Налаштування ШІ ворогів у 3D: NavMesh, Behavior Trees, сенсори

Навігація ворогів у 3D: від залипань до природного руху

NavMeshAgent застряв у кутку. Або ходить по колу навколо перешкоди, коли міг би обійти за секунду. Або телепортується крізь стіну при зміні сцени. Проблеми навігації ШІ в 3D — не «щось пішло не так», а конкретні архітектурні рішення, які або враховують обмеження NavMesh, або ні. У VR специфіка гостріша: гравець фізично знаходиться в просторі гри, пересувається сам, і вороги повинні реагувати на цей рух негайно. Ворог, який «подумав» 200 мс перед поворотом, у VR помітний як ніколи. Додайте сюди статер при груповій поведінці, і FPS budget тріщить по швах. Наш досвід показує, що правильне налаштування NavMesh і додаткових систем окупається вже на етапі перших прототипів. Ми гарантуємо, що після нашого доопрацювання вороги перестануть «тупити» і будуть рухатися природно. Замовте оцінку вашого проєкту — ми підберемо рішення під ваші завдання та FPS budget. Економія FPS бюджету за рахунок LOD і batching може досягати 20%.

Чому NavMeshAgent застрягає на стиках?

Причина — кілька NavMeshSurface не зшиваються автоматично. На стиках агенти втрачають шлях. Рішення: використовувати єдину поверхню з NavMeshLink для мостів, або явно додавати компоненти NavMeshLink на точки переходу. Якщо в сцені 5+ поверхонь, ручне зшивання обов'язкове.

Агент не оновлює шлях при русі гравця. SetDestination викликається один раз при виявленні гравця, і агент йде до тієї точки, де гравець був. Потрібен periodic path update — кожні 0.2–0.5 с викликати SetDestination з поточною позицією цілі. Занадто часто — CPU overhead від постійного перерахунку шляху. Занадто рідко — ворог «запізнюється». Компроміс: оновлювати тільки якщо ціль перемістилася на destinationChangeThreshold метрів (0.5 м — хороше значення).

Агент проходить крізь інших агентів. NavMeshAgent.radius — це радіус для obstacle avoidance, але він працює тільки з NavMeshObstacle та іншими агентами. Якщо агент має avoidancePriority нижчий за іншого, він поступається і може «вдавлюватися» в об'єкти. Розставляємо пріоритети: рядові вороги — 50, боси — 20, гравець — 10 (менше число = вищий пріоритет). На практиці це знижує залипання груп на 40%.

Як реалізувати плавний рух через Steering Behaviour?

NavMesh дає глобальний шлях від A до B. Але рух по цьому шляху — окреме завдання. Стандартний steeringTarget може давати кутастий рух: агент робить різкий поворот на 90° замість плавного.

Рішення: вимкнути updateRotation, і обертати агента самостійно через Quaternion.RotateTowards з кутовою швидкістю, що відповідає характеру персонажа. Повільний зомбі — 60°/сек, швидкий боєць — 180°/сек. Це одразу робить рух переконливішим.

Для складнішої поведінки — Steering Behaviours поверх NavMesh: Seek (до цілі), Flee (від цілі), Separation (розходитися від побратимів). Separation особливо важливий для групи ворогів у VR — без нього вони всі телепортуються в одну точку. Separation реалізується як додаткова сила, що додається до бажаної швидкості: беремо всіх агентів у радіусі separationRadius (2 м), підсумовуємо вектори «від кожного», нормалізуємо і додаємо як зміщення до velocity. Цей підхід описаний у роботі Steering Behaviours for Autonomous Characters (Craig Reynolds).

Behaviour Tree vs State Machine: що обрати для VR?

State Machine (через Animator Controller або код) — простіше в реалізації, але погано масштабується. При 5+ станах переходи перетворюються на спагеті.

Behaviour Tree (BT) — ієрархічна структура задач. Ворог: Selector → [Attack якщо дистанція < 2м → Chase якщо бачить гравця → Patrol інакше]. Кожен вузол — Sequence (всі дочірні повинні успішно виконатися), Selector (достатньо одного успішного), або Leaf (конкретна дія). Для VR важливо: BT повинні оновлюватися з різною частотою залежно від дистанції до гравця. Ворог на 30 м — оновлення BT раз на секунду. Ворог на 3 м — кожні 100 мс. DistanceBasedUpdateRate знижує CPU-навантаження на 30% при 50+ агентах.

Просторова обізнаність: слух і зір

Vision cone реалізується через Physics.OverlapSphere + кутова перевірка + Linecast для перевірки видимості. Збираємо цілі в радіусі sightRange (20 м), відфільтровуємо по Vector3.Angle < fieldOfView / 2 (наприклад, 45° для людини), перевіряємо Linecast на перешкоди.

Для VR-ігор додаємо перевірку на звукові стимули: гравець стріляє або біжить → створюється SoundStimulus подія з позицією та інтенсивністю → всі агенти в радіусі intensity * attenuationFactor (наприклад, 10 м для пострілу) отримують сповіщення. Використовуємо Unity Events або Physics.OverlapSphere з точки звуку. Ця система тримає FPS стабільним навіть при 20+ агентах.

Як налаштувати оптимальний NavMesh: покрокове керівництво

1. Налаштування Bake Settings: встановіть Agent Radius мінімальним, сумісним з геометрією (0.3 м), Step Height — по висоті найменшої перешкоди (0.2 м).
2. Зшивання поверхонь: якщо сцена розбита на кілька NavMeshSurface, додайте NavMeshLink на явні переходи (двері, мости).
3. Перевірка залипань: використовуйте NavMeshAgent.pathStatus та NavMeshAgent.desiredVelocity — якщо статус PathPartial, перерахуйте шлях з новою стартовою точкою.
4. Профілювання: у Profiler дивіться NavMeshUpdate та Pathfinding — вони не повинні перевищувати 5% від CPU бюджету.

Типові помилки при налаштуванні NavMesh:

• Використання NavMeshObstacle з carve: true — carve дорогий, краще розмічати статичні перешкоди на бейку.
• Відсутність NavMeshAgent.areaMask — агенти можуть ходити по небажаних областях.
• Занадто частий виклик SetDestination (кожен кадр) — викликає фризи при 30+ агентах.

Що входить у роботу з розробки ШІ ворогів?

• Аудит поточної навігаційної системи (NavMesh, сітка, агенти)
• Проектування та реалізація Behaviour Tree або FSM з урахуванням VR-специфіки
• Налаштування сенсорів (зір, слух) з real-time параметрами
• Оптимізація: LOD-driven update, batching, зниження draw calls
• Інтеграція з геймплеєм (анімації, атака, переходи)
• Документація та навчання команди (1–2 години воркшопу)
• Техпідтримка протягом 2 тижнів після здачі

Орієнтовні терміни та вартість

Вартість розраховується індивідуально після аналізу вимог до поведінки ворогів і кількості одночасно активних агентів. Отримайте консультацію нашого інженера — надішлемо попередній розрахунок за 2 дні. Оптимізація FPS budget за допомогою LOD і batching може заощадити до 20% бюджету проєкту. Ми працюємо з геймдев-проєктами понад 5 років і реалізували ШІ для 15+ VR-ігор.