Проектирование архитектуры программного кода игр

Проектирование архитектуры программного кода игр

Через год разработки без архитектуры происходит следующее: GameManager — класс на 3000 строк, который знает про всё. PlayerController цепляется напрямую к UIManager, потому что «так быстрее». Система квестов вызывает SaveSystem, который вызывает EventSystem, который вызывает QuestSystem — circular dependency, которую невозможно распутать без переписывания половины игры. Новый разработчик в команде боится трогать код, потому что непонятно, что на что влияет.

Это не абстрактная теория — это то, что мы видим в проектах, которые приходят на оптимизацию или масштабирование после 6–12 месяцев активной разработки без архитектурного плана.

Почему модульность критична для игровой архитектуры?

Модульная архитектура — это не про красоту, а про выживание проекта. Когда каждая система изолирована, вы можете менять одну часть, не боясь сломать другую. На практике это означает, что модули не должны знать о существовании друг друга. И бизнес-логика не должна зависеть от Unity-специфичного кода. Второй принцип позволяет тестировать логику через обычные C# unit tests без запуска PlayMode. Если система расчёта урона в RPG — это чистый C# класс без MonoBehaviour — её можно покрыть тестами за час.

Как выбрать между Service Locator и Dependency Injection?

В Unity классический выбор. DI-фреймворки (Zenject/Extenject, VContainer) дают полноценный IoC Container с constructor injection. Это правильно с точки зрения SOLID, но требует дисциплины команды. Service Locator (через статический регистр сервисов) — компромисс: проще в освоении, не требует понимания DI-контейнеров, но теряет преимущество по тестируемости. Для небольших команд (2–4 программиста) часто выбираем VContainer как баланс между строгостью и простотой.

Когда применять Event-driven и State Machine?

Event-driven architecture через ScriptableObject Events — паттерн от Ryan Hipple (Unite 2017): ScriptableObject как канал событий. Компоненты подписываются на GameEvent-ассеты, не зная друг о друге. Player берёт урон → вызывает playerDamagedEvent.Raise(). HUD слушает этот ивент и обновляет HP-бар. VFX-менеджер слушает и спавнит эффект. Никаких прямых ссылок. Это решает проблему связанности и упрощает работу в большой команде — художник может подключить свой эффект к событию без правки кода. State Machine как основа персонажной логики. Hierarchical State Machine (HSM) для AI и Player Controller — не Animator State Machine (это только для анимаций), а отдельная реализация в коде. Явные состояния устраняют «спагетти» из boolean-флагов: isAttacking && !isStunned && canJump && !isReloading.

ECS для высокопроизводительного кода

Unity DOTS (Entities 1.x) оправдан там, где нужно обновлять тысячи объектов: симуляция частиц, RTS с сотнями юнитов, процедурный мир. Вход в DOTS требует полной переработки архитектуры — это не «добавим поверх». Решение принимается в начале проекта.

Структура проекта и разделение ответственности

Мы проектируем архитектуру исходя из двух ключевых принципов: модули не должны знать о существовании друг друга, и бизнес-логика не должна зависеть от Unity-специфичного кода. Наш опыт показывает, что следование этим правилам в 90% случаев предотвращает регрессионные баги при добавлении новых фич.

Типичная слоистая архитектура для Unity-проекта:

• Domain — чистые C# классы: модели данных, бизнес-логика (DamageCalculator, QuestLogic, SaveData)
• Application — Use Cases, координация между доменными сервисами
• Infrastructure — Unity-специфичный код (MonoBehaviour, ScriptableObject, Addressables), сетевые вызовы, сохранения
• Presentation — UI, визуальные эффекты, аудио

Реальный кейс: мобильная стратегия, команда 6 человек. После 4 месяцев разработки — 40% времени уходило на баг-фиксинг побочных эффектов: изменение одной системы ломало другую. Провели архитектурный рефакторинг за 3 недели: ввели VContainer для DI, выделили Domain-слой из GameManager, заменили прямые ссылки между компонентами на ScriptableObject Events. Следующие 2 месяца — ноль регрессионных багов от рефакторинга.

Что входит в работу

Процесс проектирования архитектуры

1. Аналитика — собираем требования: тип игры, команда, сроки, будущие фичи. Архитектура должна соответствовать масштабу — для гипер-казуала с 3 системами и командой 2 человека Zenject избыточен.
2. Проектирование — создаём Architecture Decision Record (ADR) с обоснованием каждого ключевого решения. Почему VContainer, а не Zenject. Почему ScriptableObject Events, а не UnityEvent. Почему Addressables, а не Resources. ADR становится частью технической документации проекта.
3. Реализация — готовим структуру папок, naming conventions, шаблонные классы для основных паттернов. Первые 2 недели — парная разработка с командой для закрепления паттернов.
4. Тестирование — покрываем Domain-слой unit-тестами, проверяем интеграцию через playmode-тесты на критических сценариях.
5. Деплой — CI/CD с проверкой архитектурных правил (например, запрет прямых ссылок между слоями).

Стоимость рассчитывается индивидуально после аудита проекта или концепции.

Свяжитесь с нами для получения консультации или заказа аудита архитектуры вашего проекта. Мы гарантируем прозрачный подход и фиксированные сроки. Обратитесь к нашему опыту — более 50 архитектурных рефакторингов для игр разных жанров.

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

