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

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

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

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

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

Простой метод отслеживания ошибок

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

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

Составление тест-планов – это зрелая дисциплина, и вы можете найти много подробной информации о разработке хорошего тест-плана в интернете. Эшли Дэвис и Адам Сингл дают множество подробных и технических советов по созданию тест-плана игры в своей статье Testing for Game Development[163]

(«Тестирование в разработке игр») для Gamasutra.

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

Даже если ваша команда настолько мала, что вы просто тестируете игру самостоятельно по мере ее разработки, вы все равно должны записывать обнаруженные ошибки. Профессиональные разработчики используют специальные базы данных, также известные как баг-трекеры, для ведения списка ошибок и информации, сопровождающей каждую из них. Среди некоторых популярных систем отслеживания ошибок на момент написания книги можно назвать Jira, Bugzilla и Mantis.

При разработке небольшого проекта можно отслеживать ошибки в электронной таблице. Дайте столбцам эти заголовки (или используйте шаблон с сайта этой книги):

• Номер бага;

• Дата и время обнаружения;