Адаптивна поведінка NPC з RL, гібридними архітектурами та self-play

Класичні скінченні автомати (FSM) та поведінкові дерева (BT) перестають справлятися, коли NPC має адаптуватися до нестандартних тактик гравця. Противник застрягає біля стіни, союзник ігнорує фланговий обхід, пішоходи діють за шаблоном — кожен такий баг потребує правки вручну. У сучасних AAA-проєктах із сотнями типів NPC такий підхід призводить до тижнів налагодження. Зв'яжіться з нами, щоб обговорити ваше завдання та отримати попередню оцінку.

Ми розробляємо системи поведінки NPC з використанням Reinforcement Learning (RL) та гібридних архітектур вже понад 10 років. За цей час реалізували AI для 50+ NPC у шутерах, RPG та симуляторах. Клієнти економлять до $40,000 на бюджеті на ітераціях балансу NPC — інвестиції окупаються за 3–6 місяців. Гібрид BT+RL на 30% швидший у розробці, ніж чистий RL, і на 60% адаптивніший за чистий BT. У 80% проєктів обирають саме гібрид. Ми гарантуємо якість інтеграції та надаємо 30-денну підтримку після деплою.

Чому RL перемагає FSM у сучасних AAA-іграх?

FSM/BT обмеження:

• Розробник описує кожен перехід — при додаванні нової поведінки дерево переписується.
• Edge-кейси (застрягання, однакові патерни) виправляються лише патчами.
• Масштабування на 50+ типів NPC — тижні ручної роботи.

RL переваги:

• NPC навчається на взаємодії з гравцем, адаптуючись до його стилю.
• Єдиний фреймворк для різних типів поведінки: бойові, соціальні, економічні.
• Self-play (навчання проти попередніх версій себе) автоматично генерує складні тактики.

Порівняємо підходи в таблиці:

Як гібрид BT+RL дає контроль гейм-дизайнерам?

Чистий RL у production — рідкість: непередбачуваність неприйнятна для дизайнерів. Гібрид вирішує проблему:

BehaviourTree:
    → Selector:
        → IsPlayerVisible AND HealthHigh → RL AggressivePolicy
        → IsPlayerVisible AND HealthLow  → RL RetreatPolicy
        → PatrolTask (детермінований)

RL-політика відповідає за конкретні фази бою (атака, відступ), BT контролює high-level структуру. Дизайнери керують умовами переходу, RL наповнює деталі — NPC фланкує, використовує укриття, ставить пригнічуючий вогонь.

Стек та приклад реалізації: Unity ML-Agents

Стандартний інструмент для ігрового AI — Unity ML-Agents (PPO, self-play). Приклад компонента агента на C#:

public class NPCCombatAgent : Agent
{
    public override void CollectObservations(VectorSensor sensor)
    {
        sensor.AddObservation(RelativePlayerPosition);
        sensor.AddObservation(PlayerVelocity);
        sensor.AddObservation(Health / MaxHealth);
        sensor.AddObservation(Ammo / MaxAmmo);
        sensor.AddObservation(IsInCover);
        sensor.AddObservation(NearestCoverDistance);
    }

    public override void OnActionReceived(ActionBuffers actions)
    {
        float moveX = actions.ContinuousActions[0];
        float moveZ = actions.ContinuousActions[1];
        bool shoot = actions.DiscreteActions[0] == 1;
        bool takeCover = actions.DiscreteActions[1] == 1;
        MoveNPC(moveX, moveZ);
        if (shoot) Shoot();
        if (takeCover) SeekCover();
    }

    public override void OnEpisodeBegin()
    {
        ResetPosition();
        Health = MaxHealth;
    }
}

Reward-функція для бойового NPC:

void FixedUpdate()
{
    if (DamagedPlayer()) AddReward(1.0f);
    if (TookDamage()) AddReward(-0.5f);
    if (Killed()) AddReward(-10.0f);
    if (KilledPlayer()) AddReward(10.0f);
    AddReward(-0.001f);  // штраф за бездіяльність
}

Self-Play для бойових NPC

Для навчання NPC необхідний противник, здатний створити виклик. Проти random-агента NPC навчиться лише базовим патернам, тому застосовуємо self-play: агент грає проти попередніх версій себе. Офіційна документація Unity ML-Agents підтверджує, що self-play дозволяє безперервно покращувати політику, граючи проти власних копій. Конфіг для ML-Agents:

behaviors:
  NPC:
    trainer_type: ppo
    self_play:
      save_steps: 50000
      team_change: 100000
      swap_steps: 2000
      play_against_latest_model_ratio: 0.5
      window: 10

