В AAA-играх 2026 года поведение NPC описывают конечные автоматы, Behavior Tree, эвристики и «тонна ифов». Именно так формулирует ситуацию автор разбора «Не делайте NPC умнее игрока» на Habr: в современных крупнобюджетных проектах машинное обучение спокойно используют для графики, звука и генерации контента, но ядро принятия решений NPC остаётся классическим.
Причина не в том, что индустрия не заметила нейросети. Задача игрового AI отличается от задачи «построить сильного противника»: дизайнеру нужно поведение, которое игрок читает, предсказывает и побеждает с удовольствием. Оптимальный солдат, всегда выбирающий лучшую тактику, ломает игровой опыт быстрее, чем любой баг.
Оговорка по источникам: разбор на Habr разбирает классические системы и не касается обучения с подкреплением, LLM-NPC и гибридных архитектур. Всё, что ниже говорится об этих подходах, - инженерная логика и известные свойства методов, а не результаты чьих-либо замеров. Отдельно отметим: тезис «в AAA-проектах 2026 года NPC по-прежнему управляются конечными автоматами» опирается на один публичный разбор, а не на отраслевой опрос или серию технических докладов студий. Так что это скорее наблюдение автора, согласующееся с общей практикой, чем измеренная статистика по индустрии.
Почему в 2026 году NPC всё ещё на конечных автоматах
Ответ в одну строку: классические системы дают управляемое поведение с понятной ценой ошибки. Нейросеть добавляет адаптивность, но вместе с ней приходят недетерминированность, расходы на инференс и отладка, для которой нужен отдельный инструментарий. Когда встаёт вопрос «что сейчас должен делать этот конкретный NPC», старый switch по состояниям всё ещё считается лучшим инженерным решением.
Типичное описание поведения NPC выглядит так: если игрок достаточно близко, надо его атаковать; если игрок убежал, стоит немного поискать и покричать; если поиск затянулся, персонаж делает вид, что ничего не заметил, и уходит заниматься своими делами. Живность в играх работает на эвристиках по той же схеме, например охраняет сундук с лутом (разбор на Habr).
Pragmata и PUBG в исходном разборе упоминаются как примеры современных AAA-проектов с таким подходом. Однако отдельных технических докладов или интервью разработчиков этих студий, где описывалась бы их система управления NPC, найти не удалось. Поэтому воспринимать эти названия стоит как иллюстрацию из одного источника, а не как подтверждённый разбор их архитектуры.
Что такое конечный автомат в разработке игр и почему он не устарел
Конечный автомат (FSM) - это список состояний и таблица переходов между ними. Для боевого NPC набор обычно выглядит так: Patrol, Alert, Chase, Attack, Search, Return. В коде это switch по текущему состоянию плюс несколько условий перехода, где каждое условие проверяется на конкретных числах: радиус агра 12 метров, угол обзора 120 градусов, время поиска 30 секунд.
Свойства, за которые FSM держат в продакшене, вполне прагматичны:
- детерминизм: при одинаковых входах поведение повторяется, а баг воспроизводится по логу;
- объяснимость: видно, в каком состоянии NPC находится и почему туда попал;
- правка без обучения: дизайнер меняет число в редакторе и сразу видит результат;
- нулевая стоимость инференса: тысяча NPC не грузит GPU отдельной моделью.
Отладочный оверлей с текущим состоянием и таймером в этом состоянии снимает большинство вопросов вида «почему бот застрял». Никакая нейросеть такого оверлея по умолчанию не предлагает.
Behavior Tree и эвристики: чем они отличаются от нейросетей
Behavior Tree описывает поведение иерархией узлов: selector выбирает первую успешную ветку, sequence выполняет шаги по порядку, декораторы добавляют условия вроде «проверить укрытие перед атакой», а blackboard хранит общее состояние группы. Дерево масштабируется лучше автомата: поддеревья переиспользуются между классами NPC, а новая ветка не ломает уже проверенные сценарии.
Эвристики - самый дешёвый уровень: одно-два правила без структуры. Животное, охраняющее сундук с лутом, вполне обходится формулой «если игрок ближе N метров, перейти в агрессию, иначе вернуться на точку».
Разница с нейросетью проявляется в момент ошибки. У FSM и Behavior Tree решение выводится из явных правил, и его можно прочитать. У сети решение выводится из весов, и чтобы понять причину странного поступка, нужен анализ данных и логов обучения. Классические системы платят за это меньшей гибкостью, нейросети дают адаптивность в обмен на контроль.
| Подход | Что задаёт | Предсказуемость | Отладка | Где уместен |
|---|---|---|---|---|
| Конечный автомат | Состояния и переходы | Высокая | По состоянию видно причину | Бой, патрули, скриптовые сцены |
| Behavior Tree | Иерархию задач и приоритеты | Высокая | По дереву видно ветку | Сложное поведение группы |
| Эвристики | Простые правила | Высокая | Одна формула | Животные, фоновые NPC |
| Обучение с подкреплением | Максимизацию награды | Низкая | Через анализ награды и логов | Исследования, узкие подзадачи |
| LLM | Текст и структурированные вызовы | Средняя | Зависит от промпта и контекста | Диалоги, озвучка, реакции на реплики |
Почему обучение с подкреплением не спасает: функция награды и нежелательные стратегии
Обучение с подкреплением (RL) строит поведение из награды. Агент максимизирует сумму награды за эпизод, и интересность поведения для игрока в эту формулу никак не входит. Как только цель описана формально, находится дешёвый способ её достичь, и он редко совпадает с задумкой дизайнера.
Важная оговорка: конкретные примеры ниже - это разбор типовых сценариев оптимизации, а не результаты опубликованных замеров на конкретных играх. Публичных рецензируемых исследований, где такие стратегии были бы зафиксированы именно для NPC в AAA-проектах, в рамках подготовки материала найти не удалось. Механика при этом хорошо известна в RL в целом: агент эксплуатирует формулировку награды, а не замысел автора.
Как функция награды приводит к абсурдному поведению NPC
Механика предсказуема, если смотреть на неё как на задачу максимизации:
- награда за выживание: агент учится избегать боя, прятаться за укрытиями и отступать. Формально он жив и эффективен, для игрока он скучен и невовлекающ;
- награда за близость к игроку: NPC держит оптимальную дистанцию бесконечно. Вместо боя получается бесконечное преследование без развязки, и encounter не завершается;
- награда за нанесённый урон без штрафа за потери: агент идёт в размен, игнорируя укрытия и союзников, потому что смерть стоит дешевле награды.
Это не баг реализации, а следствие оптимизации: агент находит эксплойт в самой постановке задачи. Лечится это не подбором гиперпараметров, а переписыванием награды под игровой опыт: штраф за выход из зоны боя, бонус за участие в перестрелке, завершение эпизода после определённого времени. Чем сложнее награда, тем важнее проверять агента на поведение, которое игрок воспримет как поломку.
Почему таймер на 30 секунд лучше обученной нейросети
В состоянии Search нужен один эффект: игрок видит, что его ищут, и получает шанс уйти или подготовиться. Это решается атрибутом «время поиска». NPC теряет цель из виду, ищет заданное число секунд, затем возвращается к патрулю. Поведение воспроизводится в багрепорте, правится одним числом, не требует датасета, обучения и валидации, не занимает GPU и не деградирует после патча карты.
У RL в этой же точке есть скрытая цена: нужен стабильный эпизод, метрика качества, защита от эксплойтов и повторное обучение при любом изменении уровня. Простое правило проигрывает только там, где поведение должно быть по-настоящему адаптивным, например при перестроении группы под нестандартную тактику игрока. Начинать стоит с таймера. Если он решает задачу, обучение не нужно.
Где ML действительно работает в играх: рендеринг, анимация, звук и генерация контента
Разработчики используют ML для отдельных частей графического пайплайна, обработки звука и генерации контента, и там же остаются классические системы управления NPC (источник). Причина в характере задач: в этих областях нет требования к единственно правильному решению, есть требование к правдоподобному результату при заданном бюджете кадра или времени сборки.
ML в рендеринге и анимации: почему это не игровой AI
Апскейлинг кадра (DLSS и аналоги), шумоподавление трассировки лучей, motion matching для подбора анимационного кадра по траектории и скорости персонажа, ML-мимика: все эти системы улучшают картинку. Ошибка оценивается глазами и не влияет на игровую логику. Если апскейлер смазал текстуру, это заметно и правится настройками. Если решение о бое принимает сеть с непонятным поведением, ломается геймплей, а не картинка.
Ещё одно отличие: таргетинг графики допускает вероятностный результат между запусками, тогда как логика боя должна повторяться при одинаковых входах, иначе тестирование и балансировка превращаются в угадывание.
Генерация контента и звук: где ML уже приносит пользу
ML-инструменты применяют для текстур, вариаций окружения, черновой озвучки и звуковых слоёв. Ни один из этих результатов не уходит в билд без проверки человеком: арт-директор отбирает ассеты, звукорежиссёр чистит дорожки. Генерация кода и уровней с одного промпта тоже работает, но нуждается в приёмке: разбор генерации клона Super Mario Bros через one shot промпт показывает, что выданный код приходится читать и проверять перед запуском.
LLM-NPC: генеративный слой для диалогов, но не для решений
Языковые модели хорошо работают с текстом и плохо подходят на роль арбитра в реальном времени. Реплика NPC - это текст, и её генерация укладывается в допустимую задержку, особенно на локальной модели. Решение «атаковать или отступить» требует ответа за миллисекунды, повторяемости при одинаковых входах и возможности объяснить, почему бот повёл группу именно в этот коридор.
Почему LLM не заменяют FSM в ядре принятия решений
Причины инженерные, а не идеологические. Точных бенчмарков задержки и стоимости инференса применительно к NPC в рамках подготовки материала найти не удалось, поэтому ниже - оценка порядка величин, а не измеренные цифры:
- задержка и стоимость: вызов модели на каждого NPC в каждом тике не укладывается в кадровый бюджет, а на сотнях NPC превращается в отдельную статью расходов;
- недетерминированность: одинаковый контекст не гарантирует одинаковый ответ, а багрепорт «бот повёл себя странно» невозможно воспроизвести;
- галлюцинации: персонаж может сослаться на квест, которого нет, или на погибшего союзника;
- устойчивость контекста: память диалога быстро растёт, и её нужно чем-то чистить;
- внешнее воздействие: если игрок может вводить текст, он может попытаться вывести NPC из роли, а защита промпта не даёт гарантий уровня кода.
Function calling частично снимает проблему: модель возвращает структурированный вызов, а не свободный текст, и код проверяет, допустимо ли это действие сейчас. Проект NPC-Playground на движке Cubzh показывает этот слой в работе: LLM с function calling реагирует на действия игрока в 3D-сцене. При этом решения верхнего уровня всё равно остаются за кодом. Другой характерный пример - агент на Qwen, играющий в World of Warcraft через кастомный MCP: там требования к скорости и стабильности модели выходят на первый план, потому что цена ошибки - потеря управления персонажем.
Гибридный подход: LLM для диалогов, FSM для действий
Практичная схема выглядит так: FSM или Behavior Tree владеет состояниями NPC, а LLM вызывается только в точке контакта с игроком. Модель получает короткий контекст (кто перед ней, что только что произошло, какие темы запрещены) и возвращает реплику плюс максимум один тег из разрешённого списка: «дружелюбен», «подозревает», «враждебен». Код проверяет тег, меняет состояние и передаёт управление дальше. Решение атаковать принимает автомат, а не генератор текста.
Warrior Quest повторяет эту логику с другой стороны: локальная LLM отвечает за NPC и диалоги, а квесты, канон и состояние мира держит игровой код. Отсюда и ориентир по железу в 8 ГБ VRAM: модель обслуживает диалоги, а не боевую логику, поэтому требования к ней куда мягче, чем у системы, которая должна выдавать решения каждый кадр. Это ориентир из описания проекта, а не результат независимого тестирования: фактическая планка зависит от размера модели, квантизации и длины контекста.
Почему гибридный подход практичнее замены всего игрового AI одной нейросетью
Полная замена упирается в три бюджета: кадровый (миллисекунды на кадр при десятках активных NPC), денежный (инференс на каждого персонажа на игрока) и человеческий (время на отладку и валидацию). Ни один из них не масштабируется бесплатно вместе с ростом количества NPC на экране.
Инженерные преимущества классических систем: отладка и предсказуемость
FSM и Behavior Tree дают то, чего нейросеть не даёт без дополнительной обвязки: лог состояний, пошаговое воспроизведение бага, юнит-тесты на переходы, доступ дизайнера к параметрам через редактор. Если NPC ведёт себя странно, вы смотрите текущее состояние и видите причину за секунды.
У модели вместо этого - версия весов, набор данных, метод обучения и метрика. Обновление любой из частей меняет поведение сразу во всех сценах, включая те, что уже прошли приёмку. Для команд из сотен человек с жёсткими сроками это отдельный источник риска: проверить заново приходится не одну ветку дерева, а весь диапазон ситуаций.
Когда нейросети всё же могут заменить классические системы
Есть сценарии, где замена оправдана:
- узкая подзадача вместо всего AI: анимационный контроль, навигация в сложной геометрии, оценка угрозы;
- малое количество NPC и низкая цена ошибки: инди-проекты, прототипы, экспериментальные сцены;
- неигровые персонажи, чья ценность именно в вариативности реплик, а не в тактике боя;
- офлайн-инференс на локальной модели, когда качество диалога важнее скорости реакции.
В крупнобюджетном проекте с сотнями NPC, требованием к 60 fps и обязательной воспроизводимостью багов такие замены делают точечно, а не целиком для всего игрового AI.
Что это значит для разработчиков: практические выводы
Рабочая логика выбора выглядит так:
- Ядро принятия решений оставляйте на FSM, Behavior Tree и эвристиках. Их видно в отладчике, их правят числами, они не тратят GPU.
- ML применяйте там, где ошибку оценивают глазами: рендеринг, анимация, звук, генерация ассетов. Там вероятностный результат допустим.
- LLM используйте как генеративный слой: диалоги, озвучка, реакции на реплики. Ограничивайте её списком разрешённых действий и проверяйте результат кодом, а не доверием к промпту.
- Награду в RL формулируйте от игрового опыта, а не от абстрактной эффективности, и заранее продумывайте штрафы за эксплойты вроде вечного отступления.
- Сначала пробуйте простое правило: таймер поиска, радиус агра, ограничение на длительность боя. Обучение оправдано, когда простое правило уже не даёт нужного эффекта и есть метрика, чтобы это доказать.
Игровой AI решает не задачу оптимизации, а задачу впечатления. NPC должен вести себя понятно, читаемо и интересно, и именно поэтому в 2026 году конечные автоматы никуда не уходят: они остаются самым дешёвым способом получить предсказуемый результат, который дизайнер контролирует до последнего числа.