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

Если вы последовали совету, который я дал вам в главе 5, вы постоянно вели список (а) атрибуций для любых найденных сторонних ассетов, которые использовали в своей игре, и (б) людей, которые работали над игрой, и что они сделали. Когда придет время создавать внутриигровые титры и атрибуции, вам будет значительно легче проделать эту работу. Если вы не вели такой список, вам, возможно, придется сильно напрячься, чтобы просмотреть весь контент игры, составляя списки тех, чью работу надо отметить. Некоторые приобретаемые пакеты ассетов не требуют атрибуции, поэтому внимательно проверьте информацию о лицензировании того, что вы приобрели.

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

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

Испытание достижения майлстоуна беты

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

Я должен быть честен с вами: несмотря на очень простое определение бета-версии – игра завершена! – границы беты, как и альфы, несколько размыты. Помимо тех уловок, которые разработчики игр могут использовать в альфа-версии (использование очень размытой разницы между фичами и контентом, как мы обсуждали в главе 28), есть уловки, к которым мы можем прибегнуть в бета-версии, чтобы представить руководству команды игру с законченным контентом. Самый известный способ – записать недостающий фрагмент контента как баг класса «А» в нашей базе данных багов.

Я был бы лжецом, если бы сказал, что не использовал этот трюк – было дело, но только с разрешения высшего руководства моей команды, при этом недостающий контент строго отслеживался в базе данных. Иногда такая уловка необходима, когда мы должны достичь майлстоуна бета-версии, но не успели ввести в игру весь необходимый контент. Добавление контента после бета-версии сопряжено с риском в той или иной степени. Если в итоге у вас будет более нескольких багов класса «А», которые на самом деле являются недостающими фрагментами контента, ваш проект может столкнуться с проблемами на этапе постпродакшена. Исправьте эти баги, добавив нужный контент, сразу после беты.

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

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

Подведение итогов майлстоуна бета-версии

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

• Все фичи и контент игры в приличном качестве.

• Весь фронтенд, меню и элементы интерфейса в приличном качестве, включая следующие элементы:

☉ логотип команды разработчиков и/или игровой студии;

☉ логотип издателя или факультета;

☉ титульный экран (элемент интерфейса, где можно принять решение, как начать игру);

☉ титры;

☉ указание авторства (атрибуции) для любых использованных сторонних ассетов;

☉ экран «игра окончена», который объявляет об окончании раунда игры (если это применимо к вашей игре);

☉ экран опций или экраны, позволяющие игрокам настраивать опыт (если это применимо к вашей игре).

• Иконка игры со всеми требуемыми разрешениями для приложения или исполняемого файла и ее название.