Хочу в геймдев!

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

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

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

Документация: гейм-дизайн-документ

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

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

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

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

ГДД – это развернутое описание, как вы ведете пользователя к нужным ощущениям, для отдельной системы или для проекта целиком. На основании этого документа формируется (как часть ГДД) практическая инструкция для исполнителей – техническое задание (сокращенно ТЗ). Здесь хранится вся информация для программистов, художников, тестировщиков и т. д.

Обычно работа над фичей начинается именно с изменений в шаблоне ГДД. Такой шаблон встречается практически в каждой компании – гейм-дизайнер редко придумывает его с нуля, в этом нет смысла. Либо вы ведете документацию каждой версии, либо создаете отдельный документ для каждой фичи. Шаблоны для разных задач могут отличаться: например, шаблон для дизайна квеста, шаблон для дизайна абилки и т. д.

В шапке ГДД на отдельную фичу всегда обозначен человек, ответственный за нее, – FEATURE OWNER, – чтобы при возникновении вопросов любой член команды знал, к кому можно обратиться за пояснениями. Если фича уже реализована и по ней проведена аналитика, ссылку на ее результаты также прикрепляют в начале документа. Это конкретные, заранее продуманные метрики любых взаимодействий с фичей и их последствия. В некоторых компаниях заранее, еще на этапе составления ГДД, записываются метрики, которые должны отслеживаться; а когда готов аналитический отчет, он закрепляется в шапке или рядом.

Далее ГДД содержит ИНФОРМАЦИЮ ОБ ИТЕРАЦИЯХ, чтобы можно было сразу понять, на каком этапе находится работа над фичей. Например, итерация 0 – базовое описание функционала, итерация 1 – что нужно поменять/добавить и т. д. Для разных итераций могут заводить отдельные ГДД.

Итак, первым делом необходимо обозначить КОНКРЕТНЫЕ ЦЕЛИ, почему вы хотите ввести ту или иную фичу. Цели должны быть достижимыми и измеримыми, чтобы впоследствии проверить, достигли мы их или нет. Это нужно бизнесу и менеджменту, чтобы иметь информацию для принятия решения, делать их или нет, исполнителям, желающим лучше понять, для чего они работают над той или иной задачей, и вам, чтобы восстановить ход размышлений спустя какое-то время. Четкие цели помогают экономить время и не читать все ГДД в поисках ответа, зачем же делали ту или иную фичу.