Ты решил создать свою первую игру. Ура! Но с чего начать? С изучения матчасти, конечно же. А в ней говорится, что каждый уважающий себя геймдизайнер сначала должен написать дизайн-документ.
Концепция, «вижн», УТП, сеттинг, сюжет, стилистика, геймплей и механики, дизайн уровней, визуальный стиль, интерфейсы… Все это в теории нужно описывать на этапе препродакшена в геймдизайнерской документации (диздок). Но нужно ли это на самом деле?
Как выстроен процесс в большой команде
Геймдизайнера в игровой студии, выпускающей крупные тайтлы, можно смело назвать менеджером по продукту, где в качестве продукта выступает игра. В его задачи входит формирование для игры требований и описание всех возможностей, которые должны быть реализованы.
После того, как дизайн игры описан и согласован, вся документация обычно передается на проработку в технические команды, где уже анализируют описанные геймдизайнером верхнеуровневые требования. Затем разбивают их на множество маленьких задач, выделяют из них наиболее важные для MVP и приступают к разработке.
К моменту, когда команда уже перешагнет MVP и начнет проработку целевой версии игры, большинство геймдизайнерских фич, описанных ранее, зачастую меняется. И, к сожалению, как это обычно происходит на практике, многие из них вовсе уходят в бэклог (т.е. умирают), чтобы уложиться в дедлайны.
А как в маленькой?
У инди-разработчиков или небольших команд единого подхода к ведению игровой документации нет. Кому-то достаточно описания концепта и кор-геймплея, а кто-то ведет полную документацию с подробным описанием каждой механики, расчетом игрового баланса и т.д.
Из того, что я сам видел, общаясь с разработчиками, у многих из них – это один-два небольших документа в облаке, в которых расписан сюжет игры, ключевые механики, поведение врагов (если они есть) и редких случаях дизайн уровней. Имея ограниченные ресурсы, инди-разработчики не тратят много времени на проработку диздока со всеми подробностями и красивыми схемами. Они описывают свою игру концептуально, что позволяет максимально быстро передать суть игры и начать техническую проработку проекта.
Как формируется диздок?
Геймдизайн-документ (ГДД) или диздок – это детальное руководство для разработчиков, в котором содержится описание всех аспектов будущей игры.
Структура может быть разной, в зависимости от создаваемых игр и их жанра, но если говорить об усредненном варианте, то я бы выделил следующие разделы:
-
Общая информация (введение): название, жанр, платформы, целевая аудитория, возрастной рейтинг;
-
Концепция: суть геймплея, главная цель игрока, сюжет без деталей (синопсис);
-
Игровой мир: дизайн уровней, сеттинг, лор игры, персонажи;
-
Геймплей и управление: игровые механики, возможности игрока, формулы и расчет баланса, UI и UX;
-
Последовательность прохождения: схема и порядок прохождения игры, варианты концовок / награды;
-
Графика и звук: стилистика, гайдлайны дизайнерам, музыкальное сопровождение, звуковые эффекты;
-
Техническая часть: выбранный движок, требования и ограничения (хотя архитектура проекта и техническое описание обычно выносятся отдельно).
Каждый раздел должен быть проработан так, чтобы у разработчиков не возникали вопросы, в духе «что должен делать игрок на локации 2?» или «какие виды атак доступны врагу X?».
А если геймдизайнера все-таки заваливают подобными вопросами и просьбами разъяснить написанное, то это явный признак того, что диздок не был детально проработан, либо написан абстрактно, на уровне предположений. Документ, передаваемый разработке, должен четко отвечать на вопрос «как делать», а не предлагать список вариантов, из которых нужно выбрать лучший.
Еще одним важным условием хорошего геймдизайн-документа является постоянная поддержка актуальности написанного. Все изменения баланса, структуры игры, уровней и прочие нововведения должны фиксироваться. Обновлять диздок необходимо не только пока игра разрабатывается, но даже после релиза, если на нее будут продолжать выходить апдейты и фиксы. А также, желательно вести историю изменений, аналогично коммитам разработчиков.
Где лучше всего писать геймдизайн-документацию?
Подходы к написанию документации зависят от размеров проекта и команды. Будет неудобно писать диздок в Google Docs, если это RPG со множеством квестов, персонажей и огромным игровым миром. И напротив, можно потратить десятки часов на изучение документации по работе с базой знаний, чтобы впоследствии написать в ней несколько страниц для простого платформера, который будет создан за пару часов.
Лучше всего сначала использовать то, с чем уже есть опыт работы. Это по крайней мере сэкономит время, потраченное на изучение незнакомого инструмента. К тому же, если геймдизайнер подключается к проекту уже на стадии продакшена, то вполне вероятно ему придется пользоваться теми инструментами, с которыми команда уже привыкла работать и выбор делать не придется.
Что используют в студиях
Как правило, для ведения документации больших проектов создают внутренние базы знаний, которые постоянно обновляются и расширяются геймдизайнером по мере роста проекта. Идеальным вариантом, на мой взгляд, является Confluence, Notion или их аналоги, которых существует немало. Например, некоторые советуют попробовать для пет-проектов Milanote или Obsidian, но я их на практике не использовал.
Базы знаний ведутся довольно просто. Создается единое пространство, в котором документация разделяется на отдельные страницы, как минимум до уровня разделов диздока. Страницы редактируются с помощью визуального редактора, и вся информация обновляется сразу, как только геймдизайнер ее сохраняет. Если разработчику потребуется что-то найти, он идет на конкретную страницу или использует поиск по всей базе знаний.
Но не все ограничивается одним лишь текстом. Для визуального представления концептов и схем отлично подойдут интерактивные доски, например, Miro, Figma или Draw.io. В большинстве случаев, донести до разработчика то, каким должен быть игровой цикл, ИИ врагов или интерфейс, лучше всего через визуал. Это проще и быстрее воспринимается, нежели детально описанный процесс в тексте.
А чтобы было максимально комфортно контролировать разработку, документацию связывают с таск-трекерами, типа Jira или Asana. Так получаются страницы, на которых описаны определенные фичи, напрямую связанные с задачами на их разработку.
А что используют инди?
Google Docs. И здесь действительно можно поставить точку. Для типичного инди-проекта не требуется такого глубокого подхода как в крупных проектах или студиях, где в продакшене задействовано множество команд.
Если бы все разработчики в действительности создавали диздоки как это делают в крупных студиях, то половина из них до сих пор бы писала эти документы, так и не начав делать игру. Инди-разработчику достаточно описать концепцию, синопсис и обязательно критерии завершения, по достижении которых игра будет считаться завершенной.
И вот почему я особенно выделяю последнее. Без точного определения скоупа проекта, его границ, вы можете провалиться в долгострой и никогда не завершить разработку. Поэтому до начала разработки, стоит четко прописать границы проекта.
Если инди-разработчику не лень и много свободного времени, то можно использовать сервисы о которых я написал выше.
Как я отказался от диздоков
Большую часть времени, работая над крупными проектами, я практически всегда использовал Confluence – для ведения документации, а Jira с канбан-доской – для контроля задач. Это де-факто стандарт в индустрии для средних и крупных студий, впрочем, как и многие другие продукты Atlassian.
И если бы мне вновь пришлось подключаться к проекту, который будет разрабатываться и поддерживаться не менее двух лет, то непременно бы топил за использование именно этих инструментов.
Когда я ушел в инди и занялся разработкой собственных проектов, мне пришлось пересмотреть весь пайплайн создания продуктов, к которому я привык ранее.
Первое, что мне пришлось сделать, это поменять подход к ведению проектов и их препродакшену. Поддерживать огромные базы знаний стало бессмысленно и дорого, с учетом того, что проекты делаются крайне быстро относительно «большого геймдева» и такая детальная проработка на ранних этапах им только мешает.
Так, моя документация по проектам оказалась лишь в облачных документах и схемах на интерактивных досках. При этом, для контроля разработки я сохранил общий подход Agile, который, как мне кажется, наиболее выгоден для небольших инди-проектов.
Для большинства инди-проектов, разрабатываемых как соло-разработчиками, так и небольшими командами, достаточно следующего:
-
Описать концепт игры, кор-геймплей с механиками (без лишних деталей, передав лишь суть, в идеале схематичное изображение на интерактивной доске) и критерии завершения;
-
Завести канбан-доску и прописать на ней первые задачи (с деталями, которые не были описаны в концепте);
Вот и все. Как только общий концепт, описывающий суть игры, и первые задачи для разработки созданы, можно начинать разработку.
Почему мне не нравятся полноформатные диздоки (о которых я рассказал в начале)? Они избыточны для большинства игр. В особенности если вы работаете один или в небольшой команде. С той скоростью разработки, как сейчас делают игры, можно делать проекты в т.н. «потоке», когда новые фичи рождаются непосредственно во время разработки. А задачи формируются по необходимости, а не по плану.
Причем это тот случай, когда неважно, каким образом ты создаешь игру. Вайбкодишь или консервативно разрабатываешь все сам.
Инди-разработчикам не нужны даже популярные «диздоки-десятистраничники», предложенные Скоттом Роджерсом, поскольку формат, описанный в его книге «Level up. The guide to great video game design» не пригодится ни во время продакшена, ни после. Это будет текст ради текста. Который не даст четких инструкций для разработчиков, как делать игру, не покажет финансовую составляющую проекта для издателей / инвесторов, и перегрузит лишней информацией маркетологов. Так для кого же он?
Пример диздока для инди-проекта
Чтобы было нагляднее, покажу из чего состоит диздок одного из моих последних экспериментальных проектов.
В самом начале документа я указываю жанр / сеттинг, референсы, источники вдохновения и пр., чтобы читатель сразу настроился на нужную волну. В моем случае это хоррор-приключение на основе мультфильма Ежик в тумане (Юрия Норштейн) и видеоигры Observer (Bloober Team).
Далее я пишу концепцию, в несколько абзацев без лишних деталей. Это похоже на то, когда ты описываешь другу какую-то незнакомую ему игру, выделяешь основные ее отличия от похожих игр и рассказываешь, почему в нее стоит поиграть. А еще это очень похоже на короткие описания игр, которые расположены под обложками игр в Steam.
«Хоррор-приключение от первого лица с элементами аналогового хоррора и сюрреализма. Игрок исследует локации, решает простые задачи и пытается выбраться из пространства, которое постоянно возвращает его в начало. При каждом возвращении окружение меняется. Локация не пропускает игрока дальше, пока он не выполнит определенные условия».
После концепции я прописываю технические ограничения и основной игровой цикл. Все пишется своими словами, с одной лишь целью – заранее указать рамки, в которых проект будет реализован и не потерять фокус во время разработки.
Например, можно указать, что в проекте не должно быть кат-сцен, окружение с процедурной генерацией, вместо кода делать на Blueprint, ИИ врагов без боевки и т.д. А в игровом цикле я описываю геймплей, который повторяется на протяжении всей игры.
Игрок исследует локацию;Доходит до конца локации;Телепортируется в начало этой же локации;Обнаруживает, что окружение изменилось;Находит предметы, подсказки или новые интерактивные объекты;Выполняет необходимое условие;При следующем переходе локация изменяется или открывается путь на следующую;Игрок переходит к следующему эпизоду;
Учитывая, что этот ГДД я создавал для себя, то сразу прописал и верхнеуровневую реализацию этапов игры, то есть ее последовательность. Что делает игрок на первом уровне, какие у него цели, что делает на втором уровне и т.д. К описанию еще добавил, как это технически будет реализовано, поскольку имею опыт и представление как буду разрабатывать свой же проект.
Но геймдизайнеру или начинающим разработчикам это не нужно, достаточно лишь геймплейно описать последовательность своими словами. К тому же, подробно описывать каждую механику заранее невыгодно: прототипирование и тесты всё равно выявят проблемы и появится много изменений.
Закончил свой диздок описанием дополнительных механик, размерами персонажа (чтобы помещался в дверные проходы, коридоры) и критерием готовности. Например, зафиксировал, что у игрока в руке будет фонарик работающий от батареек. Размеры персонажа взял стандартные для движка, в котором работаю – 180 юнитов (см) в высоту. А критерий готовности, учитывая простоту игры, у меня такой: «игрок может пройти весь путь от начала до финала без блокирующих ошибок».
Не нужно пытаться подробно описать все будущие системы сразу. Лучше оставить спорные идеи в списке потенциальных механик, а детали, предназначенные для реализации записывать уже непосредственно перед работой над ними.
Важно понимать, что в диздоке фиксируются только принятые решения, а не каждая пришедшая в голову идея.
Как научиться писать геймдизайн-документацию и практиковаться в этом?
Лучший способ сейчас научиться писать геймдизайн-документацию это ИИ. Узнать о подходах, форматах диздоков и геймдизайне в целом, с примерами и разъяснениями проще всего через любые LLM.
Курсы же, предлагающие обучение геймдизайну, по большому счету, будут учить создавать документацию, предназначенную для крупных проектов. Как работать с инди-проектами, не обучает практически никто. И это серьезная проблема, для тех, кто не планирует делать карьеру геймдизайнера в большом геймдеве, а предпочитает свободное плавание.
Но если необходимо получить фундаментальные знания, то лучше начать с изучения книг по дизайну игр от практикующих геймдизайнеров. В них будет вся та же информация, что и на обучающих курсах, но в более «сухом» формате. Это сэкономит по меньшей мере, год обучения и средства, потраченные на курс.
Если бы я начинал изучение геймдева сейчас, то скорее всего совместил бы книги, для получения базовых знаний и теории, а практиковался бы с ИИ. Пишешь геймдизайн-документацию и сразу же отправляешь ее в «продакшен» Claude Code или ChatGPT Codex. Очень удобно, написал диздок и сразу получил созданный на его основе прототип.
Да и само составление ГДД значительно проще через ИИ. Пишешь в свободной форме все то, что хочешь видеть в игре, а затем просишь сформировать на основе написанного геймдизайн-документацию и задать вопросы, если чего-то не хватает. Так что, ИИ в работе игрового дизайнера сейчас неотъемлемая вещь.
В заключение
Диздок в типичном его представлении не нужен большинству проектов. Если вы решаете, с чего начать создание игры, начните с простого документа, в котором опишите концепт и механики, в любом удобном для вас формате.
Для инди-разработчика диздок – это скорее ориентир для принятия решений, нежели подробный контракт, который нельзя изменять.
А если в команде больше 3 человек, и ГДД пишет не тот, кто непосредственно будет разрабатывать игру, то лучше писать его в «промптообразном» формате, как набор инструкций, что необходимо сделать в первую очередь, чтобы получился прототип игры.
Сейчас можно с уверенностью сказать, что диздок в привычном его понимании не играет важной роли в производстве игр.
ссылка на оригинал статьи https://habr.com/ru/articles/1102574/