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

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

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

Вартість розраховується індивідуально після аудиту проєкту або концепції.