Технический разбор NPC

Пост посвящён текущему состоянию NPC-фреймворка Hytale: как он устроен сейчас, как выглядит на практике и в каком направлении команда хочет его развивать. Тема местами техническая, поэтому некоторые фрагменты можно спокойно пролистывать — систем вокруг NPC много, и один материал не сможет охватить вообще всё.

Где мы сейчас

На данный момент NPC-фреймворк поддерживает множество типов поведения сразу в нескольких подсистемах. Всё это настраивается через data-driven ассеты: чтобы собрать поведение, не нужно знать языки программирования — даже самые сложные NPC у разработчиков почти полностью описываются данными.

В этом разборе выделены две ключевые части: Roles (сердце поведения NPC) и Combat Action Evaluator.

Документация и обучение

Тем, кто хочет глубже разобраться в NPC, разработчики рекомендуют документацию от сообщества hytalemodding, а также подготовленные материалы:

1. документация по NPC
2. письменный туториал

Вдобавок к туториалу есть видеосерия из 6 частей:

1. Руководство по NPC. Часть 1
2. Руководство по NPC. Часть 2
3. Руководство по NPC. Часть 3
4. Руководство по NPC. Часть 4
5. Руководство по NPC. Часть 5
6. Руководство по NPC. Часть 6

Roles (роли NPC)

У каждого NPC есть роль. Именно роль задаёт общее поведение и то, как персонаж реагирует на разные стимулы в мире. Поменять весь набор поведения можно буквально заменой роли, а для ускорения работы есть набор шаблонов (templates) с настраиваемыми параметрами — это помогает быстро и эффективно создавать новых NPC.

Роль определяет не только поведение, но и, например, то, как NPC двигается, какие предметы носит, как выглядит и так далее.

«Списки инструкций» вместо привычных деревьев поведения

Технически поведение описывается тем, что разработчики называют instruction lists («списки инструкций»). Это похоже на decision trees/behaviour trees, но с упрощённой семантикой. Каждая инструкция состоит из:

1. sensor — элемента, который опрашивает состояние игры и решает, можно ли выполнить инструкцию;
2. actions/motions — действий или движений, которые NPC делает при выборе инструкции.

Вместо действий/движений можно вложить ещё один список инструкций — так поведение становится более «слоёным» и сложным, если это нужно.

Если вы знакомы с behaviour trees, логично спросить: в чём разница? Сенсоры здесь отчасти похожи на декораторы, а структура тоже древовидная. Главное отличие — как именно список обходится: вместо разных правил для разных типов узлов всегда используются семантики fallback selector node. Инструкции проверяются по порядку, и первая подошедшая — выполняется.

Если в инструкции не выставлены специальные флаги, остальные инструкции ниже по списку уже не проверяются. Это делает логику NPC проще для чтения и сопровождения, даже когда деревья становятся большими и глубокими.

JSON для конфигурации, Java для элементов

Отдельные типы элементов (сенсоры, действия, движения и т. п.) пишутся на Java, но сами списки инструкций собираются полностью в JSON. На текущем этапе у команды есть больше 150 типов элементов, из которых можно комбинировать поведение, и предусмотрен фреймворк, позволяющий моддерам добавлять новые элементы через Java. Не все элементы ещё доведены до финального состояния, но разработчики активно их дорабатывают и расширяют набор.

Фреймворк специально проектировали так, чтобы с ним можно было работать на разных уровнях: и новичкам в моддинге/NPC-дизайне, и опытным авторам сложного поведения.

Пример: «овца-хищник»

Разработчики показывают пример, как сменой роли можно превратить овцу из мирного «домашнего» поведения (Livestock), основанного на Template_Animal_Neutral, в агрессивное существо с помощью Template_Predator.

И после этого она переходит от дружелюбного поведения к атакам.

С базовыми шаблонами можно даже выдать ей случайное оружие — и, по словам автора, получается готовая основа для мода в духе «Die Hard Sheep».

