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

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

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

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

Паттерны, которые работают в игровой разработке

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

Event-driven architecture через ScriptableObject Events. Паттерн от Ryan Hipple (Unite 2017): ScriptableObject как канал событий. Компоненты подписываются на GameEvent-ассеты, не зная друг о друге. Player берёт урон → вызывает playerDamagedEvent.Raise(). HUD слушает этот ивент и обновляет HP-бар. VFX-менеджер слушает и спавнит эффект. Никаких прямых ссылок. Это решает проблему связанности и упрощает работу в большой команде — художник может подключить свой эффект к событию без правки кода.

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

State Machine как основа персонажной логики. Hierarchical State Machine (HSM) для AI и Player Controller — не Animator State Machine (это только для анимаций), а отдельная реализация в коде. Для простых случаев — собственная реализация через enum и switch. Для сложных (5+ состояний с переходами) — библиотека типа Stateless или Bolt (Ludiq). Явные состояния устраняют «спагетти» из boolean-флагов: isAttacking && !isStunned && canJump && !isReloading.

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

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

Второй принцип позволяет тестировать логику через обычные C# unit tests без запуска PlayMode. Если система расчёта урона в RPG — это чистый C# класс без MonoBehaviour — её можно покрыть тестами за час. Если она живёт внутри PlayerController.Update() — тестирование требует запуска сцены с персонажем.

Типичная слоистая архитектура для 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 месяца — ноль регрессионных багов от рефакторинга.

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

Начинаем с анализа требований: тип игры, команда, сроки, будущие фичи. Архитектура должна соответствовать масштабу — для гипер-казуала с 3 системами и командой 2 человека Zenject избыточен.

Создаём Architecture Decision Record (ADR) — документ с обоснованием каждого ключевого архитектурного решения. Почему VContainer, а не Zenject. Почему ScriptableObject Events, а не UnityEvent. Почему Addressables, а не Resources. ADR становится частью технической документации проекта.

Готовим проектную структуру папок, naming conventions, шаблонные классы для основных паттернов. Первые 2 недели — парная разработка с командой для закрепления паттернов.

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