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

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

VR-гра, написана без продуманої архітектури, перетворюється на нетронуте мінне поле до третього місяця розробки. Всі класи знають про всі класи, XR Origin напрямку викликає GameManager, який дергає AudioManager, який з якоїсь причини зберігає ссилку на Player — та при спробі додати підтримку другої платформи вся конструкція вимагає переробки з нуля.

VR додає до звичайних архітектурних проблем специфічні: декілька джерел вводу (лівий контролер, правий, hand tracking, gaze), платформозалежні API (OpenXR vs OVR vs SteamVR), жорсткі вимоги до framerate, та необхідність ізолювати платформенний код від ігрової логіки.

Ключові архітектурні рішення для VR

Абстракція над XR-вводом — перше та найважливіше рішення. Якщо ігрова логіка напрямку працює з OVRInput.Get(OVRInput.Button.PrimaryIndexTrigger), портування на іншу платформу потребує правки кожного місця, де є ввід. Правильний підхід: Input Abstraction Layer — інтерфейс IXRInputProvider з методами GetGripAxis(), GetTriggerAxis(), GetPrimary2DAxis(), та окремі реалізації під кожну платформу/SDK. Ігрова логіка знає тільки про інтерфейс.

У Unity це нативно підтримується через OpenXR + Input System: InputActionAsset з binding'ами під різні пристрої, InputAction з callbacks. Один InputActionAsset з двома binding paths працює на будь-якій OpenXR-сумісній платформі без додаткового коду.

Система взаємодій (Interaction System) — другий ключовий шар. XR Interaction Toolkit надає IXRInteractable та IXRInteractor інтерфейси, але для складних проектів недостатньо. Потрібна кастомна система подій: InteractionEventBus з типізованими подіями (GrabStarted, GrabEnded, HoverEntered, ActivatePerformed) та можливістю підписки без прямих залежностей.

State Machine для player state — обов'язковий у VR через специфічні стани: Grounded, Teleporting, InMenu, GrabbingObject, UsingTool. Без явного state machine ці стани розповзаються по bool-флагах та починають конфліктувати.

Модульна структура VR-проекту

Робоча модульна архітектура для Unity VR-проекту:

Core — платформонезалежні інтерфейси: IXRInputProvider, ILocomotionController, IHapticController, IHandTrackingProvider. Без залежностей на Unity-специфічні чи XR-специфічні класи, тільки C# interfaces.

Platform — реалізації Core-інтерфейсів: OculusInputProvider, OpenXRInputProvider, SteamVRInputProvider. Платформенний код сконцентрований тут і тільки тут. Bootstrap-компонент на старті сцени визначає активну платформу та реєструє потрібні реалізації через Dependency Injection (Zenject або самодільний IoC-контейнер).

XR — логіка взаємодій: XRInteractionManager, HandPresenceController, GrabSystem, LocomotionSystem. Працює через Core-інтерфейси, не знає про конкретні платформи.

Gameplay — ігрова логіка: механіки, прогресія, ІІ, збереження. Працює через події від XR-шару, не знає про XR напрямку.

UI — всі ігрові інтерфейси через World Space Canvas + UGUI або кастомні spatial UI. Не звертається до Gameplay напрямку — тільки через події або ViewModel-паттерн.

Таке розділення дозволяє тестувати Gameplay-логіку через Unity Test Framework без запуску XR-сесії — через mock-реалізації Core-інтерфейсів.

Продуктивність як архітектурне обмеження

У VR кожне архітектурне рішення оцінюється через призму продуктивності. 90 fps — це бюджет 11 мс на фрейм. Паттерни, які безболісні в звичайних іграх, у VR убивають framerate:

FindObjectOfType<T>() в Update — повний scene scan щокадру. У VR сцені з 500+ об'єктів легко 2–3 мс.

C# allocations у hot path — GC паузи у VR помітні фізично, тому що dropped frame у VR це не просто «підторможивает», це мгновенний motion sickness trigger. У Update/FixedUpdate — нульові аллокації, все через object pool та struct-based events.

Синхронні операції у main thread — завантаження ресурсів, мережеві запити. У VR все асинхронно: AddressableAssets.LoadAssetAsync, async/await з правильним synchronization context.

Job System та DOTS для VR-проектів з великою кількістю фізичних об'єктів або NPC — не просто оптимізація, а архітектурне вимога. IJobParallelFor для розрахунків, які можна векторизувати, розвантажує main thread на 30–50% у типових сценаріях.

Проектування включає документацію, діаграми залежностей та proof-of-concept реалізацію критичних модулів. Вартість розраховується після аналізу вимог.