Combat Action Evaluator (оценщик боевых действий)

Instruction lists уже дают дизайнерам большую свободу в настройке NPC и их боевого поведения. Но как только нужно сделать бойца, который умеет больше пары простых ударов и должен выбирать, когда применять конкретные приёмы, конфигурация быстро становится громоздкой.

Combat action evaluator создан, чтобы закрыть эту потребность: это «спутниковый» фреймворк для центрального поведения NPC, который помогает принимать умные решения «здесь и сейчас» — учитывая состояние самого NPC, окружающего мира, а также врагов/союзников.

Каждому возможному удару (или другому боевому действию) назначается набор условий: например, когда мало HP, когда враг близко, когда игрок пытается зайти со спины. Далее условия оцениваются, действия «взвешиваются» друг относительно друга — и NPC выбирает то, что считает лучшим вариантом.

Такой подход добавляет NPC некоторую «нечёткость» (fuzziness): с меньшим количеством подробных настроек можно получить более интересные боевые ситуации. Минусы тоже обозначены: входной порог выше, NPC иногда ведут себя не так, как вы ожидали, и система менее производительная (разработчики хотят улучшить это итерациями).

В качестве примера приводится Skeleton Praetorian, который с некоторой «разумностью» выбирает разные способности: блокирование, призыв на низком здоровье, рывок/чардж — вместе с базовыми атаками.

Ниже показан фрагмент конфигурации части условий для способности призыва:

Также в оригинале упоминается видео-пример, где можно увидеть, как эти решения работают в бою.

Проверка реальностью

Звучит так, будто всё уже почти готово к релизу — но автор прямо говорит: нет. У системы всё ещё много шероховатостей, недостающих функций и областей, которые требуют серьёзного улучшения.

Инструменты (tooling) — слабое место. Планируются визуальное редактирование и отладка, но сейчас большая часть конфигурации NPC делается прямо в JSON через текстовые редакторы. Работать можно, но это больно. Возможности дебага есть, но они не интуитивны и часто требуют пролистывать огромные логи.

Порог входа — проблема не только у combat action evaluator: в целом работа с NPC остаётся сложной. В будущем хотят более мягкое и понятное «введение» в NPC-моддинг, но пока доступно лишь ограниченное число шаблонов, документация по элементам и простые туториалы.

Есть и крупные «дыры» по функциям: NPC плохо позиционируются в бою, не используют нормальное избегание/«стайность» (avoidance/flocking), летающие NPC умеют садиться и взлетать, но плавающие не могут выйти из воды (и наоборот). И это только часть списка.

Возможные проблемы с производительностью тоже реальны. Игра может поддерживать довольно большое число NPC, но ещё много работы по оптимизации — особенно в части pathfinding. Разработчики стараются держать поиск пути выключенным как можно чаще, иначе производительность может сильно просесть.

Плюс технический долг: например, NPC пока не могут целенаправленно ломать блоки (кроме взрывов снарядов) из‑за ограничений некоторых «не-NPC» систем, которые нужно пересматривать (зато ставить блоки они могут). Физику NPC тоже нужно капитально переработать, чтобы корректно унифицировать её с системами игрока. И это ещё без разговора о спавне.

Баги, баги повсюду

Сообщество отмечало множество багов в опубликованных геймплейных роликах. Автор уточняет: с текущими темпами разработки многие из этих видео уже устарели, а самые критичные баги исправлены. Но отдельно он хочет остановиться на проблеме pathfinding, её сложности и возможных последствиях для релиза.

Pathfinding — большая и сложная тема, с которой тяжело даже многим обычным играм. А в процедурном, полностью изменяемом, блочном мире это ещё сложнее: нельзя полагаться на многие трюки оптимизации, рассчитанные на заранее известный ландшафт.

Поэтому текущий pathfinding в Hytale сейчас медленный. Не настолько, чтобы вызывать заметные проблемы производительности, но достаточно, чтобы разработчики не могли позволить всем NPC использовать его постоянно, и накладывают жёсткие ограничения на возможности. Пример: из‑за этого cave raptors не перепрыгивают пропасти, преследуя игрока.

