Опыты на игроках, или вся правда о внешнем тестировании

Внешние тесты как возможность дать игрокам потрогать готовящийся контент раньше всех остальных, а разработчикам — узнать, насколько он зайдет и что необходимо исправить.

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

Иными словами, внешнее тестирование — это:

Тестирование War Robots Remastered продлилось с апреля по сентябрь 2020 года. За это время мы провели более 20 тестовых сессий, за которые успели проверить более 200 единиц контента, включая 81 робота, 109 пушек и 4 обновленные карты.

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

Как все это происходит, мы и рассмотрим подробнее далее.

Подготовка теста обычно происходит в будние дни, в то время как сам тест — в выходные. В случае с ремастером бывало, что мы проводили и дополнительные сессии тестирования среди недели, но в статье опишем все-таки наиболее классический вариант.

На первом этапе происходит выбор дежурных. С ними стоит определиться еще в начале недели — в понедельник-вторник. Как правило, к ним относятся:

Также в подготовке участвуют разработчики фичей, с чьей подачи тестирование и происходит — в данном случае это техническая команда ремастера. Она же помогала проводить и внутренние тесты билда.

Кроме того, в тестах с различной периодичностью участвуют другие геймдизайнеры, левел-дизайнеры, комьюнити-менеджеры и специалисты по тестированию (QA).

Дежурный геймдизайнер заводит отдельный документ в Confluence, в котором собирает всю актуальную информацию по текущему тесту:

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

Мы собираем заявки от всех отделов на те фичи или фиксы, которые нужно протестировать: в них входят названия веток и описания их содержимого. За сбор нужной информации ответственен дежурный, и времени ему на это отводится до среды. Очень редко, но все же случается, что веток на тест нет. В таком случае на неделе его просто отменяют.

После этого готовится общая ветка теста, содержащая в себе все ветки фичей, заявленные на предыдущем этапе. Делаем мы это в привычном git-клиенте — Fork или SourceTree. Основой обычно служит ветка develop или свежая релизная ветка игры — это и есть ранее упомянутая базовая ветка, которая отражается в документации на тест. Подробнее о том, что все это такое, можно почитать в одной из предыдущих статей цикла.

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

Комьюнити-менеджер или человек из саппорта собирает со всех владельцев веток список вопросов к игрокам, на которые они должны ответить по окончании теста. Делается это до 13:00 пятницы.

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

Как только билды готовы, дежурный собирает внутренний плейтест с участием других геймдизайнеров, авторов отправленных на тест веток и других желающих. Обычно мы отыгрываем по 2-3 матча на каждой из платформ с 4-12 участниками — в зависимости от того, что мы тестируем. По ходу проведения плейтеста дежурный записывает информацию обо всех замеченных недоработках и вообще весь конструктивный фидбек. Вся эта информация агрегируется и по завершению теста публикуется в Slack-канале внешки. Критические ошибки сразу исправляются. Иногда выключается часть проблемного контента, неважного для конкретного теста. В каких-то случаях мы информируем комьюнити-менеджеров, что на тесте будут такие-то известные баги, а они потом доносят это до сведения игроков в сообщениях о старте теста в социальных сетях.

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

Готовые билды дежурный заливает в Google Play (для Android) и Testflight (для iOS) и информирует всех о том, что билды готовы для внешки, и она состоится. Дедлайн — вечер пятницы.

В конце этапа подготовки дежурный готовит настройки сервера к тесту. Делается это через так называемую админку. На это есть вечер пятницы и утро субботы. Существует целый чек-лист, по которому нужно пройтись и убедиться, что:

Как правило, тестирование проходит в выходные и разбивается на несколько интервалов: это важно для поддержания хорошего матчмейкинга при относительно небольшом пуле игроков (хотя в нашем случае он не то чтобы совсем небольшой — речь о 10 000 человек). Дежурство в выходные относится к переработкам и компенсируется компанией. При отсутствии проблем оно обычно отнимает порядка 4 часов за 2 дня — по часу на утреннюю и вечернюю сессии в субботу и воскресенье.

Основные инструменты дежурного для отслеживания состояния внешки:

Также к таким инструментам можно отнести стримы конкретного теста на YouTube, которые позволяют взглянуть на ход матча глазами игроков.

В перечень задач дежурного входит:

Какие конкретно могут возникнуть проблемы и что с ними делать?

На случай возникновения особо сложных проблем у нас заготовлено два шаблона для публикации обращений к игрокам в соцсетях — на русском и английском языках — со следующим посылом (именно посылом, текст может изменяться):

Впрочем, большинство тестов за редким исключением проходят успешно, а какие-то ошибки и вовсе всплывают раз в несколько лет. И все же у нас в документации прописаны меры практически на любой возможный случай.

После завершения тестирования ответственный от техподдержки или комьюнити-менеджеров агрегирует полученные от игроков отзывы и вкидывает в канал внешки в Slack в виде ссылки на отчет. Обычно он включает в себя три страницы:

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

В финале теста и в первые дни после него на YouTube появляется масса роликов от наших инфлюенсеров, которые также позволяют лучше понять настроения аудитории и ее отношение к нововведениям. Но не стоит забывать, что мнение инфлюенсеров не равно мнению аудитории и наоборот. Да, они коррелируют, но это не тождественные величины.

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

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

Важный момент: напрямую сопоставить показатели с внешки с показателями прода (то есть, с цифрами с основных игровых серверов проекта) не получится. Корреляция есть, но в целом игроки ведут себя на тесте иначе. Не осторожничают, не стремятся к победе и оптимальным сборкам контента. Иногда просто фанятся или тестируют безумные билды. Поэтому лучше сравнивать показатели с тестового сервера между собой с поправкой на условия теста. Например, мех ближнего боя будет выдавать разные цифры при тесте только на ближних картах и только на дальних.

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

В любом случае, это будет уже следующей итерацией внешки, которая пойдет по аналогичному сценарию, начиная с выбора дежурных.

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