— Нам нужен дизайн-док.

— Какой именно?

— Ну...ГДД.

Пожалуй, это одна из самых частых ситуаций, с которыми я столкнулся, начав искать работу в студиях.

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

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

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

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

Итак, попробуем разобраться.

🧩 I. Концептуальные документы (Vision Level)

  1. High Concept Document

  2. One-Pager

  3. Pitch Deck

  4. Vision Document

  5. Game Overview Document

  6. Vertical Slice Brief

🎮 II. Общие дизайн-документы (Game-Level Design Docs)

  1. Classic GDD (монолитный)

  2. Modular GDD

  3. Living GDD (Agile-формат)

  4. Executive GDD (сжатая версия для продюсеров)

  5. Publisher GDD

  6. Pre-Production GDD

⚙ III. Документы по механикам и системам

  1. Feature Design Document (FDD)

  2. Core Loop Document

  3. Gameplay Mechanics Doc

  4. Combat Design Doc

  5. Meta-Game Design Doc

  6. Progression Design Doc

  7. Difficulty Design Doc

  8. Boss Design Doc

💰 IV. Баланс и экономика

  1. Economy Design Doc

  2. Monetization Design Doc

  3. LiveOps Design Doc

  4. Retention Design Doc

  5. Reward System Design Doc

🗺 V. Контентные документы

  1. Level Design Document

  2. Mission Design Doc

  3. Narrative Design Doc

  4. Quest Design Doc

  5. Worldbuilding Document

📊 VI. Техническо-аналитические

  1. Technical Design Document

  2. UX Flow Doc

  3. UI Specification

  4. Analytics Design Doc

  5. KPI/Metric Design Doc

Теперь подробно :)

1) High Concept Document

1) Что это

Короткий документ, который фиксирует ядро идеи игры: что за продукт, почему он интересен, кому и за счёт чего будет “работать”.

2) Синонимы / как его называют

  • High Concept / High Concept Doc

  • Concept Doc / Концепт-док

  • “Концепция игры”

  • Иногда путают с One-Pager (но High Concept обычно чуть глубже)

3) Когда нужен

  • Самое начало: до препродакшена

  • Когда нужно согласовать видение внутри команды

  • Когда надо быстро объяснить игру внешним людям (партнёрам/издателю/инвестору/новому сотруднику)

  • Как “нулевая точка”, от которой потом растут GDD/фич-доки

4) Объём

  • Обычно 1–3 страницы (редко до 5)

  • Время чтения: 3–7 минут

5) Для кого

  • Продюсер / владелец продукта

  • Лид-дизайнер / геймдизайнеры

  • Арт-лид, нарратив, техлид (чтобы понять общий вектор)

  • Иногда: издатель, инвестор (на раннем этапе)

6) Цели документа

  • Зафиксировать “что мы делаем” одним образом для всех

  • Показать ценность: что в игре нового/сильного

  • Очертить рамки: жанр, платформа, аудитория, тон, столпы

  • Быстро ответить на вопрос: “стоит ли вообще тратить время на прототип/вертикальный срез?”

7) Что НЕ является этим документом

  • Не подробный GDD с механиками “до винтика”

  • Не экономический расчёт и не метрики (это позже)

  • Не UI/UX спецификация

  • Не план разработки (roadmap может упоминаться, но не раскрывается)

8) Структура (рекомендуемые секции)

  1. Elevator Pitch (1–2 предложения)

  2. Жанр + платформа + аудитория (для кого и где игра живёт)

  3. USP / уникальность (в чём “крючок”)

  4. Игровые столпы (3–5 pillars) — принципы, без которых игра не игра

  5. Core Fantasy (кем себя чувствует игрок)

  6. Core Loop (очень кратко, 3–6 шагов)

  7. Ключевые фичи (5–10 буллетов)

  8. Референсы / компсы (2–4 игры/фильма/жанровых ориентира + чем похожи/чем отличаемся)

  9. Тон и опыт (эмоции, темп, “как это ощущается”)

  10. Риски и допущения (top-5) (что может убить концепт)

  11. Следующий шаг (что делаем после: прототип/вертикальный срез/тест рынка)

9) Выходные артефакты

  • Согласованные pillars

  • Ясный USP

  • Мини-описание core loop

  • Список ключевых рисков

  • Понимание, какой прототип нужен первым

10) Критерии качества

  • Читается быстро, не расползается

  • После прочтения человек может пересказать игру без фантазии “от себя”

  • Есть чёткий ответ “почему это не очередной клон”

  • Pillars не абстрактные (“весело”, “интересно”), а проверяемые

  • Есть честные риски и “что проверяем прототипом”

