Планування ігрового проекту
Типова ситуація: до нас приходить команда після трьох місяців розробки з питанням «чому у нас у репозиторії 40 гігабайт та Git падає при кожному pull?». Відповідь майже завжди одна: PNG-текстури та FBX-файли закоммічені напрямо без Git LFS, історія репозиторію раздулась до неробочого стану. Це вирішується, але переписування історії в живому проекті — болючий процес, якого можна було легко уникнути.
Планування в ігровій розробці — це не про діаграми Ганта. Це про те, щоб технічні рішення перших двох тижнів не стали проблемами через три місяці.
Документація: GDD як живий інструмент
GDD (Game Design Document) в поганому виконанні — це 80-сторінковий PDF, який ніхто не читає після другого спринту. GDD в хорошому виконанні — це структурована база знань, яку команда реально використовує кожен день.
Що повинно бути в GDD
Мінімальний набір, без якого не можна починати розробку:
Ігрові системи — точне описання кожної механіки з параметрами. Не «персонаж стрибає», а «стрибок: висота 2.4 юніта, час у повітрі 0.6 сек, є 150 мс coyote time, double jump дозволений, приземлення блокує атаку на 200 мс». Числа можуть змінюватися під час балансингу, але вони повинні бути зафіксовані та версіоновані.
Технічні обмеження — цільові платформи, мінімальні вимоги до залізо, обмеження по пам'яті та draw calls. Якщо гра повинна працювати на iPhone 11 з 60 fps, це обмеження впливає на всі art-рішення з самого початку.
Scope та фічі — явний список того, що входить в MVP та що залишається на потім. «Може бути додамо крафтинг» — це не планування, це джерело feature creep.
Референси — конкретні ігри з конкретними механіками, що беруться за основу. «Як у Dark Souls, але швидше» — це робочий референс для combat designer.
Як ми ведемо GDD
Ми використовуємо Notion або Confluence — там GDD живе як wiki, а не як файл. Зміни видні в історії, можна залишати коментарі, механіки пов'язані між собою перехресними посиланнями. Технічний дизайн та художній дизайн зберігаються окремими розділами, але посилаються один на одного.
Ключовий принцип: кожна механіка в GDD повинна мати статус — в розробці, готово, на ревью, заморожено. Це дозволяє в будь-який момент зрозуміти реальний стан проекту без телефонних дзвінків.
Технічна архітектура
Вибір стека — не релігія
Вибір між Unity та Unreal ми розбираємо детально в загальному розділі каталогу. Але на етапі планування є кілька суміжних рішень, які так само критичні:
Render pipeline в Unity. URP (Universal Render Pipeline) — для мобільних та VR. HDRP — для PC/консолей з кінематографічною картинкою. Built-in (Legacy) — тільки якщо беріть старий проект на підтримку. Менювати pipeline в середині розробки — це пересборка всіх матеріалів. Рішення приймається в день першого коміту.
Архітектура ігрових об'єктів. Класичний MonoBehaviour-підхід проти ECS (Entity Component System через Unity DOTS). ECS дає порядки продуктивності на великій кількості об'єктів, але різко збільшує складність коду. Для гіперказуальних ігор — надлишково. Для стратегій з тисячами юнітів — необхідно.
Мережева архітектура. Якщо в грі планується мультиплеєр — це рішення приймається до написання першої ігрової механіки. Single-player код та networked код влаштовані принципово по-різному: в мережевій грі кожна зміна стану повинна бути явною та синхронізуємою.
ScriptableObjects як конфігураційний шар
В Unity ми використовуємо ScriptableObject-орієнтований підхід для зберігання ігрових даних. Конфігурація зброї, параметри ворогів, налаштування рівнів — все це ScriptableObject-ассети, а не захардкодені значення в коді. Це дозволяє геймдизайнеру змінювати баланс без участі програміста та без пересборки проекту.
Версіонування та робота з ассетами
Це та область, де більшість невеликих команд втрачає час найболючішим способом.
Git + Git LFS
Стандартний Git не призначений для бінарних файлів. Текстура 4K у PNG важить 20–50 MB, і якщо її коммітити як звичайний файл, історія репозиторію раздувається катастрофічно швидко.
Git LFS (Large File Storage) зберігає бінарні файли окремо, а в Git-історію кладе тільки вказівники. Налаштовується один раз в .gitattributes:
*.png filter=lfs diff=lfs merge=lfs -text
*.fbx filter=lfs diff=lfs merge=lfs -text
*.psd filter=lfs diff=lfs merge=lfs -text
*.unitypackage filter=lfs diff=lfs merge=lfs -text
*.mp3 filter=lfs diff=lfs merge=lfs -text
*.wav filter=lfs diff=lfs merge=lfs -text
Це повинно бути налаштовано до першого коміту з ассетами. Після — болючіша міграція.
Perforce — альтернатива для крупних Unreal-проектів. Epic Games самі використовують Perforce. Краще працює з дуже великими репозиторіями (сотні гігабайт), нативна підтримка в Unreal Editor. Вищі витрати інфраструктури та складність налаштування.
Ветвлення
Для ігрових проектів ми використовуємо спрощений Git Flow:
-
main/master— стабільна збірка, завжди працює -
develop— активна розробка -
feature/*— окремі фічі або механіки -
release/*— підготовка до релізу, тільки баг-фікси
Правило: в main ніколи не коммітиться нічого, що не пройшло QA. Звучить банально, але саме його порушення приводить до того, що «остання стабільна версія» стає терміном без змісту.
CI/CD для ігрових проектів
GameCI
GameCI — набір GitHub Actions для Unity. Автоматична збірка під усі цільові платформи при кожному пушу в develop. Це вирішує конкретну проблему: «у мене на машині збирається, у тебе не збирається».
Типовий pipeline:
- Активація Unity ліцензії (headless)
- Запуск тестів (Unity Test Runner — EditMode та PlayMode тести)
- Збірка під Android (APK/AAB)
- Збірка під iOS (Xcode проект)
- Збірка під PC (Standalone)
- Завантаження артефактів в S3 або одразу в Firebase App Distribution
Час збірки — 15–40 хвилин залежно від розміру проекту. Команда отримує посилання на свіжу збірку без ручної роботи.
Unity Cloud Build
Хостингове рішення від Unity. Простіша налаштування, дорожча при великій кількості збірок. Зручно для невеликих команд без DevOps-інженера. Інтегрується з Unity Dashboard та дозволяє налаштувати автоматичну відправку в TestFlight та Google Play Internal Testing.
Jenkins
Для крупних проектів або команд з нестандартними вимогами. Повний контроль над залізо та процесом, але потребує адміністрування. Ми використовуємо Jenkins, коли проект потребує специфічної конфігурації сборочної машини або коли GameCI не покриває потрібний сценарій (наприклад, консольні платформи).
Часові рамки планування
| Етап | Тривалість | Результат |
|---|---|---|
| Технічний бріф | 1–3 дні | Список платформ, технічні обмеження, попередній вибір стека |
| GDD v1 (MVP-scope) | 1–2 тижні | Описання всіх механік MVP, технічні вимоги |
| Технічне проектування | 1 тиждень | Архітектура систем, схема БД (якщо є бекенд), мережева модель |
| Налаштування інфраструктури | 2–3 дні | Git + LFS, CI/CD, шаблон проекту, угоди про код |
| Прототип ключової механіки | 1–2 тижні | Грабельний прототип core loop |
Всього до початку повноцінного виробництва: 4–6 тижнів. Це не бюрократія — це страховка від переписування.