Опыты на игроках, или вся правда о внешнем тестировании
Внешние тесты как возможность дать игрокам потрогать готовящийся контент раньше всех остальных, а разработчикам — узнать, насколько он зайдет и что необходимо исправить.
Одним из важнейших этапов работы над любым проектом, фичей или единицей контента является тестирование с привлечением игроков на так называемом комьюнити-сервере — внутри компании мы его еще называем внешним тестированием или «внешкой». Такое тестирование помогает познакомить игроков с запланированными нововведениями и изменениями до релиза, а затем на основании отзывов и собранной статистики понять, в верном ли направлении мы движемся.
Иными словами, внешнее тестирование — это:
- способ узнать общее мнение аудитории о новинке;
- возможность для участников теста задать любые вопросы о готовящейся фиче или контенте, пообщаться с разработчиками и таким образом напрямую повлиять на продукт;
- возможность проверить несколько вариантов визуала или баланса;
- инструмент раннего анонса.
Тестирование War Robots Remastered продлилось с апреля по сентябрь 2020 года. За это время мы провели более 20 тестовых сессий, за которые успели проверить более 200 единиц контента, включая 81 робота, 109 пушек и 4 обновленные карты.
Каждый внешний тест подобен небольшому релизу, поэтому подходить к его организации и проведению нужно ответственно, уделяя внимание массе мелких деталей. Именно поэтому по всем процессам, которые в него входят, у нас существуют подробные руководства.
Как все это происходит, мы и рассмотрим подробнее далее.
С понедельника по пятницу: подготовительный этап
Подготовка теста обычно происходит в будние дни, в то время как сам тест — в выходные. В случае с ремастером бывало, что мы проводили и дополнительные сессии тестирования среди недели, но в статье опишем все-таки наиболее классический вариант.
На первом этапе происходит выбор дежурных. С ними стоит определиться еще в начале недели — в понедельник-вторник. Как правило, к ним относятся:
- геймдизайнер, отвечающий за подготовку тестового билда, проведение внутренних плейтестов, информирование о замеченных на тестах проблемах и дежурство во время теста — поэтому еще его называют дежурным;
- клиентский программист, который подключается в случае, если возникают проблемы в билде или при его сборке;
- серверный программист, чья помощь может понадобиться в случае проблем с работой сервера, балансом и подобными вещами.
Также в подготовке участвуют разработчики фичей, с чьей подачи тестирование и происходит — в данном случае это техническая команда ремастера. Она же помогала проводить и внутренние тесты билда.
Кроме того, в тестах с различной периодичностью участвуют другие геймдизайнеры, левел-дизайнеры, комьюнити-менеджеры и специалисты по тестированию (QA).
Дежурный геймдизайнер заводит отдельный документ в Confluence, в котором собирает всю актуальную информацию по текущему тесту:
- даты проведения и временные периоды доступности серверов игрокам;
- имя дежурного;
- версию клиентов для Android и iOS;
- базовую ветку релиза;
- перечень тестируемых веток и их содержимое.
Помимо этого, авторы фичей, которые хотят отправить их на тест, должны проанализировать результаты предыдущих тестов или же просто довести свои фичи до состояния, пригодного для демонстрации игрокам. Когда автор определился, что тест фиче действительно необходим, и она к нему готова, он об этом пишет в канале в Slack, где ведется вся коммуникация по внешкам. После этого у него остается еще пара дней (понедельник-вторник) на мелкие доработки.
Мы собираем заявки от всех отделов на те фичи или фиксы, которые нужно протестировать: в них входят названия веток и описания их содержимого. За сбор нужной информации ответственен дежурный, и времени ему на это отводится до среды. Очень редко, но все же случается, что веток на тест нет. В таком случае на неделе его просто отменяют.
После этого готовится общая ветка теста, содержащая в себе все ветки фичей, заявленные на предыдущем этапе. Делаем мы это в привычном git-клиенте — Fork или SourceTree. Основой обычно служит ветка develop или свежая релизная ветка игры — это и есть ранее упомянутая базовая ветка, которая отражается в документации на тест. Подробнее о том, что все это такое, можно почитать в одной из предыдущих статей цикла.
В случае возникновения проблем при мерже любой ветки в тестовую дежурный сначала пытается решить их самостоятельно, а если ему это не удается — обращается к владельцу ветки, заявляющему ее на тест. Наконец, если и это не помогает — обращается к дежурным программистам.
Комьюнити-менеджер или человек из саппорта собирает со всех владельцев веток список вопросов к игрокам, на которые они должны ответить по окончании теста. Делается это до 13:00 пятницы.
После этого начинается этап финального тестирования перед внешкой — обычно он проходит в четверг-пятницу. К нему дежурный проверяет работоспособность собранной ветки в редакторе Unity и в случае каких-либо проблем обращается к владельцу ветки или дежурным программистам. Если все хорошо, он собирает тестовые билды в TeamCity. От релизных они отличаются по большей части наличием консоли с чит-кодами, позволяющими менять сервер, выдавать ресурсы, проверять работоспособность матчмейкинга и т. д.
Как только билды готовы, дежурный собирает внутренний плейтест с участием других геймдизайнеров, авторов отправленных на тест веток и других желающих. Обычно мы отыгрываем по 2-3 матча на каждой из платформ с 4-12 участниками — в зависимости от того, что мы тестируем. По ходу проведения плейтеста дежурный записывает информацию обо всех замеченных недоработках и вообще весь конструктивный фидбек. Вся эта информация агрегируется и по завершению теста публикуется в Slack-канале внешки. Критические ошибки сразу исправляются. Иногда выключается часть проблемного контента, неважного для конкретного теста. В каких-то случаях мы информируем комьюнити-менеджеров, что на тесте будут такие-то известные баги, а они потом доносят это до сведения игроков в сообщениях о старте теста в социальных сетях.
После всех исправлений мы проводим еще один внутренний тест для того, чтобы убедиться, что билд можно передавать игрокам. Если изначально тестировалась девелоперская сборка с консолью, то нужно собрать релизную и убедиться, что она функционирует аналогичным образом.
Готовые билды дежурный заливает в Google Play (для Android) и Testflight (для iOS) и информирует всех о том, что билды готовы для внешки, и она состоится. Дедлайн — вечер пятницы.
В конце этапа подготовки дежурный готовит настройки сервера к тесту. Делается это через так называемую админку. На это есть вечер пятницы и утро субботы. Существует целый чек-лист, по которому нужно пройтись и убедиться, что:
- правильно настроены дата и время старта, а также расписание теста в целом;
- добавлены ссылки на актуальные анкеты с вопросами к игрокам на русском и английском языке;
- заведены новости, которые будут публиковаться в соответствующем разделе в клиенте игры и информировать игроков о наличии анкеты, а также содержать ссылку на нее;
- очищена база игроков с предыдущего теста;
- включены мастер-серверы внешки;
- ряд других параметров имеет строго определенные настройки.
Суббота и воскресенье: этап тестирования
Как правило, тестирование проходит в выходные и разбивается на несколько интервалов: это важно для поддержания хорошего матчмейкинга при относительно небольшом пуле игроков (хотя в нашем случае он не то чтобы совсем небольшой — речь о 10 000 человек). Дежурство в выходные относится к переработкам и компенсируется компанией. При отсутствии проблем оно обычно отнимает порядка 4 часов за 2 дня — по часу на утреннюю и вечернюю сессии в субботу и воскресенье.
Основные инструменты дежурного для отслеживания состояния внешки:
- группы теста в социальных сетях (Facebook, VK, Discord), где игроки делятся любыми замеченными проблемами;
- админка тестового сервера;
- страница в нашем аналитическом сервисе, посвященная внешнему тесту;
- канал внешки в Slack, куда мы пишем обо всех изменениях настроек и проблемах теста;
- устройства с iOS и Android для самоличной проверки работоспособности.
Также к таким инструментам можно отнести стримы конкретного теста на YouTube, которые позволяют взглянуть на ход матча глазами игроков.
В перечень задач дежурного входит:
- Проверка того, что сервер включился и выключился в назначенное время. Здесь у нас сбоев никогда не случалось, но все равно стоит посмотреть, правильно ли выставлены соответствующие настройки расписания в админке.
- Необходимость сыграть пару матчей на обеих платформах при старте сессии, чтобы убедиться, что все нормально.
- Проверка в билде новости со ссылкой на опросник для игроков. Ссылка должна быть работоспособной, а форма анкеты — без проблем открываться и отправляться по мере заполнения.
- Периодический мониторинг отзывов игроков в соцсетях и проверка показателей тестовых сессий через аналитическую систему. Это необходимо для оперативной реакции на любую поломку и нештатную ситуацию.
- В случае возникновения проблем и в зависимости от их типа — их устранение или клич в Slack, чтобы с этим помогли программисты, администраторы, комьюнити-менеджеры или техподдержка.
Какие конкретно могут возникнуть проблемы и что с ними делать?
- Игроки не могут попасть в игру или в бой. В таком случае мы проверяем показатели в аналитической системе и самолично на устройствах, пишем о проблеме администраторам и дежурному от серверных программистов.
- Проблема с конкретным роботом или вооружением. Нужно убедиться что это действительно так, самолично опробовав проблемный контент на устройстве. Первое, что нужно сделать — отключить возможность приобретать этот контент в магазине. Второй этап — удаление аккаунтов игроков, чтобы сразу у всех изъять забагованный контент. Да, это радикальная мера, но иногда без нее не обойтись. Делается это обычно в промежутке между тестовыми сессиями — то есть, по окончании уже начатой.
- Нет одной или нескольких карт. В этом случае нужно убедиться, что карта включена в админке. Если же нет — добавить ее. Впрочем, иногда это норма, если мы тестируем конкретные карты, и на одной или нескольких возникают проблемы в ходе внутреннего плейтеста.
- Есть карта, которой не должно было на этом тесте — из-за багов, крешей или ее несоответствия сценарию теста. В таком случае тоже смотрим настройки админки и выключаем ее.
- Игроки не могут зайти в игру в назначенное время из-за сообщения о ведущихся работах по обслуживанию сервера, либо наоборот — могут зайти во время, не указанное в расписании. Это ошибки в настройках расписания, которые правятся через админку.
- Игрокам предлагается обновить приложение или выводится сообщение, что их версия операционной системы не поддерживается, хотя они без проблем играют на ней в основной билд игры. Зачастую это тоже ошибки в настройках, которые правятся через админку.
- Игроки не видят новость со ссылкой на анкету-опросник или не могут по ней попасть в анкету. Это тоже сигнализирует о неверной настройке в админке.
- Игрокам не хватает ресурсов на покупку нужного контента в тестовом билде. И снова речь о сбившихся настройках админки. Как видно, вообще многое можно решить через админку, поэтому перед тестом ее нужно тщательно проверять.
- Не работает веб-интерфейс самой админки. В этом случае обращаемся к администраторам и дежурному от серверных программистов.
- Что-то новое, не описанное здесь. Тут уже необходимо действовать по обстоятельствам и обязательно отписываться о проблеме в канал внешки в Slack. В крайнем случае, если проблема серьезная и возникает у многих игроков, можно принять решение о завершении текущего теста.
На случай возникновения особо сложных проблем у нас заготовлено два шаблона для публикации обращений к игрокам в соцсетях — на русском и английском языках — со следующим посылом (именно посылом, текст может изменяться):
- Есть проблема, она нам известна, и мы работаем над ее решением;
- Тест внепланово завершается: проблема очень серьезная и не позволяет нам продолжить тест, спасибо за участие, приходите в следующий раз.
Впрочем, большинство тестов за редким исключением проходят успешно, а какие-то ошибки и вовсе всплывают раз в несколько лет. И все же у нас в документации прописаны меры практически на любой возможный случай.
Начало новой недели: обработка результатов
После завершения тестирования ответственный от техподдержки или комьюнити-менеджеров агрегирует полученные от игроков отзывы и вкидывает в канал внешки в Slack в виде ссылки на отчет. Обычно он включает в себя три страницы:
- Агрегированные ответы на основные вопросы теста, в которых можно поставить оценку или выбрать один из вариантов ответов. Мы видим средние оценки от всех пользователей по любым запрашиваемым метрикам, а также то, какой процент аудитории выбрал тот или иной вариант ответа.
- Агрегированные ответы на вопросы по технической стороне теста и собранная статистика. Там много разной полезной информации, например: в какое время и какое количество анкет приходило; как долго длилась загрузка игры и боя; возникали ли какие-либо технические проблемы при установке или в ходе игрового процесса; были ли визуальные баги во время игры; какое устройство использовалось для игры и с какой версией операционной системы.
- Все ответы на основные вопросы теста с разбивкой по отдельным игрокам. Здесь мы видим не только ответы конкретного пользователя на вопросы с предыдущих этапов, но и текстовые ответы на вопросы и комментарии. Также сюда добавляются ссылки на YouTube-ролики игроков, за которые мы выдаем небольшую награду — и которые помогают лучше разбирать возникшие проблемы и смотреть на ситуацию глазами игроков.
Первый блок позволяет нам быстро считать общее отношение игроков к тестируемым изменениям и нововведением. Кроме того, эти данные проще сравнивать между тестами, понимая, как повлияли новые правки на итоговое отношение аудитории. Второй блок направлен на выявление различных технических проблем и прочих неполадок, которые могли помешать полноценно протестировать нововведения или составить о них верное представление. Наконец, третий блок позволяет понять, почему была поставлена та или иная оценка.
В финале теста и в первые дни после него на YouTube появляется масса роликов от наших инфлюенсеров, которые также позволяют лучше понять настроения аудитории и ее отношение к нововведениям. Но не стоит забывать, что мнение инфлюенсеров не равно мнению аудитории и наоборот. Да, они коррелируют, но это не тождественные величины.
Полученная информация позволяет геймдизайнерам и всем, кто отправлял свои фичи и доработки на тест, понять общее впечатление игроков, их ощущения. Но этого недостаточно для выводов по фичам и контенту — и уж точно недостаточно для формирования выводов по техническим правкам и оптимизациям. В дополнение изучаются агрегированные данные из аналитической системы. Например, в случае с контентом они позволяют узнать:
- средний урон за матч у пользователей новинки на тесте;
- как часто новинку использовали;
- среднее время жизни меха в бою;
- соотношение побед-поражений;
- какие контентные сборки использовались чаще всего (для роботов — какие на них ставили пушки, модули, пилотов, дронов и т. д.).
В случае с ремастером нам важно было сопоставлять показатели пересобранного контента с его текущими версиями с предыдущих тестов.
Важный момент: напрямую сопоставить показатели с внешки с показателями прода (то есть, с цифрами с основных игровых серверов проекта) не получится. Корреляция есть, но в целом игроки ведут себя на тесте иначе. Не осторожничают, не стремятся к победе и оптимальным сборкам контента. Иногда просто фанятся или тестируют безумные билды. Поэтому лучше сравнивать показатели с тестового сервера между собой с поправкой на условия теста. Например, мех ближнего боя будет выдавать разные цифры при тесте только на ближних картах и только на дальних.
На основании всей полученной информации мы решаем, стоит ли тестировать нововведение дальше, изменить ли какие-то параметры или прекратить тестирование, и следующий раз взять в работу что-то другое.
В любом случае, это будет уже следующей итерацией внешки, которая пойдет по аналогичному сценарию, начиная с выбора дежурных.
Подводя итоги: о пользе внешнего тестирования и практические советы по его проведению
- Внешний тест — отличный инструмент для сбора мнений игроков, игровой статистики и для раннего анонса изменений. К каждому такому тесту стоит относиться как к небольшому релизу — с максимальной ответственностью.
- Как и за любой важный процесс, за каждый внешний тест должны отвечать конкретные люди в рамках своих специализаций — ответственные или дежурные. Лучше их чередовать от недели к неделе, так как подготовка релиза — дело достаточно стрессовое.
- У всех этапов подготовки и проведения теста должны быть четкие временные рамки, известные всем участникам, также единый канал коммуникаций — лучше всего для этого подходит канал в корпоративном мессенджере. Да и вообще весь процесс стоит тщательно документировать.
- Для более сосредоточенного онлайна и хорошего матчмейкинга разбивайте тест на сессии, по несколько часов, несколько раз в сутки — как днем, так и вечером или ночью, если хотите обеспечить возможность поучаствовать в тесте игрокам со всего мира.
- Как и в случае с обычным релизом, внешний тест должен предваряться внутренними плейтестами и последующим фиксом замеченных критических багов.
- Авторы фичей, которые выкатываются на тест, должны всячески содействовать его проведению: оперативно предоставлять ветки и фиксить найденные баги, помогать во внутренних тестах билдов внешки.
- В случае возникновения критических для теста проблем, не поддающихся починке, или при проблемах со сборками билдов, нужно быть готовым отменить внешний тест, проинформировав игроков. Еще на этапе составления плана тестов нужно закладывать, что какой-то их процент не состоится.
- Перед стартом внешнего теста важно убедиться, что все настройки в админке выставлены правильно.
- Собирайте отзывы игроков через формы фидбэка, а игровую статистику — через привычный аналитический сервис. И то, и другое — важный итог тестирования.
- Разделяйте агрегированный фидбэк игроков из формы и отзывы инфлюенсеров и конкретных лидеров мнений. Это разные вещи, хоть между ними и присутствует корреляция. Отзывы игроков, конечно, на первом месте.
Это пятая статья нашего цикла о разработке ремастеров игровых проектов. В следующий раз мы расскажем о самом сердце ремастера — о графическом пайплайне, новом пуле технологий, позволяющем не только улучшить внешний вид игры, но и ее производительность.
Мы удалили несколько комментариев под данной публикацией, потому что они нарушали правила сообщества Gamedev — запрет на содержание нецензурной брани в комментариях.
Политика сообщества Gamedev предполагает общение с позиции максимальной открытости и вежливости. Мы не против критики — просто нужно высказывать её, не нарушая правила.
Подробнее о концепция сообщества, навигации и правилах общения можете почитать по ссылке ниже:
Основательно конечно, непонятно только кто все это будет читать =) Небольшим инди это где-то за горизонтом, у специалистов больших компаний своя кухня, а игрокам это словоблудие вообще не уперлось.
Кроме этих двух крайностей есть и другие варианты =) Даже если у тебя в компании какой-либо пайплайн уже настроен и работает, все равно полезно узнать, как другие команды аналогичные процессы выстроили.
Спасибо за статью!
Это просто очередная промостатья про донатку с роботами, пишут они скучно, но chemodan с баблом на сто статей уже занесли - приходится выкручиваться.
Тот же вопрос. Такое ощущение, как будто чей-то диплом открыл. Много, подробно и совершенно бесполезно.
Интересно, спасибо.
По вашему опыту, что несет больше полезной информации - анализ записи действий + опросники или запись с одновременным комментированием, т.е. "The think aloud method"/verbal protocol с последующим формализованным анализом по типу CPML?