Нельзя заранее «засеять» мир jump points, потому что мир меняется в любой момент, а каждый дополнительный блок дистанции прыжка через разрыв сильно увеличивает стоимость поиска.

Разработчики не ожидают, что это успеют полностью изменить к релизу раннего доступа, но обещают серьёзно улучшать pathfinding и уже начали работу над новым методом, который потенциально может снять большую часть проблем — если подтвердит свою жизнеспособность.

Что дальше

Tooling — в верхней части списка приоритетов. Чтобы нормально поддерживать моддеров, нужны инструменты, которые сделают создание NPC действительно увлекательным. Полный набор средств отладки появится не сразу, но команда соберёт всё, что сможет.

Также нужно решать проблемы pathfinding и перемещения, параллельно разгребая технический долг — чтобы не создавать узкие места по производительности, когда игроки сталкиваются с несколькими NPC в сложных окружениях. Это важно, чтобы бои ощущались приятно даже на ранней стадии.

Дополнительные шаблоны (templates) должны «оживить» мир: уникальные поведения добавят характер культурам разных видов Орбиса. Они же станут вдохновляющими примерами для моддеров, которые хотят строить более сложные NPC, или смогут использоваться напрямую, если подходят по задумке.

В перспективе всё это ведёт к созданию полноценных боссов — встреч, которые выжмут PvE-системы на максимум. Работы до этой точки много, но команда двигается шаг за шагом.

Фора для моддеров: debug-команды

Пост изначально писался ещё до релиза раннего доступа. С тех пор команда вложилась в то, чтобы сделать NPC доступнее для моддеров. Пока нет визуального редактора и «глубокой» отладки, но добавили ряд визуализаций, которые помогают понять, как NPC будет работать (и заодно помогли разработчикам выловить собственные баги).

Часть функций ещё в разработке, но автор показывает «тизер» того, что уже делается и что должно приехать в будущих релизах.

Каждую визуализацию можно включать через специальные debug-флаги на конкретном NPC. Это делается командой NPC debug, пока NPC находится в поле зрения. Варианты:

1. в чате в игре: /npc debug set <flag>
2. либо добавить флаги списком через запятую в свойство Debug у роли NPC

Команда /npc debug presets выводит полный список флагов и наборы пресетов. Ниже — самые полезные визуализации, которые выделены в посте.

/npc debug set VisAiming

Помогает понять, во что именно целится NPC. Работает для NPC, у которых в логике есть инструкции, связанные с прицеливанием.

/npc debug set VisMarkedTargets

Показывает все текущие помеченные цели, на которые «залочен» NPC. В большинстве стандартных шаблонов у NPC есть один LockedTarget — обычно это сущность, с которой он прямо сейчас дерётся. Полезно, чтобы понять, как и когда NPC переключает фокус, и на ком именно он сфокусирован в толпе.

/npc debug set VisSensorRanges

Показывает все проверяемые диапазоны mob-сенсоров в виде колец и секторов обзора, а также то, какие сущности в радиусе «матчатся» какими сенсорами. В целом это быстрый визуальный обзор «чувств» NPC. Отдельно уточняется: хотя отображение идёт секторами и кольцами, технически это сферы и конусы, которые могут быть ограничены условиями по высоте.

На первом скриншоте медведь спит, и у него активен только один сенсор. На втором — у медведя есть слух, зрение и абсолютная дальность обнаружения. Несмотря на то, что овцы обнаружены радиусом зрения (по ним стоят метки), они находятся вне конуса обзора — «семья овец всё ещё в безопасности».

/npc debug set VisLeashPosition

Показывает текущую позицию «поводка» (leash position) NPC.

/npc debug set VisFlock

Показывает «стайную» группу (flock), к которой относится NPC: отмечается лидер и все NPC, которые сейчас входят в эту группу.