Программирование событийной логики уровней в VR играх

id: 241 slug: vr-game-level-event-logic-programming title_ru: "Программирование событийной логики уровней в VR играх" tags: [vr-ar]

Программирование событийной логики уровней в VR играх

Событийная логика уровня в VR — это не скриптинг триггеров в OnTriggerEnter. Это управление порядком нарратива, состоянием среды, реакциями NPC и обучающими подсказками в трёхмерном пространстве, где игрок может смотреть в любую сторону, стоять где угодно и взаимодействовать с объектами в произвольном порядке. Линейный скрипт здесь ломается на третьем шаге: игрок поднял предмет раньше, чем сработал диалог, — и система не знает, в каком она состоянии.

Где ломается простая событийная логика в VR

Самая частая проблема — сериализация состояния через булевы флаги. bool doorOpened, bool npcGreeted, bool puzzleSolved в GameManager. При 15 флагах начинаются комбинаторные баги: флаг npcGreeted установлен, но doorOpened нет, а пользователь уже внутри — потому что прошёл сквозь стену при повторном заходе. Отладить это без явной модели состояний почти невозможно.

Второй кейс — конкурентные события. Игрок берёт ключ и одновременно наступает на триггер двери. Оба события срабатывают в одном фрейме, OnTriggerEnter и XRGrabInteractable.SelectEntered отрабатывают в неопределённом порядке. Если логика не обработана с учётом порядка — состояние рассинхронизируется.

Третья проблема специфична для VR-тренажёров: пропуск обязательных шагов. Инструктор разработал обязательный порядок действий, но в VR пользователь физически может выполнить шаг 5 раньше шага 2. Нужна система, которая либо мягко блокирует преждевременные действия, либо адаптирует сценарий под фактический порядок действий пользователя.

Архитектура событийной системы для VR-уровней

Основа — конечный автомат сценария (Level State Machine) с явными состояниями и переходами. Не флаги, а enum LevelState { Introduction, PuzzleActive, DoorUnlocked, Completed } с методами TryTransition(LevelState target).

Для сложных нелинейных сценариев используем иерархический State Machine или Behavior Tree:

• BehaviorDesigner или кастомный BT для NPC-реакций
• Для общей логики уровня — собственный LevelOrchestrator на основе IEnumerator-корутин или UniTask

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

Реализуем через 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%.

Отладка и инструменты

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

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

Этапы работы

Анализ сценария. Разбираем логику уровня, выявляем состояния, события, зависимости между ними.

Проектирование State Machine. Диаграмма состояний и переходов перед кодом.

Разработка. EventBus, Orchestrator, интеграция с VR-компонентами (XR Interaction Toolkit events).

Отладочные инструменты. Level State Viewer, Event Log.

Тестирование. Все граничные случаи: параллельные события, пропуск шагов, повторное прохождение.

Стоимость рассчитывается после разбора сценария и оценки сложности логики переходов.