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

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

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

Чому абстракція введення критична для 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 (<XRController>{LeftHand}/trigger та <OculusTouchController>/trigger) працює на будь-якій 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-флагах у різних компонентах і починають конфліктувати.

Як спроектувати модульну архітектуру під мультиплатформенність?

Робоча модульна архітектура для 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-інтерфейсів.

public interface IXRInputProvider { float GetTriggerAxis(XRHand hand); Vector2 GetPrimary2DAxis(XRHand hand); bool GetGripPressed(XRHand hand); event Action<XRHand> OnTriggerPressed; event Action<XRHand> OnTriggerReleased; } 

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

У 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 для розрахунків, які можна векторизувати (collision checks, proximity queries для grab system), розвантажує main thread на 30–50% у типових сценаріях — це в 2-3 рази ефективніше класичного підходу.

Що входить у проектування архітектури VR-гри

Наші інженери гарантують якість на кожному етапі. У послугу входить:

• Документація: архітектурні діаграми (UML), опис модулів, інтерфейсів та залежностей.
• Proof-of-concept реалізація критичних модулів (наприклад, абстракція введення або система взаємодій).
• Рекомендації щодо вибору стеку та інструментів під ваші платформи.
• Консультації з оптимізації продуктивності (профілювання, budget analysis).
• Підтримка на етапі інтеграції та рев'ю коду команди.

Оцінимо ваш проект за 1-2 дні — зв'яжіться з нами, щоб обговорити деталі. OpenXR гарантує сумісність. Замовте проектування архітектури — ми підготуємо детальний план та POC для вашої VR-гри.

Строки проектування

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