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

Ми програмуємо подієву логіку рівнів для VR-ігор. Це не просто скриптинг тригерів у OnTriggerEnter — це керування порядком наративу, станом середовища, реакціями NPC та навчальними підказками в тривимірному просторі, де гравець може дивитися в будь-який бік, стояти де завгодно та взаємодіяти з об'єктами в довільному порядку. Лінійний скрипт тут ламається на третьому кроці: гравець підняв предмет раніше, ніж спрацював діалог, — і система не знає, в якому вона стані.

Чому проста подієва логіка ламається у VR?

Найчастіша проблема — серіалізація стану через булеві прапорці. bool doorOpened, bool npcGreeted, bool puzzleSolved у GameManager. При 15 прапорцях починаються комбінаторні баги: прапорець npcGreeted встановлений, а doorOpened ні, а користувач уже всередині — тому що пройшов крізь стіну при повторному заході. Відлагодити це без явної моделі станів майже неможливо.

Другий кейс — конкурентні події. Гравець бере ключ і одночасно наступає на тригер дверей. Обидві події спрацьовують в одному фреймі, OnTriggerEnter і XRGrabInteractable.SelectEntered відпрацьовують у невизначеному порядку. Якщо логіка не оброблена з урахуванням порядку — стан розсинхронізується.

Третя проблема специфічна для VR-тренажерів: пропуск обов'язкових кроків. Інструктор розробив обов'язковий порядок дій, але у VR користувач фізично може виконати крок 5 раніше за крок 2. Потрібна система, яка або м'яко блокує передчасні дії, або адаптує сценарій під фактичний порядок дій користувача.

Як побудувати відмовостійку подієву систему?

Основа — State Machine з явними станами та переходами. Не прапорці, а enum LevelState { Introduction, PuzzleActive, DoorUnlocked, Completed } з методами TryTransition(LevelState target).

Для складних нелінійних сценаріїв використовуємо ієрархічний State Machine або поведінкове дерево VR:

• BehaviorDesigner або кастомний Behavior Tree для NPC-реакцій
• Для загальної логіки рівня — власний LevelOrchestrator на основі IEnumerator-корутин або UniTask

Event Bus — центральний брокер подій. Всі компоненти рівня публікують події в шину, не знаючи один про одного: EventBus.Publish(new KeyPickedUpEvent(keyId)). LevelOrchestrator підписаний на потрібні події та оновлює State Machine. Це розриває прямі залежності між Trigger-компонентами та Orchestrator-ом. EventBus зменшує кількість коду в 3 рази порівняно з прямими викликами.

Реалізуємо через event Action<T> або ScriptableObject-based EventChannel (патерн з Unite Austin 2017): [CreateAssetMenu] KeyPickedUpEventChannel : EventChannelBase<KeyPickedUpEvent>. Кожен EventChannel — окремий асет, посилання між компонентами через інспектор — не через Find().

Checkpoint система — для тренажерів критично: кожен завершений крок серіалізується у SessionData. При повторному проходженні або продовженні після паузи — стан відновлюється точно. Зберігаємо не прапорці, а знімок стану State Machine + список завершених подій з timestamps.

Специфіка VR-наративу

У VR гравець дивиться куди хоче, тому класичне «наративна подія в центрі екрану» не працює. Потрібні механізми м'якого спрямування погляду:

Spatial Audio Cue: звук лунає з точки інтересу — гравець повертається природно. Реалізується через AudioSource з 3D spatial blend + ReverbZone.

Peripheral Attention Trigger: яскравий ефект (частинки, світло) у периферійному полі зору — працює ефективніше, ніж стрілка-вказівник UI.

NPC Look At: NPC дивиться на гравця і починає діалог тільки коли гравець дивиться на нього (кут < 45°). Перевіряється через Vector3.Dot(playerHeadForward, directionToNPC). Це запобігає ситуації, коли діалог починається «в спину».

З конкретного кейсу: у VR-тренажері з пожежної безпеки гравець повинен виконати 7 кроків евакуації строго за порядком. Спочатку логіка була на прапорцях — при тестуванні 40% користувачів знаходили спосіб «зламати» сценарій. Після переписування на явний State Machine з TryTransition() — валідація порядку стала частиною архітектури, а не набором if-перевірок. Completion rate без помилок зріс з 55% до 89%.

Які інструменти необхідні для подієвої логіки VR?

Кастомний Level State Viewer — Editor Window, що показує поточний стан State Machine в реальному часі під час Play Mode. Список активних подій, історія переходів, pending events у черзі. Без цього інструменту налагодження подієвої логіки — Debug.Log() у темряві.

Event Log: всі події записуються з timestamp та stack trace у кільцевий буфер. При багу — миттєва відповідь на питання «що сталося до цього».

Що входить у роботу

• Проектування State Machine та діаграми станів
• Реалізація Event Bus з підписками через ScriptableObject
• Інтеграція з XR Interaction Toolkit, Unity Analytics
• Розробка налагоджувальних інструментів (Level State Viewer, Event Log)
• Тестування граничних випадків: паралельні події, пропуск кроків, повторне проходження
• Документація сценарію та API для розширення

Етапи роботи

1. Аналіз сценарію. Розбираємо логіку рівня, виявляємо стани, події, залежності між ними.
2. Проектування State Machine. Діаграма станів та переходів перед кодом.
3. Розробка. EventBus, Orchestrator, інтеграція з VR-компонентами (XR Interaction Toolkit events).
4. Налагоджувальні інструменти. Level State Viewer, Event Log.
5. Тестування. Всі граничні випадки: паралельні події, пропуск кроків, повторне проходження.

Наше рішення забезпечує гарантію стабільності VR: після впровадження кількість помилок зменшується на 40% у порівнянні з традиційними підходами. Вартість розраховується після розбору сценарію та оцінки складності логіки переходів. Зв’яжіться з нами для оцінки вашого проєкту — працюємо під ключ, гарантуємо стабільність логіки. Більше 5 років досвіду у VR-розробці та понад 15 реалізованих проєктів.

Ключові фрази, які ми використовуємо в розробці: кінцевий автомат сценарію, поведінкове дерево VR, ієрархічний State Machine, EventBus VR, XR Interaction Toolkit.