Ознакомительная версия. Доступно 26 страниц из 130
мы обсуждали в главе 28), есть уловки, к которым мы можем прибегнуть в бета-версии, чтобы представить руководству команды игру с законченным контентом. Самый известный способ – записать недостающий фрагмент контента как баг класса «А» в нашей базе данных багов.
Я был бы лжецом, если бы сказал, что не использовал этот трюк – было дело, но только с разрешения высшего руководства моей команды, при этом недостающий контент строго отслеживался в базе данных. Иногда такая уловка необходима, когда мы должны достичь майлстоуна бета-версии, но не успели ввести в игру весь необходимый контент. Добавление контента после бета-версии сопряжено с риском в той или иной степени. Если в итоге у вас будет более нескольких багов класса «А», которые на самом деле являются недостающими фрагментами контента, ваш проект может столкнуться с проблемами на этапе постпродакшена. Исправьте эти баги, добавив нужный контент, сразу после беты.
После этапа беты разработчики игр иногда вносят в свой контент настолько серьезные изменения, что с таким же успехом они могли бы добавлять новый контент. Это тоже рискованно: такие поздние изменения скорее создают проблемы, а не решают их. Как и в случае с фичами, каждый раз, когда мы добавляем новый контент, мы рискуем заполучить баги, проблемы с контентом и проблемы с дизайном. Чем больше времени у вас есть на этап постпродакшена, тем меньше риска сулят вам основные изменения, особенно если они сделаны на ранней стадии этого этапа.
Добавлять или менять контент, относящийся к системным или интерактивным частям игры, куда рискованнее, чем добавлять или менять статические ассеты, такие как фон титульного экрана, или линейные ассеты, такие как отрендеренные видеофайлы кат-сцен. Замена плейсхолдера кат-сцены ее окончательной, готовой версией не лишена риска – новый видеофайл может больше весить и, как следствие, привести к проблемам с памятью[182]. Но гораздо менее рискованно заменять одну часть статического или линейного контента на другую, чем возиться с системными и интерактивными частями игры, где вероятность возникновения серьезных проблем гораздо выше.
Подведение итогов майлстоуна бета-версии
Таким образом, к майлстоуну бета-версии в игре должно присутствовать следующее.
• Все фичи и контент игры в приличном качестве.
• Весь фронтенд, меню и элементы интерфейса в приличном качестве, включая следующие элементы:
☉ логотип команды разработчиков и/или игровой студии;
☉ логотип издателя или факультета;
☉ титульный экран (элемент интерфейса, где можно принять решение, как начать игру);
☉ титры;
☉ указание авторства (атрибуции) для любых использованных сторонних ассетов;
☉ экран «игра окончена», который объявляет об окончании раунда игры (если это применимо к вашей игре);
☉ экран опций или экраны, позволяющие игрокам настраивать опыт (если это применимо к вашей игре).
• Иконка игры со всеми требуемыми разрешениями для приложения или исполняемого файла и ее название.
• Изображение экрана-заставки для игры, которая запускается через лаунчер.
• Любые изображения и текст, необходимые для интернет-магазина.
• Контент системы достижений, как внутриигровой, так и подключенной к сервису издателя (если это применимо к вашей игре).
• Любые «пасхальные яйца» (скрытые сюрпризы для игрока), которые вы планируете поместить в игру.
• Если для выпуска игры потребуется пройти процесс сертификации, разработчики должны выполнить как можно больше сертификационных требований (подробнее в главе 34).
Кроме того, на этапе бета-версии мы должны разработать и начать реализовывать действенный план по решению:
• любых нерешенных проблем с дизайном;
• любых проблем с производительностью;
• серьезных багов.
Обзор майлстоуна бета-версии
Когда игра достигает стадии беты и завершена как по фичам, так и по контенту, у нас есть прекрасная возможность – а для коротких проектов, возможно, последний шанс – провести обзорную встречу и получить обратную связь от людей внутри и за пределами команды, которые направят наши усилия в нужное русло.
Как и обзор майлстоуна альфа-версии, обзор беты крупной профессиональной игры, вероятно, займет некоторое время, обзор менее масштабных проектов пройдет быстрее. Убедитесь, что вы эффективно используете время своей команды, но не упустите шанс получить откровенные, качественные отзывы от доверенных коллег и наставников и действительно лучше узнать свою игру. На стадии бета-версии обычно возникает много мелких проблем, которые необходимо выявить и обсудить, и игровой команде может быть трудно решить, какие из них важнее. Как я упоминал ранее, мнение со стороны – очень эффективное средство, когда мы не можем увидеть общую картину, потому что перегружены деталями.
В своей короткой вступительной презентации руководство команды разработчиков должно представить следующее.
• Кого они считают аудиторией своей игры. Позиционирующее утверждение (см. главу 7) должно быть максимально конкретным.
• Насколько успешно бета-версия игры отвечает требованиям майлстоуна. Например:
☉ бета-версия полностью отвечает требованиям майлстоуна, в игре представлен весь контент, баги устранены, в игре соблюден игровой баланс (мы поговорим о балансе в главе 32);
☉ проект соответствует требованиям в плане контента. необходимо еще отполировать некоторый контент, устранить баги и поработать над балансом игры;
☉ проект преодолел стадию беты, весь контент уже добавлен в игру, но большая его часть нуждается в доработке, в игре много багов, игра плохо сбалансирована;
☉ проект еще не достиг майлстоуна бета-версии. команда сообщает, чего им не хватает для беты.
• Есть ли какие-то известные проблемы с проектом.
• По каким вопросам нужна обратная связь.
На этом этапе члены обзорной группы должны очень осторожно соблюдать правило, которое мы
Ознакомительная версия. Доступно 26 страниц из 130