Self-play забезпечує постійне покращення: немає reward hacking проти конкретної стратегії, тактики стають глибшими.

Observation Design

• Ray Perception: променеві сенсори (до 20 променів) бачать теги об'єктів + відстань. Швидко, ефективно.
• Camera Sensor: CNN обробляє render texture — повільніше, але дає реалістичну «зорову систему».

Типи поведінок для навчання

Тактичні: фланкування, укриття, пригнічуючий вогонь, retreat-and-heal. Соціальні (NPC-жителі): реакція на гравця (страх, цікавість, агресія), адаптація до репутації. Економічні (торговці): ціноутворення на основі попиту, прийняття пропозицій.

Порівняння типів поведінок за складністю реалізації та часом навчання:

Scalable Training

Навчання тисяч NPC паралельно:

from mlagents_envs.environment import UnityEnvironment
from mlagents_envs.envs.unity_parallel_env import UnityParallelEnv

env = UnityParallelEnv(UnityEnvironment("game.x86_64"))
# один step обробляє всіх агентів одночасно

GPU inference: після навчання експорт в ONNX → Barracuda runtime прямо в Unity. Жодного Python на продакшені. Для масштабування використовуємо до 1000 паралельних агентів за один step.

Процес роботи та що входить

1. Аналітика: вивчаємо механіки гри, визначаємо типи NPC та вимоги до поведінки.
2. Проектування: розробляємо архітектуру (BT+RL гібрид, reward-функції, спостереження).
3. Реалізація: навчаємо моделі, інтегруємо в ігровий движок, налаштовуємо inference.
4. Тестування: перевіряємо адаптивність, відсутність багів, відповідність гейм-дизайну.
5. Деплой: експорт в ONNX, оптимізація для цільових платформ (PC, консолі, мобільні).

Результат включає:

• Документацію з архітектури та навчання.
• Вихідні коди агентів та конфігів.
• Навчену ONNX-модель.
• Інтеграцію у ваш проєкт.
• Підтримку протягом місяця.

Терміни орієнтовно

Базовий бойовий NPC з self-play — від 6 тижнів. Повноцінна система з гібридом BT+RL, кількома типами поведінок та production-ready inference — від 14 до 20 тижнів. Вартість стартує від $12,000 та розраховується індивідуально під ваш проєкт. Отримайте консультацію — допоможемо визначити підходящу архітектуру для вашої гри. Замовте розробку NPC AI вже сьогодні та отримайте попередній аналіз протягом 2 днів.

Більше 10 років ми займаємося ML у геймдеві — реалізували NPC AI для шутерів, RPG та симуляторів. Наші сертифіковані спеціалісти гарантують якість. Якщо хочете обговорити ваше завдання, зв'яжіться з нами — оцінимо проєкт та запропонуємо рішення.

Навчання з підкріпленням: PPO, SAC, DQN та промислове застосування

Ми щодня бачимо проєкти, які гинуть не через слабкий алгоритм, а через неправильну винагороду. Інженер пише reward = +1 за правильну дію, запускає навчання, а через 10 млн кроків агент знаходить спосіб отримати максимум, не вирішивши завдання. Це reward hacking — системний біль промислового RL. Наш досвід показує: правильний reward займає 70% успіху.

Чому RL складніше, ніж supervised learning?

У supervised learning є датасет з правильними відповідями. У RL правильної відповіді немає — є скалярний сигнал «краще/гірше», який надходить із затримкою в сотні кроків. Агент сам досліджує простір і знаходить стратегію.

Наслідки: нестабільність навчання, висока чутливість до гіперпараметрів, повільна збіжність. PPO (Proximal Policy Optimization) на Atari сходиться за 10 млн кроків — це години. На роботизованих завданнях з реальною фізикою — дні або тижні в симуляторі.

Чому reward engineering вирішальний для RL?

Без якісної reward-функції навчання перетворюється на лотерею. Reward hacking — класична пастка: агент знаходить неочевидний спосіб максимізувати винагороду, ігноруючи справжню ціль. Один із проєктів — сортування компонентів на PCB — demand: ми витратили 2 тижні на формалізацію reward: штраф за зіткнення, бонус за швидкість, penalty за неправильне розташування. Без цього агент навчився скидати деталі з конвеєра, отримуючи +1 за кожну скинуту, а не за відсортовану.

Як обрати алгоритм під задачу?

Як налаштувати PPO та уникнути типових проблем?

PPO — робоча конячка RL. Основна ідея: обмежуємо оновлення політики через кліпування ratio clip_range=0.2. Це дає стабільність порівняно з vanilla policy gradient. Але без грамотного налаштування агент не сходиться.

