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

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

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

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

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

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

КОГДА ВСЕ ФИЧИ РЕАЛИЗОВАНЫ

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

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

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

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

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

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

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

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

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

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

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

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