11) Типичные ошибки

  • Вода вместо конкретики (“уникальная, захватывающая, инновационная”)

  • Слишком много фич → нет ядра

  • Нет аудитории/платформы (а это меняет вообще всё)

  • Компсы без объяснения (“как Ведьмак”, “как GTA”)

  • Путают с GDD и начинают расписывать баланс/таблицы

2) One-Pager

1) Что это

One-Pager — это ультра-сжатая версия концепции игры на одну страницу.
Его задача — дать максимально плотный, концентрированный ответ на вопрос:

«Что это за игра и почему она вообще кому-то нужна?»

Если High Concept — это уже короткий, но всё-таки документ, то One-Pager — это ударная выжимка.

2) Синонимы / как его называют

  • One-Page Concept

  • Single Page Game Summary

  • Executive Summary

  • “Краткая концепция”

  • Иногда HR называют это просто “GDD”

3) Когда нужен

  • На первом контакте с HR / издателем

  • В тестовых заданиях (“Опишите концепцию игры”)

  • Для быстрых внутренних обсуждений

  • Когда нужно презентовать идею за 2–3 минуты

  • Для подачи на гранты / акселераторы (первый этап)

4) Объём

  • Строго 1 страница

  • 500–800 слов максимум

  • В идеале — читается за 2–4 минуты

5) Для кого

  • HR (первичная фильтрация)

  • Продюсер

  • Издатель

  • Руководство

  • Новый член команды

Это документ не для программиста, а для принятия решения: интересно или нет.

6) Цели документа

  • Быстро показать:

    • жанр

    • аудиторию

    • уникальность

    • базовый геймплей

  • Зафиксировать главную фантазию игрока

  • Дать понимание масштаба

  • Ответить на вопрос:

    “В это вообще стоит инвестировать время?”

7) Что НЕ является этим документом

  • Не GDD

  • Не фич-док

  • Не бизнес-план

  • Не маркетинговая стратегия

  • Не аналитика

One-Pager — это не детали, а суть.

8) Рекомендуемая структура

  1. Название игры

  2. Elevator Pitch (1–2 предложения)

  3. Жанр + платформа + аудитория

  4. Core Fantasy

  5. Core Loop (очень кратко)

  6. 3–5 ключевых особенностей

  7. Почему это сработает (USP / рыночная ниша)

  8. Референсы

  9. (опционально) предполагаемая модель монетизации

9) Выходные артефакты

После One-Pager у команды должно появиться:

  • Общее понимание идеи

  • Согласованный тон

  • Чёткая формулировка “о чём игра”

  • Решение — делать прототип или нет

10) Критерии качества

  • Нет воды

  • Нет “громких слов” без конкретики

  • Есть чёткая фантазия игрока

  • Есть понятный рынок

  • После прочтения хочется задать вопросы, а не закрыть документ

11) Типичные ошибки

  • Превращают в мини-GDD на 4 страницы

  • Пишут слишком художественно и забывают о геймплее

  • Нет аудитории и платформы

  • Нет понимания, чем игра отличается от конкурентов

  • Слишком много механик — нет ядра

3) Pitch Deck

1) Что это

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

Это не просто описание игры.
Это документ, цель которого — вызвать доверие и получить ресурсы.

Если High Concept отвечает на вопрос «что это»,
то Pitch Deck отвечает на вопрос:

«Почему в это стоит вложить деньги / время / команду?»

Pitch Deck может существовать вообще без полноценного GDD.

2) Синонимы / как его называют

  • Investor Deck

  • Publisher Pitch

  • Game Pitch Presentation

  • Investment Presentation

  • “Презентация проекта”

  • Иногда HR называют это “GDD” (что неверно)

3) Когда нужен

  • При поиске издателя

  • При поиске инвестиций

  • При внутреннем утверждении проекта

  • На конкурсах, грантах, акселераторах

  • Иногда — в тестовых на позицию старшего/лид-дизайнера

4) Объём

  • 10–20 слайдов (оптимально 12–15)

  • 10–15 минут устной защиты

  • Не должен быть перегружен те��стом

5) Для кого

  • Издатели

  • Инвесторы

  • Руководство студии

  • Продюсеры

  • Иногда — потенциальные партнёры

Это документ не для дизайнеров и не для программистов.
Это инструмент принятия бизнес-решения.

6) Цели документа

  • Доказать, что игра:

    • Понятна

    • Актуальна рынку

    • Реализуема

    • Может приносить деньги

  • Показать компетентность команды

  • Обосновать бюджет / сроки

  • Продемонстрировать уникальность

