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

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

Через год разработки без архитектуры происходит следующее: 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 с проверкой архитектурных правил (например, запрет прямых ссылок между слоями).

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