Написання верхнерівневого дизайн-документа (GDD)
GDD на 200 сторінках з описом кожного предмета, NPC та діалогу — це не GDD, це заготовка енциклопедії. Реальний інструмент для початку розробки — верхнерівневий дизайн-документ на 20–40 сторінках, який відповідає на питання: в чому унікальність гри, як виглядає ігровий цикл, які системи потрібно побудувати та чому гравець повернеться.
Команда повинна прочитати GDD та зрозуміти, що робити. Якщо після прочитання залишаються питання «а як саме працює X» — це нормально для верхнього рівня. Якщо залишаються питання «а чому нам взагалі робити X» — документ не виконав свою функцію.
Що входить у верхнерівневий 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 днів |
Вартість визначається після ознайомлення з концепцією та вимогами до обсягу документа.