Организация удобных багрепортов для альфатестеров браузерной игры

На данный момент мы заняты разработкой браузерной игры и в поте лица готовим ее к ближайшим закрытым, открытым, альфа и бета-тестам. В связи с этим надо создать максимально удобную систему багрепота со стороны пользователей. Стоит учитывать, что несмотря на многократные предупреждения игроков, что они являются участниками технического этапа, не стоит испытывать их терпение. Если не формировать никаких условий для « улучшения проекта», то все просто плюнут на ваши трудности и пойдут в какой-нить релизнутый проект, где знай себе — «играй, люби, плати».

Казалось бы, сознательный пользователь может спокойно увидеть багу, открыть некую открытую на внешку багтрекер, грамотно поставить там задачу и т.п. Теоретически – может. Практически – см. окончание прошлого абзаца. К слову, этот подход зачастую и связан с накоплением первого негатива к проекту, ведь набрать альфа-тестеров тоже стоит рекламных денег, начинается сбор аудитории, а она натыкается на продукт, который просят протестировать, но условий для этого не создают – в результате увеличение стоимости рекламы, общий фон вокруг проекта и т.п.
Но вернемся к нашим баранам, т.е. багам.

Какие условия?

• Браузерный проект, стратегия;
• Технологии – Flash + PHP;
• Внутренний багтрекер – Redmine.

Что требуется

• Организовать быстрый и казуальный багрепорт любым игроком;
• Возможность игрока дать текстовое описание багу;
• Возможность игрока приложить скрин экрана;
• Возможность игрока пометить прямо на экране, что игрок считает визуальным проявлением ошибки, ну или просто написать по среди экрана красным цветом три буквы (разумеется, слово «БАГ»);
• Возможность игрока отправить по одному клику всю важную информацию разработчикам;
• Необходимость разработчика адекватно размещать задачу в редмайне и реализовать основную группировку багов по маркерам, а по возможности и попытаться определять на кого конкретно стоит багу отправить (опять же ориентируясь по маркеру);

Как выглядит со стороны игрока

Пользователь находится в игре и, надеемся, наслаждается игровым процессом. Тут внезапно он замечает ошибку. Ну, скажем, иконка в магазине «полетела». Казалось бы мелочь и тянуться до каких нить хитрых сервисов репорта игроку за этим явно лень («играть то не мешает в общем, да и разрабы наверняка знают»). Чтобы снизить порог «лени» для репорта пользователю достаточно нажать на F12. Тогда он увидит следующую картину прямо поверх своего текущего экрана, никаких перезагрузок и перебросок:

Рис.1

Как видимо по рисунку выше – поверх города игрока появился тултип, сообщающий, что игрок находится в режиме багрепорта. Ниже расположилась минималистичная формочка, позволяющая вбить комментарий, выбрать цвет маркера для пометок и записей поверх экрана, кнопки отмены действий и кнопка «Отправить», которая, очевидно отсылает багрепорт нерадивым разработчикам, его допустившим.
Следом игрок видит заполненную форму ошибки, открывающуюся на соседнем табе:

Рис.2

На этом забота игрока о репорте заканчивается, вкладку он может закрыть и продолжить игру с места, где остановился.

Как выглядит со стороны разработчика

Обсудим немного реализации, а заодно отметит, как итоговый процесс представляется разработчику.
Итак:

• клиент полностью «привязан» к серверу, т.е. проверяет примерно в 2400 местах, где сервер шлет какие данные, их корректность. Если где-то что-то не согласуется, то генерирует ошибку. Упрощенный пример такой ситуации: после найма юнита должно было остаться 1000 золота, а осталось 1001;
• ошибка имеет уникальный маркер, состоящий из кода ошибки и хеша места ошибки. Пример: проверка на валидность ответа некого метода сервера, может проверять 100500 методов, если проверка не пройдена именно эта — это код ошибки, а к нему приписывается еще хеш, который уникален именно для набора данных, на которых возникла ошибка, таким образом, каждая ошибка в конкретном месте игры имеет свой уникальный маркер;
• если клиент генерирует ошибку, или если тестер просто видит визуальный косяк в игре, он жмет F12, и появляется такая вот форма как на рисунке 1.
• когда нажимается «отправить» в этой форме, то клиент формирует архив, который содержит в себе: скриншот (если есть «граффити» от игрока – вместе с нми), файл с комментом тестера, лог ошибок (если они были), код ошибки (если была), лог ворнингов (что могло привести к ошибке)
• затем этот архив в хранилище, где на сервере он распаковывается и показывается юзеру по http-ссылке в виде подробного и удобного репорта об ошибке, который можно наблюдать на рисунке 2.
• И наконец, самое удобное: сервер этой системы создает задачу в Redmine, отслеживая повторные задачи по маркеру ошибки, и назначает ее на менеджера проекьта, ставя в наблюдатели продюсера, а также ведущих разработчиков по серверу и клиенту.
• К задаче аттачится ссылка на репорт игрока.

Получается задача в Readmine примерно такого плана:

Рис.3

При желании, а скорее при необходимости, систему можно расширять и улучшать во нмогих направлениях. Например, вводить достаточно объективные (верные с 90% вероятностью) критерии прямой отправки бага на непосредственного лида, с добавлением ПМ’а и/или продюсера в наблюдатели.

И этого достаточно?

…спросит любознательный читатель. Для удобной организации сбора ошибок со стороны пользователей – да. Более чем уверены, что с течением времени система будет обрастать плюшками, фишками, расширяться функционально. При увеличении команды проекта, наверняка придется вводить отборочные критерии, как писалось выше.

Конечно, не стоит забывать и про правильное логирование. Зачастую, приложенный к ошибке лог намного полезнее всех скриншотов и пометок от пользователя. Эта система, разумеется, также должна быть реализована на любом этапе тестирования и хотя материал не о ней, коротко изложим тезисы:

• есть внутриигровая система учета логов, т.е. игровой сервер пишет каждый чих юзера в специальном формате (в т.ч. и ошибки), в текстовые файлы. Эти логи собирает сервер статистики, где их и можно посмотреть, сгруппировать по разным признакам (например, наиболее частые ошибки), посмотреть путь которым юзеры приходят к ошибке по последовательности в логах и т.п.
• есть система приема багов от клиента игры (автомат) который просто сообщает серверу, что случилась такая-то ошибка на клиенте, без логов, не через сервисы сервера (которые могут висеть) а через отдельный скрипт через http-запрос, это тоже попадает в игровые логи и на сервер статистики.

Заключение

Первые проверки на удобство реализуемой систем уже ведутсЯ, игроки репортят баги,, группировка помогает отсеивать повторы и т.п. Как уже говорилось выше, этот подход не является единственным, уникальнейшим или универсальным. Он «какой-то такой, для нас работающий» – делимся поводами для его создания и примерным мнением об удобствах. Конечно, программистам всегда придется копаться в логгах на сервере статистики, КМам перерывать форумы на предмет важных репортов и т.п. Но можно существенно упростить все этой действо для самих игроков. Надеемся, что читателе смогут извлечь из материала пользу и для своих проектов.

Автор: VBproffi