Вячеслав Уточкин – Хочу в геймдев! Основы игровой разработки для начинающих (страница 36)

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

Убедившись, что ваш билд функционирует, можно переходить к ТЕСТИРОВАНИЮ ЗАДАЧ. Базовая логика тестирования – сделать так, чтобы игра работала по заявленным требованиям. Здесь все понятно: если гейм-дизайнер обозначил условия для игрового события, QA должен проанализировать и сверить полученную информацию с той, что была заявлена, и проверить, не нарушает ли она общих стандартов функционирования продукта. Такая работа занимает 70 % работы QA-специалиста: он проверяет, что конкретная задача действительно выполнена и в полном объеме соответствует описанию. Поэтому чем больше информации тестировщик получит от заказчика, тем лучше будет результат.

Не стоит чего-то утаивать: напротив, нужно дать максимум ввод-ных данных, чтобы специалист мог верно оценить объем тестирования, а не тратить время на «найди то, незнамо что». Чтобы это работало эффективно, разработка должна вестись в рамках конкретных задач. Например, если вы используете Trello, можно перенести задачу в колонку Need test, откуда QA-специалист, в свою очередь, либо отправит ее в Done, либо сообщит об обнаруженных дефектах через баг-репорт и отправит карточку на доработку.

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

Есть еще РЕГРЕССИОННОЕ тестирование, направленное на поиск ошибок в уже проверенных участках кода. В любом проекте есть какое-то слабое, проблемное место. Как известно, баги – сущность живучая, поэтому нужно убедиться, что не вернулись ошибки, которые были исправлены ранее. Предположим, нам стало известно о некой архитектурной проблеме, и в нашем шутере игроки постоянно проваливаются под землю. Даже если программисты на определенном этапе смогли исправить этот дефект, важно зафиксировать и определить его ключевые детали и отправить на регрессионное тестирование, то есть добавить в базовую проверку последующих версий игры, ведь такая проблема серьезно влияет на геймплей. Это позволяет заранее предупредить команду о возвращении бага, а не ждать негативных отзывов от игроков.

Это могут быть и абсолютно новые дефекты – ключевое значение имеет то, что они появились в ранее проверенной и исправно работающей части программы; такие баги могут возникнуть при любом изменении кода. Название «регрессионное» такое тестирование получило, так как в ходе него проверяют, не стала ли система хуже, не «регрессировала» ли она.

Чек-листы и тест-кейсы можно составлять и до появления полной версии игры. Для составления некоторых из них достаточно только утвержденных спецификаций. Например, если у нас уже есть готовый макет главного экрана или точный перечень способов оплаты игровых товаров, вполне можно написать кейсы на проверку всех кнопок экрана или платежных систем. Однако, чтобы их использовать, придется подождать рабочий билд.

ГЕЙМПЛЕЙНЫЕ ТЕСТЫ организуют для самих разработчиков, директоров, журналистов и т. д., чтобы те оценили игровые механики. На любом этапе разработки важную роль играют регулярные внутренние совместные плейтесты. Когда вся команда собирается вместе, чтобы поиграть в свою игру, шанс того, что кто-то перестанет понимать, что она собой представляет, сильно уменьшается. Такие встречи мотивируют дальше работать над проектом, ведь все видят результаты собственного труда, могут сразу заметить ошибки, обмениваться идеями и мнениями.

ФОКУС-ГРУППЫ – это специально подобранная аудитория, которой мы демонстрируем игру для проверки, насколько выбранным людям понравится то, что мы предлагаем. Скажем, мы хотим показать механику сражений на мечах историческим реконструкторам или понять, насколько интересен наш симулятор свиданий молодым девушкам из Санкт-Петербурга. В полученных отзывах о проекте кроется и обратная сторона: если результаты неутешительные, есть соблазн объяснить неудачу неправильным подбором фокус-группы. Это опасный подход – нужно быть абсолютно уверенным, что проблемы не в самой игре. Такой вид тестирования проводят на ранних этапах производства.

