Написання Game Design Document (GDD) мобільної гри
Без GDD команда мобільної гри працює наосліп. Художник малює, розробник кодить, маркетолог планує — кожен свою версію гри. За місяць з'ясовується, що механіки не стикуються, UI не влізає в Safe Area, а монетизація не окупає CPI. Ми пишемо Game Design Document, який вирішує ці проблеми до початку розробки. Наш досвід — понад 5 років у мобільній геймдев-індустрії та десятки GDD для проєктів від hyper-casual до midcore. Кожен документ проходить рев'ю з командою замовника та адаптується під його стек (Unity, Godot, Cocos Creator) і цільову платформу (iOS, Android).
Поганий GDD: 40 сторінок надихаючого тексту без жодного числа та схеми. Хороший GDD: художник розуміє стиль за мудбордом і таблицею кольорів, розробник — за діаграмою станів і числовими параметрами, QA — за чеклістом acceptance criteria кожної фічі. Такий документ — робочий інструмент, а не маркетинговий буклет.
Що таке GDD і чому без нього не обійтися?
Game Design Document (GDD) — це єдине джерело істини для всієї команди. Він фіксує всі ключові рішення: від жанру та механік до монетизації та технічних обмежень. У мобільній розробці, де ітерації короткі, а бюджет обмежений, GDD страхує від різночитань. Факт: команда з 4 осіб без GDD втратила 2 тижні на переробку, тому що художник, розробник і маркетолог працювали з різними уявленнями. GDD, написаний за 2 дні, заощадив би 2 тижні — це в 7 разів швидше.
Як виглядає структура GDD для мобільної гри?
GDD мобільної гри відрізняється від PC/console документа — він компактніший, фокусується на touch-взаємодії та мобільних обмеженнях, включає секцію монетизації з першої сторінки (це не соромно, це реальність ринку).
Огляд і концепція
Один абзац: жанр, цільова аудиторія, USP (unique selling point). Референси: 2–3 існуючі гри з конкретним зазначенням, що запозичуємо, а що робимо інакше. Moodboard: 10–15 зображень стилю візуалу.
Не «гра про пригоди у фентезійному світі». А «match-3 з RPG-прогресією в стилі Puzzle & Dragons, але з асинхронним PvP і без energy mechanic».
Core mechanics
Для кожної механіки: назва, опис у 2–3 реченнях, user story («як гравець, я хочу X, щоб Y»), схема state machine, вхідні події (tap, swipe, hold), параметри з дефолтними значеннями та допустимими діапазонами.
Приклад параметрів механіки «кидка» в physics puzzle:
throw_power_min: 200 [100-400] throw_power_max: 1500 [800-2500] gravity_scale: 1.2 [0.8-2.0] bounce_factor: 0.6 [0.3-0.9] max_trajectory_points: 20 [10-40] Ці параметри — ScriptableObject в Unity. Game designer змінює без програміста.
UI/UX specification
Wireframes для кожного екрана — не фінальний дизайн, але розташування елементів, розміри tap targets (мінімум 44×44pt згідно з Apple HIG), ієрархія інформації. Навігаційна карта: всі екрани + переходи між ними.
Для мобайла окремо: поведінка при перериванні (дзвінок, сповіщення), поведінка при втраті з'єднання, орієнтація (portrait only, landscape only, обидві), Safe Area для iPhone з notch.
Монетизація
Конкретна модель з числами: free-to-play + IAP, premium ($2.99 upfront), rewarded ads (мета: eCPM $8–15 для casual). Опис кожного IAP: що продаємо, ціноутворення, де в інтерфейсі пропонуємо. Soft currency vs hard currency — їх джерела (earning) і синки (spending).
Energy mechanic якщо є: початковий запас, час регенерації, максимум, способи докупити. Конкретно: 5 життів, регенерація 1 життя/30 хвилин, максимум 5, повна регенерація 100 gems, 1 IAP життя — 20 gems.
Технічні вимоги
Цільові платформи: iOS 15+, Android 8.0+. Двигун: Unity 2023 LTS / Godot 4.x / Cocos Creator 3.x. Цільовий FPS: 60 на iPhone 12+, 30+ на Android mid-range (Snapdragon 665+). Розмір білду: до 100 MB для першого завантаження (App Store / Play Store рекомендації для cellular download). Asset streaming якщо потрібен.
Порівняння GDD для різних жанрів
| Аспект | Hyper-casual | Casual | Midcore/Hardcore |
|---|---|---|---|
| Обсяг документа | 10–15 сторінок | 20–30 сторінок | 40–80 сторінок |
| Механіки | 1–2 core механіки | 3–5 механік з прогресією | Система механік, рецепти, крафт |
| Монетизація | Rewarded ads + IAP | IAP + ads + subscription | IAP, DLC, battle pass |
| Технічні вимоги | Один білд, низькі вимоги | Кілька платформ, середнє | Оптимізація, серверна частина |
Рівень деталізації
GDD — living document. Не потрібно описувати кожну частинку до початку розробки. Потрібно описати:
- Core mechanics — повністю, до числових параметрів
- First hour experience — детально
- Content plan (рівні, глави, події) — структура без деталей кожного рівня
- Монетизацію — повністю
Level design конкретних рівнів — у окремих Level Design Documents (LDD), коли дійде до створення рівнів.
Формати та інструменти
GDD у Notion або Confluence — зручно для командної роботи, versioning, коментарів. Альтернатива — Google Docs зі змістом. Схеми — Miro або draw.io (FigJam). Таблиці балансування — Google Sheets (не в GDD, посилання з GDD).
Не пишемо GDD у Word без системи версіонування — через місяць ніхто не знає, яка версія актуальна.
Що входить в роботу
- Інтерв'ю за концептом (1–2 години)
- Документ огляду та концепції з референсами та мудбордом
- Опис усіх core mechanics зі схемами та параметрами
- UI/UX wireframes для ключових екранів
- Навігаційна карта додатку
- Специфікація монетизації
- Технічні вимоги
- Контент-план (рівні, події, DLC)
Терміни
3–5 робочих днів — GDD для гіпер-казуальної або казуальної гри. Для midcore / hardcore проєкту з комплексними системами — 7–14 днів. Вартість розраховується індивідуально.
Гарантуємо: після передачі GDD ви отримуєте документ, який можна одразу передати команді розробки. Зв'яжіться з нами, щоб обговорити ваш проєкт і замовити GDD.