Skip to content
E
Egmatic
шаблон gddдизайн-документ игрыgddсоло-разработчикпланирование инди-игры

5 шаблонов дизайн-документа для соло-разработчика

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

Владислав Ковнеров17 августа 2026 г.11 мин

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

Если неясно, зачем вообще нужен дизайн-документ, начните со статьи о том, зачем пишут GDD до кода; здесь же вы получите сами формы.

Почему большинство шаблонов не подходят одному человеку

Поищите «шаблон GDD» — и найдёте документы из пятнадцати разделов: планы монетизации, маркетинговые таблицы, графы для согласования. Это наследие студийных процессов, где документ согласовывает десяток человек и проходит через утверждения. У соло-разработчика задача другая: вынудить себя принять три-четыре дорогих решения — что за игра, какого масштаба и когда она готова — до того как они станут дорогими.

Поэтому шаблоны ниже сознательно короткие. Каждый жертвует полнотой ради гарантии, что вы его действительно заполните и будете поддерживать. Полстраницы, которые вы ведёте, лучше тридцати страниц, брошенных на второй неделе.

ШаблонДля чегоОбъёмВремя заполненияКогда перестаёт работать
СтраницаДжемы, первые игры1 страницаМеньше часаПроект перестал умещаться на страницу
Лист основного циклаПрототипирование одной механикиПолстраницы20–30 минутЦикл получился интересным, но больше ничего не решено
План по этапамПроект на 1–3 месяца2–3 страницыОдин вечерУ этапов нет критериев готовности
Журнал решенийРазработка уже идётРастёт со временем10 минут в неделюВы записываете мнения, а не решения
Спецификация от страницы в магазинеПодготовка к релизу1–2 страницы2–3 часаСтраница обещает больше, чем потянет масштаб

Это варианты на выбор, а не чек-лист. Большинство проектов последовательно использует два-три шаблона — именно так их и выбирают, об этом ниже.

Шаблон 1. Документ на одну страницу

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

ИГРА:          [название]
СУТЬ:          [жанр + изюминка + платформа, одно предложение]
ИГРОК:         [для кого игра, одна строка]
ЦИКЛ:          [что игрок делает каждые 30 секунд]
УПРАВЛЕНИЕ:    [схема ввода, одна строка]
В ВЕРСИИ 1:    [3–5 конкретных пунктов: уровни, режимы, контент]
БЕЗ ЭТОГО:     [сознательные отказы, список такой же длины]
ГОТОВО, КОГДА: [точное состояние, которое считается релизом]

Шаблон держат два приёма. Сначала заполните графу БЕЗ ЭТОГО и сделайте список не короче, чем «В ВЕРСИИ 1»: именно перечень отказов доводит проект до конца, а незаконченность первых игр — это проблема масштаба, а не умения. Затем впишите в ГОТОВО, КОГДА состояние, которое можно проверить, а не ощущение: «10 уровней, меню, сохранения, загружено на itch.io», а не «достаточно отполировано».

Шаблон 2. Лист основного цикла

Он нужен на этапе прототипа, пока больше ничего не существует. Одна механика описана так, чтобы стало ясно, стоит ли строить игру вокруг неё. Проектирование от цикла — устоявшаяся практика, а её привычное теоретическое основание — модель MDA: механики, динамика, эстетика.

ДЕЙСТВИЕ:      [единственное, что делает игрок]
ВЫЗОВ:         [что делает это действие нетривиальным]
НАГРАДА:       [почему хочется повторить]
ПРОВАЛ:        [что происходит при ошибке]
30 СЕКУНД:     [опишите случайные полминуты игры]
ИНТЕРЕСНО ИЗ-ЗА: [какое чувство возникает, одна честная строка]

Самая честная графа — 30 СЕКУНД. Если вы не можете пересказать полминуты обычной игры — не обучение и не босс, — значит, цикл ещё не решён, и прототип скажет вам то же самое бесплатно. Держите лист рядом, пока быстро проверяете идею; как только прототип противоречит строке — правьте строку.

Шаблон 3. План по этапам

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

Э0 ПРОТОТИП     основной цикл играбелен — готово, когда: [...]
Э1 ВЕРТИКАЛЬНЫЙ СРЕЗ  одна сцена/уровень в финальном качестве — готово, когда: [...]
Э2 КОНТЕНТ      все уровни в серых блоках, все системы — готово, когда: [...]
Э3 РЕЛИЗ        арт и звук финальные, сборка загружена в магазин — готово, когда: [...]
ЗАПАС:          20–30% календаря, заложенные заранее