7) Что НЕ является этим документом

  • Не GDD

  • Не фич-док

  • Не техническая спецификация

  • Не маркетинговый план в деталях

  • Не подробная экономика

Pitch Deck — это инструмент убеждения, а не инженерный документ.

8) Рекомендуемая структура

  1. Обложка (название, логотип, жанр)

  2. Elevator Pitch

  3. Проблема рынка / возможность

  4. Описание игры (коротко)

  5. Core Gameplay

  6. USP / отличия от конкурентов

  7. Рынок и аудитория

  8. Компсы и позиционирование

  9. Монетизация / бизнес-модель

  10. Статус разработки (прототип, вертикальный срез)

  11. План производства (high-level)

  12. Бюджет и запрос

  13. Команда

  14. Почему мы

9) Выходные артефакты

После Pitch Deck должно быть:

  • Решение о финансировании / партнёрстве

  • Дальнейшие переговоры

  • Запрос на дополнительные материалы (GDD, билд, финмодель)

10) Критерии качества

  • Чёткий фокус (без рассыпания в детали)

  • Визуальная чистота

  • Логичная структура

  • Нет слайдов “ни о чём”

  • Чёткий ответ на вопрос “где деньги?”

11) Типичные ошибки

  • Перегруз текстом

  • Нет чёткого USP

  • Нет понимания рынка

  • Слишком много фич, мало стратегии

  • Отсутствие бизнес-части

  • Попытка засунуть туда GDD

4) Vision Document

1) Что это

Vision Document — это документ, который фиксирует долгосрочное видение проекта: каким он должен стать, какие принципы его формируют и какие решения нельзя нарушать.

Если High Concept отвечает на вопрос «что это за игра»,
то Vision Document отвечает на вопрос:

«Какой эта игра должна стать и какими принципами мы руководствуемся?»

Это документ про направление, философию и рамки.

2) Синонимы / как его называют

  • Project Vision

  • Game Vision

  • Vision & Pillars

  • Creative Vision

  • Иногда называют “GDD” (что создаёт хаос)

3) Когда нужен

  • В начале препродакшена

  • Когда команда начинает расти

  • Когда появляются первые разночтения

  • Когда нужно зафиксировать “вектор” развития

  • При смене лида / продюсера

Особенно важен в проектах с долгой разработкой или LiveOps.

4) Объём

  • 3–10 страниц

  • Иногда оформляется как презентация

  • Не перегружен таблицами

5) Для кого

  • Вся команда

  • Продюсер

  • Лиды направлений

  • Новые сотрудники

Это внутренний документ.

6) Цели документа

  • Зафиксировать:

    • Тон проекта

    • Игровые столпы (pillars)

    • Принципы дизайна

    • Ограничения

  • Предотвратить “расползание” концепта

  • Обеспечить единое понимание направления

Vision Document — это компас.

7) Что НЕ является этим документом

  • Не подробный GDD

  • Не список механик

  • Не roadmap

  • Не экономическая модель

  • Не маркетинговая стратегия

Это не “как делаем”, а “зачем и в каком направлении”.

8) Рекомендуемая структура

  1. Общее описание проекта

  2. Миссия проекта

  3. Core Vision (в 1–2 абзацах)

  4. Игровые столпы (3–5)

  5. Тон и эмоциональный опыт

  6. Целевая аудитория

  7. Дизайн-принципы (что можно / что нельзя)

  8. Границы проекта (scope boundaries)

  9. Долгосрочная цель (куда игра должна прийти через X лет)

9) Выходные артефакты

  • Зафиксированные pillars

  • Согласованные дизайн-принципы

  • Общее понимание “духа проекта”

  • Основа для дальнейших GDD и фич-доков

10) Критерии качества

  • Ясность

  • Конкретность (pillars проверяемы)

  • Не перегружен механиками

  • Позволяет принимать решения (“это вписывается в vision или нет?”)

11) Типичные ошибки

  • Повторяют High Concept

  • Слишком абстрактные формулировки

  • Нет ограничений

  • Нет чёткой аудитории

  • Документ никто не использует

5) Game Overview Document

1) Что это

Game Overview Document (GOD) — это структурированное, но не чрезмерно детализированное описание всей игры на среднем уровне абстракции.

Если High Concept — это идея,
а GDD — это глубинная проработка,

то Game Overview — это карта всей игры сверху, без погружения в микро-детали.

Он отвечает на вопрос:

«Как устроена игра в целом?»

2) Синонимы / как его называют

  • Game Overview

  • Project Overview

  • Game Summary (расширенный)

  • Design Overview

  • Иногда это называют “сжатый GDD”

