Проектування архітектури програмного коду ігор
Через рік розробки без архітектури відбувається наступне: 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 місяці — нуль регресійних багів від рефакторингу.
Що входить в роботу
| Deliverable | Опис |
|---|---|
| Архітектурний план | Схема модулів, залежності, вибрані патерни з обґрунтуванням |
| ADR документація | Запис кожного ключового рішення з контекстом і альтернативами |
| Налаштування DI-контейнера | Інтеграція VContainer/Zenject, реєстрація сервісів, тести контейнера |
| Впровадження івент-системи | ScriptableObject Events, підписки, відписки, дебаг-інструменти |
| Code review і навчання | Парне програмування в перші 2 тижні, шаблони та naming conventions |
| Технічна підтримка | 2 тижні пост-релізної підтримки з питань архітектури |
Процес проектування архітектури
- Аналітика — збираємо вимоги: тип гри, команда, терміни, майбутні фічі. Архітектура має відповідати масштабу — для гіпер-казуалу з 3 системами та командою 2 особи Zenject надлишковий.
- Проєктування — створюємо Architecture Decision Record (ADR) з обґрунтуванням кожного ключового рішення. Чому VContainer, а не Zenject. Чому ScriptableObject Events, а не UnityEvent. Чому Addressables, а не Resources. ADR стає частиною технічної документації проєкту.
- Реалізація — готуємо структуру папок, naming conventions, шаблонні класи для основних патернів. Перші 2 тижні — парна розробка з командою для закріплення патернів.
- Тестування — покриваємо Domain-шар unit-тестами, перевіряємо інтеграцію через playmode-тести на критичних сценаріях.
- Деплой — CI/CD з перевіркою архітектурних правил (наприклад, заборона прямих посилань між шарами).
| Масштаб завдання | Орієнтовні терміни |
|---|---|
| Консультація + архітектурний план (новий проєкт) | 3–7 днів |
| Рефакторинг архітектури існуючого проєкту | 3–8 тижнів |
| Повне проєктування архітектури з документацією | 2–4 тижні |
| Впровадження ECS/DOTS у проєкт | 4–10 тижнів |
Вартість розраховується індивідуально після аудиту проєкту або концепції.
Типові ознаки проблемної архітектури
- GameManager >1000 рядків з різноплановою логікою
- Циклічні залежності між системами
- Неможливість написати unit-тест без запуску всієї сцени
- Кожна зміна потребує правки 5+ файлів
- «Прокляття булевих флагів»: умови на кшталт
if (isAttacking && !isStunned && canJump)розмазані по всьому коду
Зв'яжіться з нами для отримання консультації або замовлення аудиту архітектури вашого проєкту. Ми гарантуємо прозорий підхід і фіксовані терміни. Зверніться до нашого досвіду — понад 50 архітектурних рефакторингів для ігор різних жанрів.