Правило, которое держит шаблон в честности: каждый этап заканчивается сборкой, которую можно показать другому человеку. Если у Э1 написано «отрефакторен код движения игрока» — это список задач, а не этап; играбельная сборка — единственное доказательство прогресса, которое не умеет врать. Запас закладывайте сразу, при составлении плана: он нужен каждому первому проекту, а среди ошибок, губящих инди-проекты, незаложенное время занимает первое место.

Шаблон 4. Журнал решений

Это живой GDD в самой честной форме: не описание игры, а датированная запись решений, из которых она сложилась. Заведите его в первый день разработки — в текстовом файле или базе Notion.

2026-08-17  Формат сохранений сменён с XML на JSON.
ПОЧЕМУ:     данные уровней правятся руками; ошибки XML стоили дня.
ЗАМЕНЯЕТ:   решение от 02.07.2026.
МАСШТАБ:    без изменений.

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

Шаблон 5. Спецификация от страницы в магазина

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

НАЗВАНИЕ + СЛОГАН:   что говорит баннер в магазине
СКРИНШОТЫ (4):       что должен показать каждый кадр
ТРЕЙЛЕР:             5–8 эпизодов по порядку
ДВЕ РЕЦЕНЗИИ:        фразы, которые вы хотите услышать от игроков
ТРЕБУЕТ ОБЕЩАНИЕ:    без чего страница не может жить
СОКРАТИТЬ ДО ОБЕЩАНИЯ:  чего обещание не требует

Острая графа — ДВЕ РЕЦЕНЗИИ: игроки описывают игры чувствами и моментами, и если вы не можете представить фразу, которую хотите прочитать, обещание ещё расплывчато. Настоящую работу делают две последние графы: страница в магазине служит инструментом сокращения масштаба. Всё из «требует обещание» теперь блокирует релиз, остальное необязательно. Когда шаблон вскрывает противоречие между тем, что говорит страница, и тем, что есть в сборке, верьте шаблону и режьте.

Как выбрать свой шаблон

Три вопроса по порядку:

  1. Прототип основного цикла уже есть? Нет — берите лист основного цикла, пока ничего другое не имеет смысла. Да — дальше.
  2. Это джем или первая игра? Берите документ на одну страницу. Вы его закончите — в этом и проверка.
  3. Это проект с календарём, идущий к релизу? Выстраивайте цепочку: план по этапам — когда у проекта появился календарь, журнал решений — с первой недели, спецификацию от страницы в магазине — примерно за месяц до конца.

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

Ошибки, которые ломают любой шаблон

ОшибкаЧем вредитКак правильно
Скопировать студийный шаблон15 разделов, которые никто не ведёт в одиночкуВзять самый маленький шаблон под свою стадию
Заполнить несколько шаблонов «на всякий случай»Это варианты на выбор, а не чек-листОдин активный шаблон на стадию
Оставить «ГОТОВО, КОГДА» пустымУ проекта не появляется условия концаЗаполнить его первым, проверяемым состоянием
Считать заполненную форму окончательнойНерушимый дизайн устаревает и игнорируетсяСтавить дату у каждой правки; шаблоны 4 и 5 созданы, чтобы меняться
Перечислять функции вместо контента«Больше врагов» прячет настоящий масштабСчитать уровни, сцены, ассеты — числа, которых можно достичь
Писать документ вместо прототипаНепроверенный цикл порождает художественный вымыселЛист цикла и прототип — в одну неделю

Роль Egmatic

У всех шаблонов выше одно и то же финальное поле под разными именами: состояние, которое считается выпущенной игрой. Egmatic создан, чтобы это поле достигалось дёшево: это 2D-редактор, где вы расставляете сцены, соединяете логику узлами и экспортируете игру на десктоп, веб и мобильные платформы без сборочного конвейера. Этап, заканчивающийся «сборкой, в которую можно поиграть», перестаёт быть церемонией и превращается в экспорт; запись в журнале решений перестаёт быть обещанием, когда живой предпросмотр показывает изменение за секунды.

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

Итог

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

Источники

  1. Проектирование от цикла и модель «механики — динамика — эстетика» — Robin Hunicke, Robert LeBlanc, Marc Zubek, MDA: A Formal Approach to Game Design and Game Research (2004)
  2. Как выглядит настоящий документ препродакшна и как быстро он расходится с игрой — «Библия Doom» Тома Холла, Doom Bible (1992)
  3. Принцип «работы от обратного», положенный в основу пятого шаблона, — Colin Bryar, Bill Carr, книга «Working Backwards» (2021)

Похожие статьи