3) Когда нужен

  • После утверждения концепта

  • Перед началом активного препродакшена

  • Для онбординга новых сотрудников

  • Когда нужно быстро показать проект стейкхолдерам

  • В тестовых на middle/senior-позиции

4) Объём

  • 5–20 страниц

  • Читается за 15–30 минут

  • Обычно без таблиц и глубокой аналитики

5) Для кого

  • Продюсер

  • Лиды направлений

  • Новый дизайнер

  • Новый программист

  • Издатель (на промежуточном этапе)

Это мост между “идеей” и “полной спецификацией”.

6) Цели документа

  • Показать:

    • Основные системы

    • Основные механики

    • Структуру прогрессии

    • Контентный объём

  • Дать целостную картину игры

  • Обозначить масштаб

7) Что НЕ является этим документом

  • Не подробный GDD

  • Не фич-док

  • Не экономическая модель

  • Не технический документ

  • Не маркетинговая стратегия

Это обзор, а не детализация.

8) Рекомендуемая структура

  1. Краткое описание проекта

  2. Жанр, платформа, аудитория

  3. Core Loop

  4. Основные механики

  5. Структура прогрессии

  6. Основные игровые системы

  7. Контент (уровни, режимы, сюжет)

  8. Монетизация (если применимо, на уровне принципа)

  9. Технические ограничения (high-level)

  10. Общий scope

9) Выходные артефакты

  • Понимание архитектуры игры

  • Основа для разбиения на фич-доки

  • Общий scope проекта

  • Понимание связей между системами

10) Критерии качества

  • Логичность структуры

  • Нет “дыр” (описана не одна система, а вся картина)

  • Нет избыточных деталей

  • Видна взаимосвязь механик

11) Типичные ошибки

  • Превращают в GDD на 80 страниц

  • Или наоборот — делают слишком поверхностным

  • Нет структуры

  • Нет связи между системами

  • Нет понимания масштаба

6) Vertical Slice Brief

1) Что это

Vertical Slice Brief — это документ, описывающий, что именно должно войти в вертикальный срез игры и зачем он создаётся.

Это не описание всей игры.
Это описание одного демонстрационного фрагмента, который показывает проект в максимальном качестве.

Он отвечает на вопрос:

«Что именно мы должны сделать, чтобы доказать, что игра работает?»

2) Синонимы / как его называют

  • Vertical Slice Doc

  • VS Brief

  • Slice Specification

  • Demo Scope Doc

  • Prototype-to-Slice Plan

Иногда путают с:

  • Прототипом

  • Мини-GDD

  • Production Plan

3) Когда нужен

  • После утверждения концепта

  • Перед выходом к издателю

  • Перед запросом финансирования

  • Для внутреннего “go / no-go” решения

  • При переходе из препродакшена в продакшен

4) Объём

  • 5–15 страниц

  • Может сопровождаться roadmap

  • Не детализируется до уровня полной спецификации

5) Для кого

  • Продюсер

  • Лиды направлений

  • Вся core-команда

  • Иногда издатель

Это управленческий и стратегический документ.

6) Цели документа

  • Определить:

    • Какой фрагмент игры будет реализован

    • Какие механики войдут

    • Какой уровень качества требуется

  • Зафиксировать scope среза

  • Определить критерии успеха

  • Ограничить разрастание задач

Vertical Slice — это не просто кусок игры.
Это демонстрация финального качества в миниатюре.

7) Что НЕ является этим документом

  • Не High Concept

  • Не полный GDD

  • Не просто “план демо”

  • Не список задач из Jira

Vertical Slice Brief — это концептуально-управленческий документ.

8) Рекомендуемая структура

  1. Цель вертикального среза

  2. Какие элементы демонстрируем

    • Core gameplay

    • Один уровень / сегмент

    • Базовая прогрессия

  3. Качество (production level?)

  4. Технический стек

  5. Объём контента

  6. Ограничения

  7. Метрики успеха

  8. Сроки

  9. Риски

9) Выходные артефакты

  • Чёткий scope среза

  • Понимание ресурсов

  • Критерии оценки

  • Основа для переговоров

10) Критерии качества

  • Нет расползания scope

  • Понятны границы

  • Ясно, какие системы войдут

  • Есть критерии “мы доказали, что игра работает”

11) Типичные ошибки

  • Делают “маленькую игру” вместо среза

  • Добавляют лишние фичи

  • Нет критериев успеха

  • Нет понимания, для кого делается срез

  • Путают с прототипом

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

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

Также могу поделиться реальными примерами структур — без NDA, но с практической пользой.