Как написать геймдизайн-документ: структура, советы и популярные ошибки

Как написать геймдизайн-документ: структура, советы и популярные ошибки

Геймдизайнер — это человек, который стоит у истоков каждой игры. Он создает концепцию и правила игры, доносит до каждого члена команды его задачу. И главный инструмент в руках этого специалиста — геймдизайн-документ.

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

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

«Плохой диздок — это тот, который не отвечает на главные вопросы: что? зачем? и почему?. Нельзя, чтобы после прочтения документации у ребят, которые занимаются реализацией, остались какие-либо глобальные вопросы», — говорит Евгений Чувычин, Lead game designer студии VOKI Games.

В нашем материале мы расскажем о том, как сформировать эффективный ГДД, который будет понятным и доступным во всех отношениях. 

Итак, где же начать писать главный мануал проекта? Существует много популярных сервисов для организации документов (Confluence и т.п.), но оформить информацию можно и в Google Docs. 

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

Будьте готовы, что ГДД будет меняться с каждым обновлением игры. Какие-то процессы будут оптимизироваться, появляться новые фичи и персонажи, меняться пути подачи информации и т.д. 

Начнем со структуры. Для каждого проекта она индивидуальна, но условно ее можно поделить на рубрики:

  • Оглавление
  • Вступление
  • Нарратив
  • Геймплей
  • Интерфейс
  • Фичи
  • Аналитика

Оглавление: здесь стоит описать иерархию проекта, ссылки для навигации по документу.

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

Нарратив: история места и события, лор, информация о персонажах, квестовые элементы.

Геймплей: игровой процесс со всеми его механиками и способами взаимодействия с игроком. 

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

Также рекомендуем разбить структуру на пункты и списки там, где это возможно.

Например:

  1. Игроку предлагается поставить в особняке новый предмет мебели

1.1. Если игрок имеет достаточно звезд — он покупает предмет

1.2. Если у игрока недостаточно звезд — ему предлагается пройти уровень по поиску предметов.

Фичи: функции предметов, ресурсы и другие возможности, фишки игры.

Графика: арт-гайд, форматы, работа с текстом и прочая стандартизация, характеристики персонажей и окон. Здесь важно отметить, что стоит избегать лишнего описания анимации. Например:

Нет: «персонаж подпрыгивает на месте, подняв руки вверх, испугавшись шума в камине»;

Да: «персонаж пугается».

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

Аналитика: A/B тесты, статистика из разных источников и отслеживание метрик.

Как написать геймдизайн-документ: структура, советы и популярные ошибк

Еще несколько полезных советов:

  • не стесняйтесь иллюстрировать информацию картинками. Странно описывать окно или персонажа, не приложив к тексту его изображение;
  • большие файлы с референсами (картинки, видео) сильно «утяжеляют» документ, да и качество этих файлов ощутимо портится. Картинки можно загрузить на файлообменник или вынести в отдельный документ, а видео — залить на YouTube, добавив в ГДД только ссылки;
  • предложения должны быть краткими и информативными. Помним — мы пишем не роман, а руководство к действию; 
  • в документе должен быть порядок: текст аккуратно оформлен, а каждая ссылка — в нужном месте с подписью. 

Вернувшись к теме хорошего ГДД, можно сказать, что при его создании и редактировании нужно ставить себя на место других членов команды и игроков, задавая себе вопросы: «Можно ли неправильно трактовать этот пункт?», «Будут ли у человека дополнительные вопросы?», «Легко ли ориентироваться в документе?». 

Тем не менее, не стоит гнаться за идеальным диздоком. Позвольте ему оптимизироваться и обновляться параллельно с развитием вашего проекта!