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

Подготовка к релизу

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

• шлифовать игру до финальной версии;

• оптимизировать ее, если необходимо, под разные платформы;

• проводить все маркетинговые активности и размещать игру в сторах.

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

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

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

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

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

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

Чем занимается тестировщик и виды тестирования

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

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

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

Цели тестирования могут отличаться на разных этапах жизни проекта. Во время активной разработки важно вызвать как можно больше «отказов», чтобы выявить скрытые в программе дефекты. Поэтому по большей части будет проводиться «негативное тестирование», цель которого – пытаться всеми способами «сломать» игру, чтобы впоследствии устранить найденные дефекты. Ближе к релизу (не только всего проекта, это может быть и релиз части функционала) уже проводятся приемочные тесты, цель которых – доказать, что все работает как задумано.

Первое, над чем работают QA, – SMOKE-ТЕСТЫ. Это быстрая проверка работоспособности текущего билда: что он вообще запускается, что можно зайти в игру, создать аккаунт и пр. Задача smoke-тестирования – быстро удостовериться, что продукт функционирует, базовые функции работают и последние изменения не конфликтуют с текущей версией игры. Если проблемы начинаются уже на этом этапе, проверять что-либо дальше не имеет смысла, можно прекращать тестирование и писать разработчику, что требуется новый билд.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Теперь важно провести КОМПЛЕКСНОЕ ТЕСТИРОВАНИЕ СОВМЕСТИМОСТИ, которое включает в себя тестовое покрытие[77]77
  . Тестовое покрытие (от англ. test coverage) – это одна из метрик оценки качества тестирования программного обеспечения. Представляет собой величину, выраженную в процентах, которая отображает степень плотности покрытия тестами функциональных требований или исполняемого кода.


[Закрыть] на целевом железе. Обычно игровые студии обращаются к специализированным компаниям, особенно для игр под Android: целевых устройств очень много. ПК-игры тоже необходимо протестировать на машинах с разной производительностью, линейками видеокарт, оперативной памятью, разрядностью операционной системы и прочим. Проводить такие плейтесты самостоятельно может быть очень дорого; необходимо обратиться хотя бы к друзьям и знакомым, чтобы убедиться, что на разных устройствах все работает как задумано.

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

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

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

Для предварительного тестирования необходимо хотя бы 10 человек, для ЗБТ[78]78
  . ЗБТ – сокращенно от «закрытое бета-тестирование».


[Закрыть] или soft launch – от тысячи. Желательно, конечно, чтобы это были люди, входящие в состав целевой аудитории, подобранные с помощью таргетинга[79]79
  . Таргетинг (от англ. target – «цель») – рекламный механизм, позволяющий выделить из всей имеющейся аудитории только ту часть, которая удовлетворяет заданным критериям (т. е. целевую аудиторию).


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

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

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

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

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

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

Отзывы игроков

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

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

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

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

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

Другое дело, если некоторые непопулярные решения принимаются вынужденно, просто чтобы не сломать внутриигровую систему, например игровой баланс. В некоторых MOBA-играх разработчики ослабляют самых сильных и популярных героев, чтобы уравнять всем шансы на победу. Для киберспортивных продуктов забота о балансе особенно важна. Но исчезновение отработанной тактики в Heroes of the Storm или ослабление любимого героя League of Legends вызовут серьезное разочарование у части игрового сообщества.

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

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

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

Третья проблема не такая глобальная, но тоже встречается. Это ненависть сообществ. Отсутствие чернокожих рыцарей в Kingdom Come: Deliverance было достаточным основанием к призыву бойкотировать эту игру. Другое дело, что аудитория игры была все-таки более нишевой и для этих людей реалистичный сеттинг и историческая достоверность происходящего были одними из главных преимуществ, так что никто не пострадал.

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