Услуги по планированию и проектированию игр

Планирование игрового проекта

Типичная ситуация: к нам приходит команда после трёх месяцев разработки с вопросом «почему у нас в репозитории 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, это ограничение влияет на все арт-решения с самого начала.

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:

1. Активация Unity лицензии (headless)
2. Запуск тестов (Unity Test Runner — EditMode и PlayMode тесты)
3. Сборка под Android (APK/AAB)
4. Сборка под iOS (Xcode проект)
5. Сборка под PC (Standalone)
6. Загрузка артефактов в S3 или сразу в Firebase App Distribution

Время сборки — 15–40 минут в зависимости от размера проекта. Команда получает ссылку на свежую сборку без ручной работы.

Unity Cloud Build

Хостинговое решение от Unity. Проще настройки, дороже при большом количестве сборок. Удобно для небольших команд без DevOps-инженера. Интегрируется с Unity Dashboard и позволяет настроить автоматическую отправку в TestFlight и Google Play Internal Testing.

Jenkins

Для крупных проектов или команд с нестандартными требованиями. Полный контроль над железом и процессом, но требует администрирования. Мы используем Jenkins, когда проект требует специфической конфигурации сборочной машины или когда GameCI не покрывает нужный сценарий (например, консольные платформы).

Временные рамки планирования

Итого до начала полноценного производства: 4–6 недель. Это не бюрократия — это страховка от переписывания.