Игровая разработка без боли и кранчей. Как выжить в игровой индустрии и сохранить вдохновение - Ричард Лемаршан
Однако по мере приближения к альфа-майлстоуну нам, вероятно, придется отойти от концентрической разработки, чтобы включить в игру все фичи и плейсхолдеры уровней, которые нам нужны для альфы. Нам снова надо будет переключить передачи, по возможности придерживаться концентрической разработки, но при этом принять некоторые новые методы, необходимые для эффективной работы. Мы рассмотрим эти изменения в главе 29.
Некоторые игровые платформы – большинство игровых консолей и некоторые мобильные устройства и VR-платформы – требуют прохождения сертификации до выпуска игры. Альфа-фаза проекта – подходящее время для детального изучения сертификационных требований в рамках подготовки к дополнительной работе, которую команде необходимо будет выполнить, чтобы им соответствовать. Подробнее об этом вы можете прочитать в главе 34.
Простой метод отслеживания ошибок
В каждой игре, большой или маленькой, важно в какой-то момент производства начать методично находить, перечислять и исправлять баги, прячущиеся внутри игры и портящие игровой опыт. Как только вы этим займетесь на этапе продакшена, можете считать, что вы вошли в альфа-фазу вашей игры.
Начните с разработки тест-плана. Тест-план обычно делает руководитель QA-отдела в сотрудничестве с креативными руководителями проекта, продюсерами и, возможно, руководителями отделов. Работая в небольшой команде, старайтесь привлекать к этой работе столько членов команды, сколько это практически осуществимо. Тест-план немного похож на рецепт блюда или план на выходные. У нас выписано то, что мы имеем представление о необходимых элементах и инструментах и проблемах, с которыми мы можем столкнуться. Мы составляем списки в соответствии с важностью проблем, которыми мы должны заняться в первую очередь. Мы можем также указать в плане, какие составляющие игры не будут проходить тестирование, чтобы QA-отдел и команда разработчиков могли установить некоторые границы в своей работе.
Составление тест-планов – это зрелая дисциплина, и вы можете найти много подробной информации о разработке хорошего тест-плана в интернете. Эшли Дэвис и Адам Сингл дают множество подробных и технических советов по созданию тест-плана игры в своей статье Testing for Game Development[163] («Тестирование в разработке игр») для Gamasutra.
Как только у вас есть план, вы готовы начать тестирование. Обычно прохождение билда игры в соответствии с тест-планом и учет обнаруженных ошибок занимают немало времени. (Лучше тестировать билд игры, а не запускать ее в редакторе, так как билд может вести себя по-другому.) Стоит отметить, что QA-тестеры обычно не просто играют в игру свободно и исследовательски, как это сделал бы обычный игрок. Они тщательно проверяют каждый тип возможного взаимодействия, высматривая то, что ведет себя не так, как следовало бы. Если вы работаете в небольшой команде, вам придется решить, как вы будете тестировать игру. Нанять кого-то, кто поможет вам с обеспечением качества, – это всегда хорошая инвестиция.
Даже если ваша команда настолько мала, что вы просто тестируете игру самостоятельно по мере ее разработки, вы все равно должны записывать обнаруженные ошибки. Профессиональные разработчики используют специальные базы данных, также известные как баг-трекеры, для ведения списка ошибок и информации, сопровождающей каждую из них. Среди некоторых популярных систем отслеживания ошибок на момент написания книги можно назвать Jira, Bugzilla и Mantis.
При разработке небольшого проекта можно отслеживать ошибки в электронной таблице. Дайте столбцам эти заголовки (или используйте шаблон с сайта этой книги):
• Номер бага;
• Дата и время обнаружения;
• Дата и время билда (или номер билда);
• Краткое описание;
• Класс;
• Приоритет;
• Категория;
• Описание;
• Локация в игре;
• Воспроизводимость;
• Шаги для воспроизведения ошибки;
• Задействованный скрипт;
• Ответственное лицо;
• Статус;
• Приложения;
• Примечания;
• Примечания к исправлению.
Давайте рассмотрим каждый из этих разделов и ту информацию, которую вы будете вносить в каждый столбец.
Номер бага
Каждая ошибка должна иметь уникальный номер, чтобы вы могли быстро и легко ее обозначить.
Дата и время обнаружения
При обнаружении бага надо записать дату и время его обнаружения. Многие электронные таблицы позволяют вводить дату и время с помощью сочетания клавиш.
Дата и время билда (или номер билда)
Вы должны обозначить билд игры, в котором впервые был обнаружен баг. Вы можете прочитать про билды и то, как их собирать, в главе 5.
Краткое описание
Этот столбец должен включать очень краткое описание ошибки – затем оно будет служить ее названием.
Класс
Баги бывают разных классов, каждый из которых описывает степень их серьезности. Точное определение каждого класса может варьироваться от студии к студии, но довольно часто можно встретить эту классификацию:
• Блокер (Showstopper)
☉ Ошибка, которая должна быть немедленно исправлена, поскольку она в какой-то момент препятствует прохождению игры – следовательно, и тестированию[164].
• Класс А
☉ Серьезная ошибка, которая существенно мешает функционированию игры и должна быть исправлена[165].
• Класс Б
☉ Ошибка, которая существенно влияет на функциональность или опыт, создаваемый игрой, и которая должна быть по возможности исправлена.
• Класс В
☉ Менее серьезная ошибка, которая не оказывает существенного влияния на функционирование или опыт, создаваемый игрой, но которая должна быть исправлена, если это возможно.
Комментарий
☉ Этот класс багов используется тестировщиками