Одна з частих пасток — entropy collapse: агент занадто швидко стає детермінованим, перестає досліджувати. Симптом — entropy coefficient падає до нуля. Лікування — ent_coef=0.01–0.05 і не знижувати нижче 0.001. Інша проблема — value function розходиться, коли vf_loss_coef високий, а explained_variance від'ємний. Рекомендуємо vf_coef=0.5 і gradient clipping max_grad_norm=0.5.

Неправильний n_steps також ламає навчання. n_steps=2048 — дефолт Stable‑Baselines3. Для завдань з довгим горизонтом (>500 кроків) потрібно збільшувати, для швидких (10–50 кроків) — зменшувати до 256–512.

Для швидкого старту використовуємо stable‑baselines3 + sb3‑contrib. Для research і кастомних алгоритмів — tianshou або CleanRL.

SAC для безперервного керування

SAC (Soft Actor‑Critic) додає в objective максимізацію ентропії — агент вчиться бути і ефективним, і різноманітним. Це дає відмінну sample efficiency та стійкість до шуму в reward. На задачах керування техпроцесами SAC зазвичай обходить PPO за збіжністю: потребує на 30–40% менше взаємодій для досягнення тієї ж якості. Ключовий параметр — target_entropy. Стандартне значення ‑dim(action_space) часто підходить, але для специфічних завдань краще налаштовувати вручну.

Як перенести навченого агента на реальний пристрій?

Навчати RL на реальному роботі — дорого та небезпечно. Стандартний підхід: навчання в симуляторі → трансфер на реальне залізо. Основна проблема — reality gap: симулятор не відтворює фізику, тертя, шум датчиків.

Головний інструмент — domain randomization. Під час навчання випадково варіюємо параметри середовища: маса об'єктів ±30%, коефіцієнт тертя ±50%, затримка дій 0–100 мс, шум спостережень σ=0.01–0.1. Агент навчається бути робастним до варіацій, і реальний світ стає лише ще однією варіацією.

Порівняння популярних симуляторів:

RLHF: навчання LLM з людського зворотного зв'язку

RLHF став стандартом після InstructGPT. Класична схема: supervised fine‑tuning → reward model → PPO.

Проблеми класичного PPO: нестабільність (KL‑дивергенція може вибухнути), повільна збіжність, складність налаштування. Тому популярні альтернативи:

• DPO — обходить reward model, вчиться на парах уподобань. Простіше, стабільніше, але менш гнучкий.
• GRPO — використовується в DeepSeek‑R1, хороший для reasoning tasks.
• ORPO — об'єднує SFT та alignment в одну стадію.

Бібліотека trl від Hugging Face — стандарт. Підтримує PPO, DPO, ORPO, GRPO з коробки, працює з PEFT/LoRA для memory‑efficient fine‑tuning.

Reward hacking залишається однією з головних причин провалів у RL, поряд з неправильно обраною архітектурою середовища. Це підтверджують дослідження з відкритих джерел (Reward hacking in reinforcement learning, Wikipedia).

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

• Архітектурне рішення та обґрунтування вибору алгоритму
• Розробка та документування reward‑функції
• Створення симулятора або налаштування існуючого
• Навчання, hyper‑parameter sweep (Optuna / Ray Tune)
• Трансфер на реальне залізо або інтеграція в продукт
• Документація, доступи до коду та симуляторів
• Навчання команди та 3‑місячна підтримка після деплою

Процес роботи

1. Аудит завдання — фіксуємо цілі, ресурси, обмеження.
2. Reward engineering — формалізація бажаної поведінки, перевірка на reward hacking.
3. Вибір середовища та алгоритму — baseline, перші прогони.
4. Систематичний hyperparameter sweep — використовуємо Optuna.
5. Навчання в симуляторі з domain randomization.
6. Тестування на реальному обладнанні (за потреби).
7. Деплой, моніторинг, підтримка.

Терміни: proof of concept — 2–4 тижні; production‑система з sim‑to‑real — 3–8 місяців; RLHF для LLM — 4–10 тижнів. Вартість розраховується індивідуально — оцінимо ваш проєкт за 2 дні. Замовте консультацію, щоб уникнути типових пасток RL.

Наша команда — понад п’ять років досвіду в RL, 30+ успішних проєктів у роботиці, оптимізації ланцюгів постачання та LLM alignment. Гарантуємо прозору архітектуру та повну технічну документацію. Зв'яжіться з нами для отримання детальної оцінки вашого проєкту.