Игровая разработка без боли и кранчей. Как выжить в игровой индустрии и сохранить вдохновение

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

• должны быть удалены любые отладочные показания на экране (например, показатель частоты кадров);

• должны быть созданы фичи и контент, которые потребуются для сертификации игры, если они еще не были созданы и доработаны. Мы обсудим это более подробно в главе 34.

Как только мы подготовим релиз-кандидат, мы готовы еще его потестировать.

От релиз-кандидата к золотой мастер-версии

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

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

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

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

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

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

Выпуск игры

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

Если мы выпускаем игру на таком сервисе, как Steam или Google Play, нам надо будет пройти короткий процесс подачи заявки и утверждения, а также, возможно, внести плату. Владельцы платформы проверят игру и либо одобрят ее для распространения, либо откажут.

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

Глава 34 Процесс сертификации

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

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