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

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

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

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

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

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

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

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

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

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

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

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

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

Причиной возникновения фичи не должны быть аналоги у конкурентов или «мне кажется, будет круто». Без анализа «зачем» нельзя понять, насколько реализация необходима. «Повысить Retention», «увеличить конверсию в платящих игроков», «снизить процент отваливающихся через неделю игроков» – хорошие цели, основанные на конкретных метриках. Еще лучше, когда есть объяснение, почему выбрано это решение, а не другое, и почему оно должно понравиться разным категориям игроков. Сюда прилагают результаты опросов, аналитики, любые данные, подтверждающие вашу гипотезу. Этот пункт должен предполагать методы проверки, насколько успешной окажется фича после завершения работы над ней.

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

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

Можно составить ЮЗЕР-СТОРИ, то есть описать, как игрок будет взаимодействовать с каким-то игровым элементом: как узнает о новой опции, как поймет принцип ее работы и взаимодействия с другими элементами, а также, например, как защититься, если игровые соперники применяют новую опцию против него. Описание самой фичи здесь минимально, все внимание сосредоточено на ходе мыслей игрока, сталкивающегося с ней, с самой первой встречи. Цель – воссоздать эмоции и цепочку возможных рассуждений игрока, сформулировать желаемую мотивацию. Не просто ввести новую фичу, но понять, почему она станет ценной.

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