Типичная ситуация: к нам приходит команда после трёх месяцев разработки с вопросом «почему у нас в репозитории 40 гигабайт и Git падает при каждом pull?». Ответ почти всегда один: PNG-текстуры и FBX-файлы закоммичены напрямую без Git LFS, история репозитория раздулась до неработоспособного состояния. Это решается, но переписывание истории в живом проекте — болезненный процесс, которого можно было легко избежать.

Планирование игр — это не про диаграммы Ганта. Это про технические решения первых двух недель, которые не станут проблемами через три месяца.

Почему планирование игр — это не про Ганта?

График работ — только вершина. Настоящее планирование игрового проекта включает:

• жёсткую фиксацию целевых платформ и минимальных требований (например, iPhone 11, 60 fps);
• декомпозицию механик до числовых параметров с версионированием;
• выбор стека, от которого зависит вся архитектура (render pipeline, сеть, ECS);
• настройку инфраструктуры до первого коммита с ассетами.

Без этого «план» — список задач без опоры. Через месяц выясняется, что Unreal-проект сборки под мобильные платформы не тянет, а ECS оказался избыточным для простого раннера. Время потрачено, бюджет ушёл на прототипы, которые нужно переписывать.

Документация: 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, а не как файл. Изменения видны в истории, можно оставлять комментарии, механики связаны между собой перекрёстными ссылками. Технический дизайн и художественный дизайн хранятся отдельными разделами, но ссылаются друг на друга. Каждая механика имеет статус: в разработке, готово, на ревью, заморожено. Это позволяет в любой момент понять реальное состояние проекта без звонков.

Техническая архитектура

Выбор стека — не религия

Выбор между Unity и Unreal разбираем детально в общем разделе каталога. Но на этапе планирования есть несколько смежных решений, критически влияющих на проект:

• Render pipeline в Unity. URP — для мобильных и VR. HDRP — для PC/консолей. Built-in (Legacy) — только если берёте старый проект. Менять pipeline в середине разработки — пересборка всех материалов. Решение принимается в день первого коммита.
• Архитектура игровых объектов. Классический MonoBehaviour против ECS (Entity Component System через Unity DOTS). ECS даёт порядки производительности на тысячах объектов, но резко увеличивает сложность кода. Для гиперкажуальных игр — избыточно. Для стратегий — необходимо.
• Сетевая архитектура. Если мультиплеер планируется — решение принимается до первой игровой механики. Single-player и networked code устроены принципиально по-разному: в сетевой игре каждое изменение состояния должно быть явным и синхронизируемым.

ScriptableObjects как конфигурационный слой

В Unity используем ScriptableObject-ориентированный подход для хранения игровых данных. Конфигурация оружия, параметры врагов, настройки уровней — всё это ScriptableObject-ассеты, а не захардкоженные значения. Это позволяет гейм-дизайнеру менять баланс без участия программиста и без пересборки проекта.

Версионирование и работа с ассетами

Это та область, где большинство небольших команд теряет время самым обидным способом.

Git + Git LFS

Стандартный Git не предназначен для бинарных файлов. Текстура 4K в PNG весит 20–50 MB. Если её коммитить как обычный файл, история репозитория раздувается катастрофически быстро. Git LFS хранит бинарные файлы отдельно, а в 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

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

Perforce

Альтернатива для крупных Unreal-проектов. Epic Games сами используют Perforce. Лучше работает с очень большими репозиториями (сотни гигабайт), нативная поддержка в Unreal Editor. Выше стоимость инфраструктуры и сложность настройки.

Ветвление

Для игровых проектов используем упрощённый Git Flow: main, develop, feature/*, release/*. Правило: в main никогда не коммитится ничего, что не прошло QA. Его нарушение приводит к тому, что «последняя стабильная версия» становится термином без содержания.

CI/CD для игровых проектов

Автоматическая сборка при каждом пуше решает проблему «у меня на машине собирается, у тебя нет». Pipeline включает:

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

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

GameCI — GitHub Actions для Unity. Unity Cloud Build — хостинг от Unity, проще настройки, дороже при большом количестве сборок. Jenkins — полный контроль, используется для консольных платформ.

Что входит в работу

• Документация: техническое задание, GDD (MVP-scope), архитектурная схема, модели данных.
• Настройка репозитория: Git + LFS, правила ветвления, шаблон проекта, соглашения о коде.
• CI/CD: конфигурация сборок под все целевые платформы, автоматическое тестирование.
• Доступы: к репозиторию, CI/CD, баг-трекеру; обучение команды работе с инструментами.
• Поддержка: сопровождение в течение первого месяца разработки — ответы на вопросы, корректировка настроек, ревью архитектурных решений.

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

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

Как планирование игр предотвращает технический долг?

Ошибка в планировании на первом спринте обходится в 10 раз дороже, чем исправление на прототипе. Неправильный выбор стека или отсутствие LFS приводят к пересборке архитектуры, потере коммитов и демотивации команды. Грамотное планирование игр — это инвестиция, которая окупается снижением багов на 30% и ускорением релиза в среднем на 2 месяца.

Оценим ваш проект — свяжитесь с нами, чтобы получить консультацию и детальный план первых шагов. Закажите планирование игрового проекта и избегите типичных граблей, которые мы видим в 90% обращений.