Полноценные ИГРОВЫЕ ТЕСТИРОВАНИЯ НА ЖИВЫХ ИГРОКАХ (альфа, бета, soft launch) покажут, насколько гейм-дизайнерские решения приятны для более широкой аудитории. Здесь важно именно собирать отзывы. Поиск багов лучше проводить раньше и предоставить его профессионалам; они сделают это быстрее и качественнее, чем игроки.

А/Б-ТЕСТИРОВАНИЕ предполагает, что мы делим игроков минимум на две группы и каждой демонстрируем отличную от другой группы некую новую игровую сущность. Суть такого тестирования в том, что контрольная группа сравнивается с набором тестовых групп, где один или несколько показателей изменились. Так можно проследить, какие из изменений улучшают целевой показатель. Проверять геймплей таким образом очень сложно: если одной группе дать шанс урона X2, а другой нет, ощущения от игрового процесса будут слишком разными, чтобы сделать корректные выводы. Проверять, как работают разные монетизационные предложения (скидки, акции и пр.), напротив, очень эффективно.

Другой вариант: мы преподносим новый функционал постепенно: сначала, допустим, для 5 % игроков, потом для 20 % и т. д. При таком подходе, если на первых этапах мы выявляем какие-то проблемы, у нас есть возможность исправить их до того, как эти изменения затронут широкую массу игроков. Особенно это актуально для мобильных игр, здесь важно постоянно снимать метрики и проверять монетизационные схемы. Технически такой процесс не самый простой, так что в основном этим занимаются крупные игровые студии, для которых цена ошибки слишком высока.

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

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

Теперь важно провести КОМПЛЕКСНОЕ ТЕСТИРОВАНИЕ СОВМЕСТИМОСТИ, которое включает в себя тестовое покрытие[77] на целевом железе. Обычно игровые студии обращаются к специализированным компаниям, особенно для игр под Android: целевых устройств очень много. ПК-игры тоже необходимо протестировать на машинах с разной производительностью, линейками видеокарт, оперативной памятью, разрядностью операционной системы и прочим. Проводить такие плейтесты самостоятельно может быть очень дорого; необходимо обратиться хотя бы к друзьям и знакомым, чтобы убедиться, что на разных устройствах все работает как задумано.

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

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

Следующий процесс – формальные приготовления для размещения проекта на игровых платформах. Это относительно просто для мобильных сторов (Google Play и App Store) и Steam, сложнее для Epic Games и очень сложно для консолей, у которых самый серьезный контроль качества перед размещением на их площадке.

Для предварительного тестирования необходимо хотя бы 10 человек, для ЗБТ[78] или soft launch – от тысячи. Желательно, конечно, чтобы это были люди, входящие в состав целевой аудитории, подобранные с помощью таргетинга[79]. Если в игру, направленную на женскую аудиторию, с помощью целевого трафика «загнать» 90 % мужчин, результаты будут соответствующими. Трафик покупают либо на целевую аудиторию, либо на большую массу пользователей, но раздробленную по каким-то признакам, – чтобы снять метрики со всех категорий игроков. Консольные игры больше продвигают за счет бренд-маркетинга и PR, чем за счет трафика. ПК-игры где-то посередине: можно покупать трафик, но все равно важен органический трафик – то есть пользователи, пришедшие из поисковых систем.

Много внимания уделяется сбору метрик и отзывов. Гейм-дизайнер и продюсер должны заранее продумать, какие именно данные необходимы, чтобы сделать выводы и договориться с программистами о технической реализации сбора статистики. Современные технологии, например облачные, позволяют собирать и хранить большой объем данных, но это не всегда дешево. Для небольших проектов фиксация всех состояний и действий игрового монстра против игроков может быть неоправданным решением, хотя очевидно, что анализировать такое взаимодействие полезно. Можно фиксировать, например, не каждый факт смерти игрока от моба, а каждый десятый.