Написание верхнеуровневого дизайн-документа (GDD)
GDD на 200 страниц с описанием каждого предмета, NPC и диалога — это не GDD, это заготовка энциклопедии. Реальный инструмент для начала разработки — верхнеуровневый дизайн-документ на 20–40 страниц, который отвечает на вопросы: в чём уникальность игры, как выглядит игровой цикл, какие системы нужно построить и почему игрок будет возвращаться.
Команда должна прочитать GDD и понять, что делать. Если после чтения остаются вопросы «а как именно работает Х» — это нормально для верхнего уровня. Если остаются вопросы «а зачем нам вообще делать Х» — документ не выполнил свою функцию.
Что входит в верхнеуровневый GDD
Core Gameplay Loop. Один-два абзаца и схема. Что делает игрок каждые 30 секунд, каждые 5 минут, каждые 30 минут. Для мобильного rouge-like: убиваешь монстров (30 сек) → собираешь апгрейды (5 мин) → заканчиваешь ран, открываешь постоянные улучшения (30 мин). Понятно и программисту, и художнику, и продюсеру.
Player Progression. Как игрок становится сильнее/опытнее. Что открывается и когда. Механики удержания (daily rewards, streak, progression gates). Для F2P — монетизационная модель на уровне концепции: что продаём, как это не ломает баланс.
Game Systems Overview. Список систем с однострочным описанием назначения. Combat System, Inventory, Crafting, Quest/Mission, Save/Load, Economy, UI/HUD. Это будущий беклог для разработки — каждая система станет эпиком в Jira.
Технические ограничения и платформенный контекст. Верхнеуровневый GDD пишется с пониманием движка. Если делаем на Unity Mobile → нет ray tracing, ограниченный particle budget, нужен offline mode. Эти ограничения влияют на дизайн: нельзя проектировать систему с real-time глобальным освещением для мобильного проекта.
Референсы. Не просто «похоже на Minecraft». А «система крафта как в Valheim (recipe-based, resource nodes в открытом мире), но без клеточного строительства — свободное размещение как в Rust». Конкретные механики из конкретных игр — это язык, понятный всей команде.
Почему GDD часто не работает
Три классических проблемы.
Первая — документ описывает «мечту», а не продукт первой версии. 50 классов персонажей, 300 предметов, процедурный мир — и всё это в MVP. Верхнеуровневый GDD должен разделять V1 (что будет в релизе), Post-launch (что планируем в обновлениях) и Vision (куда хотим прийти за 2+ года). Иначе команда не знает, что делать сейчас.
Вторая — нет обоснования механик. Написано «в игре есть дерево прокачки», но не написано почему. Почему не простой уровень персонажа? Что дерево даёт игроку, чего не даёт счётчик уровней? GDD должен отвечать на «зачем», иначе программист сделает систему «технически», не понимая её игровой цели.
Третья — GDD не обновляется. Написали в начале, забыли через месяц. Итог — документ описывает игру, которая давно изменилась, и никто ему не доверяет. Мы выстраиваем процесс ревизии GDD параллельно с разработкой.
Как мы пишем GDD
Начинаем с интервью: 2–4 часа с геймдизайнером или заказчиком. Задаём структурированные вопросы по жанру, целевой аудитории, монетизации, конкурентному ландшафту, техническим ограничениям. Фиксируем ответы.
Затем — competitor analysis: выбираем 3–5 похожих игр, смотрим на их loop, progression, retention механики. Не для копирования, а для понимания жанровых паттернов и точек дифференциации.
Пишем структуру GDD и согласовываем с заказчиком до написания текста. Это экономит время на переработку: лучше переделать оглавление, чем готовый раздел.
Готовый документ проходит ревью с техлидом — проверяем реализуемость механик в рамках выбранного стека и бюджета.
| Масштаб задачи | Ориентировочные сроки |
|---|---|
| GDD для гипер-казуала / прототипа | 3–5 дней |
| GDD для мидкор-игры (10–15 систем) | 1–2 недели |
| GDD для сложного проекта (RPG, стратегия, MMO) | 3–4 недели |
| Ревизия существующего GDD + gap analysis | 3–5 дней |
Стоимость определяется после ознакомления с концепцией и требованиями к объёму документа.