В Unreal Engine 5 существует обширный набор инструментов и систем для анимации. В этом небольшом руководстве я постараюсь дать общий обзор на то, какие есть системы и как их использовать и откуда начинать копать код в случае багов и расширений. Это руководство скорее пригодится программистам и техническим аниматорам, но и остальные разработчики могут найти его полезным.

В unreal система координат достаточно уникальная: левая система координат с Z вверх.

Эта особенность вызывает некоторые сложности при экспорте анимаций и скелетов. В большей части программ для анимаций это уже учтено, и достаточно включить галочку “Unreal Export” или похожую, и проблем не будет, но если скелет выглядит странно и кости вывернуты - это первое, что стоит проверять.

В Unreal  существуют два основных ассета. связанных со скелетной анимацией: непосредственно скелет (Skeleton) и скелетный меш (Skeletal Mesh).

Skeleton  (USkeleton)

Основой всей анимационной логики Unreal служит skeleton ассет, содержащий иерархию костей и их расположение в базовой (неанимированной) позе. Чаще всего в Unreal используется A поза, но в большинстве случаев базовая поза не так важна, так как большая часть инструментов, для которых она используется (например аддитивные анимации), позволяет указывать базовую позу напрямую, например кадр из определенной анимации.

В скелете определены несколько важных дополнительных сущностей. важных для анимационной системы:

• Curve (Кривые) - это целочисленные значения, которые можно задавать внутри анимации и монтажей, и которые можно считывать в любом месте анимационной системы. Кривые позволяют переключать разные опции, менять параметры материалов и управлять анимационными графами. Если кривая помечена как material curve, её значение будет автоматически передаваться во все материалы, которые используется skeletal mesh. (подробнее о кривых можно почитать тут)
• Animation Notifies - набор стандартных событий для этого скелета. Они делятся на два типа Notify (буквально событие, на которое можно отреагировать в BP) и SyncMarker - точки синхронизации, использующиеся для бленда между анимациями.
• Blend Profiles - это маска, которая показывает какие кости и насколько активны в этом профиле. С помощью них можно проигрывать анимации только на определенных костях или конечностях.
• Retargeting – параметры ретаргетинга. Поскольку большинство анимационных ассетов привязано к конкретному скелету, для использования анимаций на совместимых скелетах необходимо указать их соответствие. Здесь задаются как явно совместимые скелеты, так и правила Retargetting.
• Socket - это дополнительные кости, созданые внутри Unreal. Чаще всего они используются для присоединения дополнительных компонентов (например другого меша или VFX), либо для определения положения некоторой части скелета в пространстве (например - куда смотрит голова персонажа) (подробнее о Socket можно почитать тут)

Если вы не можете найти какие-то настройки скелета, обратите внимание на меню Window. в котором могут быть нужные вам окна настроек. Подробное описание скелетов можно найти тут

Skeletal Mesh (USkeletalMesh)

Skeleton Mesh - это уже непосредственно меш с треугольниками, материалами и скинингом, который использует определенный Skeleton для анимации. В основном тут живут настройки, связанные с визуальной функцией модели, но есть и несколько анимационных:

• Curve (Кривые) - те же кривые,. что и для скелета, но существуют только для этого конкретного меша.
• Morph Target - настройки, позволяющие деформировать меш.
• Cloth Settings - настройки ткани.

При работе с анимацией основное внимание обычно уделяется скелету, а не мешу.

Skeletal Mesh Component (USkeletalMeshComponent)

Поскольку основой всех игровых объектов в Unreal является Actor, чтобы добавить Skeleton Mesh на Actor используется Skeleton Mesh Component. В этом компоненте соединяются все настройки. необходимые для правильного функционирования SkeletalMesh. Их достаточно много и большая их часть имеет описание, или можно понять их функции из исходников, но часть стоит упомянуть отдельно.

• ComponentTick - настройка того, когда и как тикает наш компонент. Она стандартная для ActorComponent, но все равно важная для SkeletalMesh. В ней можно указать, нужно ли мешу обновляться на сервере (в некоторых играх - да, в некоторых - нет), когда тикать (чаще всего до физики, но меши, которые присоединены к другому компоненту, должны тикать в конце, чтобы не отставать на кадр от своего родителя)
• Visibility Based Anim Tick Option позволяет настраивать то, будет ли обновляться поза в зависимости от видимости скелета. Очень важная настройка для оптимизации, так как тяжеловесные анимационные графы очень сильно бьют по производительности проекта.
• Animation Mode отвечает за то, как анимирован компонент с помощью Blueprint (о которых пойдет речь дальше), или с помощью простой анимации, или вообще каким-нибудь необычным образом из кода (например копированием поз в Animation Sharing).

Этот компонент еще интересен тем, что, не смотря на режим анимации, этот компонент все равно отвечает за финальное обновление позы и Transform конкретного меша. Даже при многопоточной логике  обновления анимационных графов, о которых мы поговорим позже, финальное положение костей все равно обновляется в этом компоненте, что делает его идеальной точкой старта для поиска багов. Сам компонент унаследован от USkinnedMeshComponent, которйы в свою очередь унаследован от UMeshComponent. Эти два класса и сам USkeletalMeshComponent позволяют достаточно быстро определить стандартные проблемы, связанные с анимациями.  Например: передается ли кривая в материалы (USkeletalMeshComponent::ApplyAnimationCurvesToComponent), или обновляется ли поза (USkinnedMeshComponent::ShouldTickPose и USkinnedMeshComponent::TickPose), или вообще тикает ли наш скелет (USkeletalMeshComponent::TickComponent).

Анимации

Базовым абстрактным ассетом, содержащим анимационную информацию является UAnimationAsset. От него унаследованы все остальные ассеты, которые отвечают за анимации.

Animation Sequence (UAnimSequence)

Каждая анимация представлена в Unreal как Animation Sequence. Она жестко привязана к Skeleton и не может существовать без конкретного скелета. Тут живут все движения костей, которые запекались в анимационной программе, также тут можно добавлять анимации кривых и аддитивных треков. Кроме того тут определены настройки того как эту анимацию воспринимать остальной анимационной системе: аддитивная ли это анимация или обычная (Additive Anim Type), есть ли у этой анимации Root Motion, и если есть, то от какой позы он считается (Все эти настройки расположены в секции Root Motion) . В анимации можно добавлять нотификаторы: как определенные раньше в Skeleton, так и любые доступные. Нотификаторы могут варьироваться от событий до полноценных блюпринтов, выполняющих некоторую игровую логику или вызывающих выполнение такой логики в других системах. (Подробнее про нотификаторы будет ниже)

Обычно этот класс не расширяют в c++, а просто создают ассеты из него, но часто бывает так, что необходимо добавить какую-нибудь важную информацию в анимацию. Для этого в Unreal UAssetUserData и UAnimMetaData можно заводить дополнительные типы данных и хранить их прямо в анимации. Затем их может использовать либо игровая логика, либо узлы AnimationBlueprint. Эти данные присутствуют у всех анимационных ассетов, унаследованных от UAnimationAsset, в том числе и у UAnimSequence.

Подробнее про анимации можно почитать тут

Animation Montage (UAnimMontage)

Animation Montage - это склейки и комбинации нескольких анимаций. Они используются для того, чтобы комбинировать анимации. С помощью монтажей можо легко реплицировать RootMotion и проигрывание анимаций по сети (Такие плагины как Game Ability System очень сильно зависят от монтажей и вокруг них строят свою систему репликации анимаций).

Монтаж разбит на слоты (в дальнейшем они будут полезны при проигрывании разных анимаций на разных частях скелета или Animation Blueprint). Каждый слот состоит из последовательности анимаций.

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

Настройки BlendIn и BlendOut позволяют настраивать бленды при старте монтажа и его окончания. Чаще всего монтажи играют роль некоего действия, которое совершает персонаж. Такое действие должно начать проигрываться сразу и желательно реплицироваться по сети. Кроме того, как будет видно ниже, в AnimationBlueprint монтажи живут обособленно в анимационном графе и чаще всего нет отдельного перехода в монтаж, поэтому. чтобы позы не переключались резко, логика проигрывания монтажа берет на себя контроль за блендом поз.

Подробнее про монтажи можно почитать тут

Blend Space(UBlendSpace)

Blend Space позволяет смешивать разные анимации в зависимости от двух параметров: горизонтальная и вертикальная оси. Стандартным примером использования является создание красивой анимации передвижения, где по горизонтальной оси откладывают направление перемещения (угол относительно прямого направления), а по вертикальной оси - скорость передвижения. Анимации располагают в разных точках образовавшейся плоскости. Когда надо выбрать позу, BlendSpace по входящим параметрам определяет точку на плоскости, находит ближайшие анимации и. в зависимости от расстояния от них до текущей точки, смешивает их в одну позу.

Подробнее про Blend Space можно почитать тут

Anim Notify

Нотификаторы (наследники класса UAnimNotify и UAnimNotifyState) - главный механизм передачи информации из анимационной системы в остальные подсистемы игры. Нотификаторы делятся на два типа:

• Наследники UAnimNotify - единоразовое событие. Если при проигрывании анимации или монтажа встречается нотификатор, то вызывается функция UAnimNotify::Notify.
• Наследники UAnimNotifyState - нотификатор с длительностью, активный на протяжение определенного числа кадров. Анимационная система вызывает UAnimNotifyState::NotifyBegin, UAnimNotifyState::NotifyEnd, UAnimNotifyState::NotifyTick на старте, при завершении и тике нотификатора соответственно.

Нотификаторы удобно использовать для вызова геймплейных событий, проигрывания звуков, или визуальных эффектов непосредственно из анимации.

Подробнее про нотификаторы можно почитать тут 

Animation Blueprint (ABP)

Анимационный блюприт (иногда анимационный граф) является основным и стандартным способом управления анимациями в Unreal. С точки зрения редактора, ABP привязан к конкретному скелету и состоит из двух частей. Первая часть - это стандартный для любого Blueprint EventGraph: здесь можно создавать логику, заполнять некоторые важные флаги и параметры для работы ABP. Вторая часть - это AnimationGraph (анимационный граф), роль которого  собрать финальную позу скелета со всеми кривыми, морфами и прочими метаданными.

Animation Graph

Анимационный граф состоит из последовательности AnimNode (FAnimNode_Base) (анимационных узлов), которые выполняют логику, чтобы получить анимационную позу, повлиять на метаданные, либо переключить между разными частями графа.

У каждого AnimNode есть один выход, в который передается результат работы узла, но может быть несколько входов. Какой из них использовать определяет сам узел на основе своей внутренней логики.

В Unreal создано очень много готовых узлов, с помощью которых можно создать почти любое поведение. Я остановлюсь на нескольких самых важных и часто используемых.

Sequence Player (FAnimNode_SequencePlayerBase)

Узел, который проигрывает Animation Sequence. Самый простой и атомарный элементы любого ABP. В этом узле можно задать какую анимацию надо играть и указать настройки того, как надо играть её.

State Machine (FAnimNode_StateMachine)

Стандартный конечный автомат для описания конкретных анимационных состояний. Каждое состояние представляет из себя Animation Graph, что позволяет вкладывать в состояние еще один State Machine. Переходы между состояниями осуществляются с помощью условий или событий. У состояний существует набор событий, на которые можно повесить функции или события из EventGraph

Побольше почитать про State Machine можно тут 

Slot (FAnimNode_Slot)

Узел, который играет слот из монтажа. ABP позволяет играть неограниченное количество монтажей параллельно, но с точки зрения Анимационного графа это не значит ничего для финальной позы, монтаж просто помещается в ABP, начинается, проигрывается и заканчивается. Для того, чтобы анимация из него попала в финальную позу, как раз и существует узел Slot. Этот узел использует позу одного из слотов активного сейчас монтажа, и если монтажа нет, то он просто прокидывает входящую позу без изменений.

Слоты разбиты на группы и редактируются для конкретного скелета в Animation Slot Manager, который можно открыть с помощью меню Window.

BlendByBool (FAnimNode_BlendListByBool)

Узел, который выбирает либо одну входящую позу, либо вторую, в зависимости от булевого флага. По аналогии работают и остальные BlendBy узлы

Apply Additive (FAnimNode_ApplyAdditive)

Добавляет в позу аддитивную позу. Обычно используется для проигрывания дополнительных небольших анимаций или поз смещения, например анимации реакции на удар или blendspace поворота головы за целью.

Layered blend per bone (FAnimNode_LayeredBoneBlend)

Позволяет разбить скелет на части и указать для каждой части позу, которую надо будет использовать. Чаще всего используется для анимаций верхней части тела (например анимации стрельбы, которая играется независимо от анимации ног). Для разбиения скелета на части можно указывать непосредственно кости, либо BlendProfile, заданные в Skeleton.

Подробнее про узлы можно почитать тут

Многопоточность

ABP в Unreal может обновлять свои узлы и позы многопоточно, что очень положительно влияет на производительность графа и игры в целом. Для того, чтобы ваш граф использовал многопоточность, в ABP стоит использовать Blueprint Thread Safe Update Animation и только Thread Safe функции.

Fast Update

Как видно из скришнотов выше, некоторые узлы отмечены белой молнией. Эти узлы помечены для быстрой обработки. Такие узлы позволяют компилятору blueprint копировать значения переменных и тем самым избегать вызовов блюпринтовых методов и функций. Это улучшает производительность всего ABP. Для этого ни один пин узла не должен содержать никаких вычислений кроме как чтения переменных( а лучше всего вообще bind переменные в параметры узла).

Подробнее про многопоточность и Fast Update можно почитать тут 

FAnimNode_Base

В определенный момент разработки может наступить момент, когда уже существующих AnimNode недостаточно и нужно реализовать новую логику. Для этого нужно создать два класса: класс, содержащий непосредственно логику изменения позы, и класс, необходимый для редактора графов.

• Runtime узел - наследуется от FAnimNode_Base, и должен существовать в c++ проекте с типом "Runtime". Этот класс будет использоваться во время игры и выполнять нужную логику.
• Узел редактора - наследуется от UAnimGraphNode_Base., он содержит необходимые для редактора настройки и логики нового узла, и он должен существовать в c++ проекте с типом "UncookedOnly".

Выполнение узла разбито в ABP на несколько этапов, и для них всех в FAnimNode_Base существуют виртуальные функции. Из интересных стоит отметить следующие:

• Initialize_AnyThread функция для инициализации вашего узла
• Update_AnyThread функция для обновления логики узла.
• PreUpdate функция, которая выполняется до вызова Update в GameThread; позволяет сохранить данные, которые могут быть не threadsafe.
• Evaluate_AnyThread функция для обновления и создания финальной позы.

Чтобы добавить вход в новый узел, ему надо задать поле следующего вида

UPROPERTY(EditAnywhere, BlueprintReadWrite, Category=Links)
FPoseLink BasePose;

При этом в Update_AnyThread  стоит вызвать GetEvaluateGraphExposedInputs().Execute(Context);. чтобы входящие узлы тоже получили шанс выполнить свою логику, и вызвать FPoseLinkBase::Update(const FAnimationUpdateContext& InContext) на самой BasePose, передав соответствующий контекст. Примером того, как работать с входящими позами, может служить класс FAnimNode_BlendListBase, который блендит список входящих поз с разными весами. Создавая новый узел, полезно поглядеть что и как делается в этом классе.

UAnimInstance и FAnimInstanceProxy

Программно Animation Blueprint разделён на две составляющие:

• UAnimInstance – базовый класс экземпляра ABP. Может быть расширен в Blueprint или C++.
• FAnimInstanceProxy – прослойка, обеспечивающая потокобезопасный доступ к данным во время обновления графа и скелета. Именно с ней взаимодействуют FAnimNode. Результирующая поза и метаданные (например, Root Motion) сохраняются в прокси, затем считываются UAnimInstance и передаются в USkeletalMeshComponent.

Debug

В Unreal есть несколько инструментов для дебага анимаций и скелетов.

Существуют флаги, позволяющие рендерить кости и их положение в пространстве: консольная команда Show Bones. Если открыть окно редактирования какого-нибудь ABP, то, как и с любым Bluerprint, если у вас запущена PIE, вы можете выбрать экземпляр работающего в мире ABP и посмотреть, что с ним происходит с помощью редактора.

Основным инструментом является конечно же Rewinder Debbuger, который записывает все события, происходящие с актором и с ABP, и позволяет, используя timeline, подробно кадр за кадром просматривать, что происходит. Для того. чтобы открыть Rewinder, нужно воспользоваться меню Tools -> Debug

После этого выбрать нужного актора и нажать запись.
N.B. я не уверен, насколько эта проблема зависит от версии Unreal или от сборки, но у меня Rewinder работает только в netmode PIE Play As Standalone. После этого вы можете спокойно анализировать, что происходит с мешем или ABP

Evaluator (Вычислитель)

Evaluator - это особый тип узлов в StateTree, который активен все время выполнения конкретного дерева, и который позволяет дополнять или получать данные, необходимые для работы дерева. Отличие от глобальных задач скорее архитектурное, чем в логике выполнения: вычислители отвечают за сбор и вычисление данных, а не изменение состояния агента или какие-то действия. Простым примером может служить вычислитель поиска цели, который из списка известных Акторов выбирает лучшую цель, или вычислитель, который считает расстояние от текущей цели до агента и сохраняет его в переменную.

Data Flow

Давайте разберемся, как с помощью параметров и полей можно передавать данные между разными состояниям. Начнем с полей любых задач и вычислителей: если задача  глобальна или актуальна для текущего состояния (например, эта задача существует на родительском поле), то это поле можно передать в другую задачу или вычислитель. Для этого в StateTree используется binding полей (по аналогии с полями в Animation Blueprint).

Если поле определено в Blueprint, то оно по умолчанию доступно для binding. Для полей в c++ существует несколько правил: поле должно иметь макрос UPROPERTY, также у него должны быть настройки EditAnywhere и BlueprintReadWrite, и поле должно быть публичным:

//State tree expose data
UPROPERTY(EditAnywhere, BlueprintReadWrite)
float ParticipantsCount;

Input, Output, Context

Определяя поля возможно  разместить их для StateTree. Если поле находится в категории Input, значит поле содержит входящие данные для работы вашего класса. Если поле находится в категории Output, то ваш класс запишет результат своей работы в это поле. Поле из категории Context содержит необходимый конекст для работы класса, поэтому StateTree попробует заполнить его из вашей схемы автоматически. Поля без категории расцениваются как настройки, но их все равно можно привязывать к полям и параметрам.
N.B. стоит помнить, что даже поле должно быть видимым для настройки в редакторе, чтобы была возможность его редактировать в редакторе StateTree. Blueprint поле должно быть публичное и Instance Editable, а поле из c++ должно иметь макроc EditAnywhere.

Parameters (Параметры)

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

Примером параметра для состояния может служить точка назначения условного состояния передвижения. Родительское состояние содержит параметр-вектор точки назначения. Первое состояние - потомок находит подходящую точку для перемещения с помощью задачи и записывает его в параметр родителя, а второе состояние - с помощью задачи передвижения перемещается в заданную точку.

Параметры также передаются в поля классов с помощью binding.

Property Function

По умолчанию невозможно использовать функции (даже BlueprintCallable) для назначения полей (binding), но существует подход, который это исправляет. Существует возможность определить класс, унаследованный от FStateTreePropertyFunctionBase.

Такие классы выполняются перевычеслением назанченного поля и позволяют поменять логику выполнения назначения, или поменять результат назанчения. Примером может служить FStateTreeGetActorLocationPropertyFunction, которая позволяет назначать в поля позицию Актора напрямую.

Дебаг и Тестирование

Одной из удобных возможностей работы со StateTree является то, что почти любой узел дерева может быть выключен или переключен в фиксированный режим во время работы в редакторе. Это очень сильно облегчает разработку, настройку и тестирование деревьев.

Например любое условие может быть переключено в режим Force True или Force False.

Любая задача может быть выключена.

Любой переход тоже может быть выключен

В Unreal Engine 5.7 для дебага используется Rewinder, который записывает все происходящее с Aкторами во время PIE, но у State Tree есть свое окно дебага, которое позволяет более подробно отслеживать что происходит с деревом и, например, какие переходы выполнялись с какими условиями.

В следующий раз мы попробуем собрать простой боевой ИИ, используя StateTree

UCRCharacterMovementComponent

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

Начнем с создания класса,  унаследованного от UCharacterMovementComponent. Для начала добавим поле, отвечающие за “вверх” нашего персонажа, добавим указатель на контроллер гравитации, и создадим функцию, с помощью которой можно назначить указатель.

N.B. Создание таких Setter может быть не самым правильным, так как мы создаем зависимости между классами, создающими контроллеры гравитации, и нашим компонентом. В общем случае лучше использовать интерфейсы или события. Но, поскольку мы сейчас концентрируемся на тестировании механики и простой реализации ленты Мёбиуса, такой подход допустим. В дальнейшем мы сможем легко его переписать.

UCLASS(ClassGroup=(Custom), meta=(BlueprintSpawnableComponent))
class FPSGAME_API UCRCharacterMovementComponent : public UCharacterMovementComponent
{
	GENERATED_BODY()

public:
	virtual void TickComponent(float DeltaTime, ELevelTick TickType, FActorComponentTickFunction* ThisTickFunction) override;
	FVector GetUpOrientation() const;
	UFUNCTION(BlueprintCallable)
	void SetGravityController(UObject* InGravityController);

	TOptional<FVector> UpOverride;
	UPROPERTY()
	TScriptInterface<class ICRGravityController> GravityController;
};

FVector UCRCharacterMovementComponent::GetUpOrientation() const
{
	return UpOverride.Get(FVector::UpVector);
}

void UCRCharacterMovementComponent::SetGravityController(UObject* InGravityController)
{
	if (InGravityController->Implements<UCRGravityController>())
	{
		GravityController = TScriptInterface<ICRGravityController>(InGravityController);
	}
}

Во время тика нашего компонента получим у гравитационного контроллера (если он есть) ориентацию и гравитацию, сохраним ориентации и проставим как направление гравитации.

void UCRCharacterMovementComponent::TickComponent(float DeltaTime, ELevelTick TickType,
	FActorComponentTickFunction* ThisTickFunction)
{
	Super::TickComponent(DeltaTime, TickType, ThisTickFunction);
	UE_VLOG(GetOwner(), LogCRCharacterMovementComponent, VeryVerbose,  TEXT("Mode %s CustomMode %s"), *GetMovementName(), *GetCustomMovementName());
	if (GravityController)
	{		
		FVector ControllerUp;
		FVector Gravity;	
		GravityController->GetGravityAndOrientation(GetActorLocation(), Gravity, ControllerUp);
		SetGravityDirection(Gravity);
		UpOverride = ControllerUp;
	}
}

ACRPlayerController

Второй класс, который нам необходимо расширить - это класс нашего контроллера. В данном примере мы используем базовые настройки Unreal Engine 5.6 для шаблона FPS. Ориентация персонажа следует за камерой, контроллер поворачивает камеру. Для третьего лица (или если у вас сложный контроллер, который выполняет некоторые дополнительные функции) может потребоваться дополнительная логика.

Унаследуем наш от APlayerController. Переопределим функцию UpdateRotation и создадим пару функций для удобного вычисления ориентации, плюс добавим поле, чтобы кешировать предыдущую ориентацию “вверх”.

UCLASS()
class FPSGAME_API ACRPlayerController : public APlayerController
{
	GENERATED_BODY()

	virtual void UpdateRotation(float DeltaTime) override;
public:
	static FRotator GetUpRelativeRotation(FRotator Rotation, FVector GravityDirection);
	static FRotator GetUpWorldRotation(FRotator Rotation, FVector GravityDirection);
 
private:
	FVector LastFrameUp = FVector::ZeroVector;
};

Функции GetUpRelativeRotation и GetUpWorldRotation достаточно простые: мы вычисляем итоговый поворот ориентации относительно того, насколько у нас гравитационный “вверх” отличается от мирового. Разница в том, что в одном случае мы считаем, что поворот локальный, а в другом - мировой.

FRotator ACRPlayerController::GetUpRelativeRotation(FRotator Rotation, FVector UpDirection)
{
	if (!UpDirection.Equals(FVector::UpVector))
	{
		FQuat GravityRotation = FQuat::FindBetweenNormals(UpDirection, FVector::UpVector);
		return (GravityRotation * Rotation.Quaternion()).Rotator();
	}
 
	return Rotation;
}
 
FRotator ACRPlayerController::GetUpWorldRotation(FRotator Rotation, FVector UpDirection)
{
	if (!UpDirection.Equals(FVector::UpVector))
	{
		FQuat GravityRotation = FQuat::FindBetweenNormals(FVector::UpVector, UpDirection);
		return (GravityRotation * Rotation.Quaternion()).Rotator();
	}
 
	return Rotation;
}

Функция поворота UpdateRotation требует более подробного рассмотрения.

Для начала получим требуемое направление “вверх” из UCRCharacterMovementComponent

	FVector UpDirection = FVector::UpVector;
	if (ACharacter* PlayerCharacter = Cast<ACharacter>(GetPawn()))
	{
		if (UCRCharacterMovementComponent* MoveComp = PlayerCharacter->GetCharacterMovement<UCRCharacterMovementComponent>())
		{
			UpDirection = MoveComp->GetUpOrientation();
		}
	}

Получим требуемую игроком ориентацию контроллера.

FRotator ViewRotation = GetControlRotation();

Эту ориентацию надо повернуть так, чтобы она соответствовала новой гравитации. Например если игрок смотрел на 45 градусов вверх относительно мировых координат, теперь мы должны повернуть эту ориентацию так, чтобы эти 45 градусов сохранились от нашего локального “вверх”.

	if (!LastFrameUp.Equals(FVector::ZeroVector))
	{
		const FQuat DeltaGravityRotation = FQuat::FindBetweenNormals(LastFrameUp, UpDirection);
		const FQuat WarpedCameraRotation = DeltaGravityRotation * FQuat(ViewRotation);
 
		ViewRotation = WarpedCameraRotation.Rotator();	
	}
	LastFrameUp = UpDirection;

Теперь нам надо взять управление от игрока, чтобы добавить поворот, который пытается сделать игрок, и передать в PlayerCameraManager, чтобы он применил модификаторы и правила поворота камеры. После чего убрать Roll, перевести нашу локальную ориентацию в мировую, и выставить в контроллер.

N.B. Так как мы делаем абстрактную систему, не очень хочется вклиниваться в работу других систем. Если мы собрали или настроили какие-то модификаторы или ограничители поворота, они должны работать с нашей гравитацией тоже, поэтому важно чтобы PlayerCameraManager работал с нашей логикой

	ViewRotation = GetUpRelativeRotation(ViewRotation, UpDirection);

	FRotator DeltaRot(RotationInput);
	if (PlayerCameraManager)
	{
		PlayerCameraManager->ProcessViewRotation(DeltaTime, ViewRotation, DeltaRot);

		ViewRotation.Roll = 0;
 
		SetControlRotation(GetUpWorldRotation(ViewRotation, UpDirection));
	}

В конце убираем Roll и Pitch у нашей ориентации, переводим в мировые координаты и передаем это нашей пешке.

	ViewRotation.Roll = 0.0f;
	ViewRotation.Pitch = 0.0f;
	APawn* const P = GetPawnOrSpectator();
	if (P)
	{
		P->FaceRotation(GetUpWorldRotation(ViewRotation, UpDirection), DeltaTime);
	}

ApplyGravityController

Для теста нам понадобится реализовать простой способ назначить нашему персонажу контролер гравитации. В реальной игре это может быть сделано через уровень, систему способностей или GameMode. Для тестирования нам подойдет и просто триггер, который будет просто проставлять выбранного Actor в UCRCharacterMovementComponent

Теперь наш код готов к полноценному тестированию.

FSM + Behaviour Tree

Один из самых простых подходов в сочетании разных решениях - это прямой гибрид Конечного Автомата и Дерева Поведения. Автомат принимает высокоуровневые решения: запускается боевое поведение или мирное, стоит NPC  убегать от игрока или разговаривать с ним. Каждое состояние Автомата реализовано как самостоятельное дерево поведения. Деревья поведения подробно на низком уровне реализуют каждые состояния. Такой подход позволяет не перегружать FSM переходами низкоуровневых поведений (такими как неудачная навигация или выбор способности для текущего состояния).

Насколько нам известно, Дерево Поведения чаще всего использует BlackBoard для хранения информации. Поскольку наши деревья в случае сочетания с Автоматом не должны покрывать все поведение нашего агента, то, следовательно, наши Blackboard должны хранить информацию только для текущего состояния Автомата, что упрощает его структуру  и облегчает работу с ним. Кроме того мы получаем возможность использовать шаблонные деревья. Например дерево ближнего боя может выглядеть как навигация и использование способности, в котором настройки навигации и способность храниться в Blackboard. Blackboard настраивается уже автоматом, в зависимости от того, какое поведение он описывает текущим состоянием.

Одна из проблем такого подхода заключается в том, что передача данных между Деревьями и Автоматами может быть нетривиальной. Например если дизайн вашего агента требует, чтобы агенту нужно было убегать от игрока, если у него нет подходящих предметов для активации. Но такой запрос про предметы может быть частью низкоуровневой логики, за которую отвечает Дерево поведений. Получается Дерево должно сообщить более высокоуровневой логике о своей неудаче. Такое направление потока данных в ИИ выглядит тяжелым для поддержки: в Автомате будут условия, которые скрыты где-то в дебрях Деревьев поведений, причем не обязательно,что всех.

Главным преимуществом совмещения FSM и Дерева Поведения является прирост производительности. Количество переходов в Автомате ограничено высокоуровневыми состояниями, и их частоту обновления можно понизить, так как такая задержка не будет заметна игроку. Дерево Поведений отвечает за одно состояние, соответственно количество декораторов и условий тоже ограничено, и Дерево работает быстрее.

Behaviour Tree + Utility AI

Другой популярный подход к сочетанию моделей ИИ - это сочетание шаблонных деревьев поведений и подхода полезности для выбор конкретных действий и способностей.

Дерево поведений может описывать абстрактное поведение с модулями и узлами, которые выбираются и настраиваются с помощью Utility AI. Например Дерево Поведения дальнего боя будет включать перемещение в точку для атаки и использование оружия дальнего боя, а  выбор точки и выбор оружия осуществляется с помощью полезности.

Такой ИИ отлично работает с дизайном агентов, у которых дизайн отличается способностями и предметами, но общее поведение, позиционирование и схожая логика. Например РПГ, где разнообразие ИИ кроется именно в сборке или инвентаре противников, а не в их поведении.

GOAP + FSM/BehaviorTree

Основным подходом к работе с GOAP является реализация конкретных действий в плане с помощью других моделей поведений. Такой подход использовался при создании GOAP в F.E.A.R.: каждое действие реализовывалось через Конечный Автомат, состоящий из 3 действий: передвижение, использование smart object и  проигрывание анимации. А куда перемещаться, что за объект использовать, и какую анимацию играть, определялось типом действием и задавалось в настройках действий.

Такой подход позволяет убрать из планов тривиальные действия и сочетания и сфокусироваться на высокоуровневых поведениях. Также  это сокращает размер планов, а следовательно и размер пространства, в котором мы ищем план.

StateTree

Один из новых и реализованных гибридов двух моделей - это StateTree в Unreal Engine 5. Подход StateTree - это попытка получить бонусы и удобства контролируемых переходов в разные состояния с понятной системой последовательностей и селекторов.

Schema и Context

State Tree является абстрактной моделью, и, хотя естественное его использование - это ИИ, сама структура состояний и переходов может быть использована для чего угодно: от низкоуровневой системы комбо до высокоуровневой системы миссий и заданий. Поэтому в основе state tree, в отличие от дерева поведения, лежит идея, что state tree может запускаться на любом объекте и с любым контекстом. Для того чтобы код понимал, с чем он работает и какие структуры обязательные для данного дерева, существует schema

UStateTreeAIComponentSchema::UStateTreeAIComponentSchema(const FObjectInitializer& ObjectInitializer /*= FObjectInitializer::Get()*/)
	: AIControllerClass(AAIController::StaticClass())
{
	check(ContextDataDescs.Num() == 1 && ContextDataDescs[0].Struct == AActor::StaticClass());
	// Make the Actor a pawn by default so it binds to the controlled pawn instead of the AIController.
	ContextActorClass = APawn::StaticClass();
	ContextDataDescs[0].Struct = ContextActorClass.Get();
	ContextDataDescs.Emplace(UE::GameplayStateTree::Private::Name_AIController, AIControllerClass.Get(), FGuid(0xEDB3CD97, 0x95F94E0A, 0xBD15207B, 0x98645CDC));
}

Схема содержит набор полей и правил, с помощью которых остальные части state tree могут получить необходимую информации и доступ к нужным объектам.

Для запуска дерева поведения и его обновления необходимо использовать контекст и внешней контролер (которым может быть компонент, актор или подсистема).

FStateTreeExecutionContext Context(*GetOwner(), *StateTreeRef.GetStateTree(), InstanceData);
if (SetContextRequirements(Context))
{
    const EStateTreeRunStatus PreviousRunStatus = Context.GetStateTreeRunStatus();
    const EStateTreeRunStatus CurrentRunStatus =  Context.Tick(DeltaTime);

    if (CurrentRunStatus != PreviousRunStatus)
    {
        OnStateTreeRunStatusChanged.Broadcast(CurrentRunStatus);
    }
}

Именно контролер и схема заземляют абстрактное дерево до конкретной реализации. В дальнейшем мы будем рассматривать State Tree в контексте ИИ и brain component Unreal Engine. Но зона его применения намного шире.

State (Состояние)

Можно догадаться из названия, что основой StateTree является состояние (state). Состояние совмещает в себе сразу несколько моделей. Первое - это аналог состояния из конечного автомата: структура, у которой есть понятие входа/старта и выхода/завершения. Она описывает некоторое поведение и выполняет некоторую логику, также может иметь условия и правила выполнения или входа.

Вторая модель - это управляющий узел из дерева поведения: структура обладает набором потомков, которые она запускает и обрабатывает в соответствии с конкретным набором правил.

Например мы можем указать состоянию правила TrySelectChildrenInOrder

, для того чтобы наше состояние вело себя как селектор, либо как селектор с выбором по весам(кусочек utility based ai).

Transition (Переход)

В отличие от конечного автомата, состояния в State Tree чаще обладают циклом “выполняю  -> завершил (успешно или нет)” , что делает их схожими с конечными узлами деревьев поведения. После завершения же состояние обладает свойствами уже конечного автомата: вы может свободно определить, куда переходит дерево по завершению конкретного действия. Можно совершить переход в соседнее состояние, либо прыгнуть в другое часть дерева, либо завершить дерево, либо перезапустить его. Также такие переходы можно совершать в любой момент времени, как и в конечном автомате: по событию или во время тика по условию. Кроме того сохраняется иерархическая структура дерева: если переход совершает родительское состояние, то все его потомки завершаются автоматически.

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

Condition (Условия)

Условия в State Tree встречаются в переходах из состояний и в самих состояниях при старте состояния. Условия при входе позволяют реализовать модель селектор из дерева последней: потомки конкретного состояния обладают набором условий, и он будет перебирать их при входе пока её найдет то, у которого условие выполнено.

Условия обычно наследуются от FStateTreeConditionBase. Однако, если в вашем проекте несколько StateTree, которые используются с разными схемами, может быть удобно создать промежуточные базовые классы и указать в схеме, какие классы условий можно использовать в какой схеме.

bool UStateTreeAIComponentSchema::IsStructAllowed(const UScriptStruct* InScriptStruct) const
{
	return Super::IsStructAllowed(InScriptStruct)
		|| InScriptStruct->IsChildOf(FStateTreeAITaskBase::StaticStruct())
		|| InScriptStruct->IsChildOf(FStateTreeAIConditionBase::StaticStruct());
}

Условия можно комбинировать по правилам булевых операций. Для этого в unreal Engine 5.6 есть интерфейс создания условий. Конечно же можно создавать blueprint условия.

Для удобства рекомендую всегда реализовывать функцию FText FStateTreeNodeBase::GetDescription, чтобы ваше дерево было читаемым и удобным.

Task (задачи)

Задачи являются той частью состояния, которая позволяет им выполнять логику. Задача - это кирпичики, из которых собирается поведение в State Tree. Задачи могут простыми (например навигация в пространстве), и сложными действиями (например проиграть последовательность атак). В принципе, как и в дереве поведения, задачи в StateTree лучше делать атомарными и простыми. В каждом состоянии может быть сколько угодно задач.Состояние определяет само, когда оно должно завершиться, с помощью настройки (по окончанию любой задачи или всех).

Задачи наследуются от класса FStateTreeTaskBase, но, по аналогии с условиями, удобно будет завести промежуточный базовый класс, который вы разрешите использовать вашей схеме.

Бесконечные задачи могут выполнять роль сервисов и декораторов из дерева поведения. Такую задачу можно добавить в любое состояние, либо добавить в список глобальных задач всего дерева. Глобальные задачи чаще всего собирают и анализируют состояние игрового мира и агента и сводят его к простым флагам или полям, которые в свою очередь могут использоваться остальными состояниями.

Data Flow

При работе и проектировании StateTree важно сразу понять как работает видимость данных в дереве. Данные доступны иерархически, т.е. любая задача или условие может получить данные от всех задач текущего состояния и его предка в иерархии. Такой подход позволяет организовать удобную передачу данных: задача родительского состояния выполняет запрос, например, к систему EQ, получает цель для перемещения, а потомки состояния запускают задачи навигации используя результаты задачи родительского состояния.

В следующий раз мы разберемся какие переменные и функции доступны для State Tree и попробуем собрать простой боевой ИИ.

ICRGravityController

Очевидно, раз мой пет проект начинает заигрывать с гравитацией, то на одной ленте Мебиуса останавливаться я не буду, поэтому надо организовывать все так, чтобы я мог делать какие угодно локальные изменения гравитации. Лучший подход для этого - создать интерфейс. Это позволит мне выбрать любой подход к изменению гравитации игрока в будущем: и если Лента Мебиуса это Actor, то в дальнейшем за изменение гравитации может отвечать, например, компонент.

// This class does not need to be modified.
UINTERFACE(BlueprintType)
class UCRGravityController : public UInterface
{
	GENERATED_BODY()
};

/**
 * 
 */
class FPSGAME_API ICRGravityController
{
	GENERATED_BODY()

	// Add interface functions to this class. This is the class that will be inherited to implement this interface.
public:

	virtual void GetGravityAndOrientation(FVector WorldLocation, FVector& Gravity, FVector& Orientation) {};
};

Я специально разделил направление гравитации и ориентацию для ситуаций, когда игрок сошел с нашей ленты в сторону, и мы хотим вернуть его на ленту, но не поворачивать его ориентацию. В общем же случае гравитация и ориентация совпадают с нормалью поверхности нашей ленты Мебиуса. Здесь и далее под ориентацией я понимаю вектор “вверх” капсулы игрока (в каком то смысле Pitch). Так как мой пет проект - это FPS, то остальные вращения либо не важны (Roll), либо управляются игроком (Yaw)

Теперь надо слегка модифицировать наш класс ленты.

Первым делом добавим реализацию нашего интерфейса:

class FPSGAME_API ACRMobiusStrip : public AActor, public ICRGravityController
.
.
.
virtual void GetGravityAndOrientation(FVector WorldLocation, FVector& Gravity, FVector& Orientation) override;

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

	UPROPERTY(VisibleAnywhere,BlueprintReadWrite)
	class USplineComponent* MobiusSplineComponent

	FSplinePoint Point(index, Location, ESplinePointType::Curve, Rotator);
	//setup additional spline for storing Rotation
	MobiusSplineComponent->AddPoint(Point);

Считаем гравитацию

Теперь приступим к реализации самой гравитации. Мы хотим, чтобы наша гравитация менялась плавно, а не скачками между точками сплайна. Для этого получим текущую точку на сплайне и два узла.

const FVector LocationOnSpline = MobiusSplineComponent->FindLocationClosestToWorldLocation(WorldLocation, ESplineCoordinateSpace::Type::World);

const float Key = MobiusSplineComponent->FindInputKeyClosestToWorldLocation(WorldLocation);
	
const FQuat QuatAtStart = MobiusSplineComponent->GetRotationAtSplineInputKey(FMath::Floor(Key),ESplineCoordinateSpace::Type::World).Quaternion();
FQuat QuatAtEnd = MobiusSplineComponent->GetRotationAtSplineInputKey(FMath::CeilToFloat(Key),ESplineCoordinateSpace::Type::World).Quaternion();

Дальше надо учесть, что наша ориентация ведет себя не гладко, и в точке соединения начала и конца ленты у нас разрыв. Учтём его.

if ( NumberOfHalfTurns % 2 != 0 && FMath::CeilToFloat(Key) == MobiusSplineComponent->GetNumberOfSplinePoints())
{
	QuatAtEnd = QuatAtEnd * FQuat(FRotator(0.0f, 0.0f , -180.f));
}

Получаем итоговое значение ориентации в данной точке сплайна:

	const FQuat Rotation = FQuat::Slerp(QuatAtStart, QuatAtEnd, FMath::Frac(Key));

N.B. Я намеренно использую Кватернионы, а не ротаторы, т.к. поскольку мы крутимся достаточно рандомно и непредсказуемо, шансы получить шарнирный замок (gimbal lock) очень высоки, поэтому лучше использовать Кватернионы.

Сохраним расстояние от оси нашей ленты:

FVector Distance = WorldLocation - LocationOnSpline;
const float WidthOffset = Rotation.GetAxisY().Dot(Distance);

Теперь у нас 3 варианта: мы находимся “над”(где под вертикалью мы понимаем ориентацию ленты)  плоскостью нашей ленты, сбоку от ней, или в области ребра.

Разберем все 3 случая отдельно.

Мы над лентой

Этому соответствует условие

FMath::Abs(WidthOffset) < SegmentWidth/2

Тут все просто: если направление до нас совпадает с направлением нормали, то гравитация противоположна направлению нормали (тянет нас к ленте). Если мы находимся под лентой, то гравитация должна совпадать с нормалью (опять же  тянуть нас к ленте). Ориентация капсулы игрока противоположна направлению гравитации:

FVector MobiusUp = Rotation.GetAxisZ();
if ((Distance).GetSafeNormal().Dot(MobiusUp) < 0.0f)
{
	MobiusUp = MobiusUp * -1.0f;
}	
		
Orientation =  MobiusUp;
Gravity = MobiusUp * -1.0f;

Мы сбоку от ленты

Этому соответствует условие

FMath::Abs(WidthOffset) > SegmentWidth/2

Для начала поймем, что мы не на грани.

const float HeightOffset = Rotation.GetAxisZ().Dot(Distance);
	
if (FMath::Abs(HeightOffset) > SegmentDepth/2)
{

Мы хотим, чтобы игрок вернулся на ленту, но при этом не хотим крутить ему ориентацию, так как такое возвращение будет скорее небольшим улучшением UX, а не полноценной механикой.

Тянем его к точке на поверхности, на которой он может стоять. Ориентация соответствует предыдущему случаю.

const FVector FloorPoint = LocationOnSpline + Distance.ProjectOnToNormal(Rotation.GetAxisZ()).GetSafeNormal() * SegmentDepth/2;
FVector ToFloorPointDirection = Gravity = (FloorPoint - WorldLocation).GetSafeNormal();
FVector MobiusUp = Rotation.GetAxisZ();
if ((Distance).GetSafeNormal().Dot(MobiusUp) < 0.0f)
{
	MobiusUp = MobiusUp * -1.0f;
}
Orientation =  MobiusUp;
Gravity = ToFloorPointDirection;

Мы на грани

Условия:

FMath::Abs(WidthOffset) > SegmentWidth/2
FMath::Abs(HeightOffset) < SegmentDepth/2

В последний случае мы на грани ленты. Он самый интересный, тк мы хотим дать игроку две возможности. Первая - поменять сторону ленты, т.е. игрок должен иметь возможность плавно менять ориентацию. Вторая - это при правильном управлении балансировать на грани ленты.

Для начала посчитаем “вверх” относительно поверхности ленты и относительно  грани:

FVector MobiusUp = Rotation.GetAxisZ();
if ((Distance).GetSafeNormal().Dot(MobiusUp) < 0.0f)
{
	MobiusUp = MobiusUp * -1.0f;
}
			
FVector SideUp = Rotation.GetAxisY();		
		
if (WidthOffset < 0.0f)
{
	SideUp = SideUp * -1.0f;
}

Теперь в зависимости от положения по “вертикали”, получим значение, насколько глубоко игрок зашел “в грань”

	const float LerpAlpha = 1.0f - FMath::Abs(HeightOffset / (SegmentDepth/2));

Теперь интерполируем между двумя векторами получая вектор “вверх” для игрока

Orientation = FVector::SlerpVectorToDirection(MobiusUp, SideUp, LerpAlpha);		

Для гравитации сделаем проще: пытаемся вернуть игрока туда откуда он прошел на грань, плюс в направлении к ленте - это позволит ему поймать момент и остаться на грани

Gravity = MobiusUp;
FVector SideDown = SideUp * -1.0f;
Gravity = FVector::SlerpVectorToDirection(Gravity, SideDown, LerpAlpha);		

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

P.S.  Финальный код функции вычисления гравитации:

void ACRMobiusStrip::GetGravityAndOrientation(FVector WorldLocation, FVector& Gravity, FVector& Orientation)
{
	const FVector LocationOnSpline = MobiusSplineComponent->FindLocationClosestToWorldLocation(WorldLocation, ESplineCoordinateSpace::Type::World);

	const float Key = MobiusSplineComponent->FindInputKeyClosestToWorldLocation(WorldLocation);
	
	const FQuat QuatAtStart = MobiusSplineComponent->GetRotationAtSplineInputKey(FMath::Floor(Key),ESplineCoordinateSpace::Type::World).Quaternion();
	FQuat QuatAtEnd = MobiusSplineComponent->GetRotationAtSplineInputKey(FMath::CeilToFloat(Key),ESplineCoordinateSpace::Type::World).Quaternion();

	if ( NumberOfHalfTurns % 2 != 0 && FMath::CeilToFloat(Key) == MobiusSplineComponent->GetNumberOfSplinePoints())
	{
		QuatAtEnd = QuatAtEnd * FQuat(FRotator(0.0f, 0.0f , -180.f));
	}

	const FQuat Rotation = FQuat::Slerp(QuatAtStart, QuatAtEnd, FMath::Frac(Key));
	FVector Distance = WorldLocation - LocationOnSpline;
	const float WidthOffset = Rotation.GetAxisY().Dot(Distance);
	if (FMath::Abs(WidthOffset) > SegmentWidth/2)
	{
		//we outside spline
		const float HeightOffset = Rotation.GetAxisZ().Dot(Distance);
	
		if (FMath::Abs(HeightOffset) > SegmentDepth/2)
		{		
			//we not inside spline depth		
			//DrawDebugSphere(GetWorld(), FloorPoint, 100.0f, 32, FColor::Blue, false);
			const FVector FloorPoint = LocationOnSpline + Distance.ProjectOnToNormal(Rotation.GetAxisZ()).GetSafeNormal() * SegmentDepth/2;
			FVector ToFloorPointDirection = Gravity = (FloorPoint - WorldLocation).GetSafeNormal();
			FVector MobiusUp = Rotation.GetAxisZ();
			if ((Distance).GetSafeNormal().Dot(MobiusUp) < 0.0f)
			{
				MobiusUp = MobiusUp * -1.0f;
			}
			Orientation =  MobiusUp;
			Gravity = ToFloorPointDirection;
		}
		else
		{
			FVector MobiusUp = Rotation.GetAxisZ();
			if ((Distance).GetSafeNormal().Dot(MobiusUp) < 0.0f)
			{
				MobiusUp = MobiusUp * -1.0f;
			}
			
			FVector SideUp = Rotation.GetAxisY();		
		
			if (WidthOffset < 0.0f)
			{
				SideUp = SideUp * -1.0f;
			}

			const float LerpAlpha = 1.0f - FMath::Abs(HeightOffset / (SegmentDepth/2));
			
			Orientation = FVector::SlerpVectorToDirection(MobiusUp, SideUp, LerpAlpha);			
			//DrawDebugDirectionalArrow(GetWorld(), LocationOnSpline, LocationOnSpline + MobiusUp *200.f, 20, FColor::Green, false);
			Gravity = MobiusUp;
			FVector SideDown = SideUp * -1.0f;
			Gravity = FVector::SlerpVectorToDirection(Gravity, SideDown, LerpAlpha);		
		}
	}
	else
	{
		FVector MobiusUp = Rotation.GetAxisZ();
		if ((Distance).GetSafeNormal().Dot(MobiusUp) < 0.0f)
		{
			MobiusUp = MobiusUp * -1.0f;
		}	
		
		Orientation =  MobiusUp;
		Gravity = MobiusUp * -1.0f;
	}

	//DrawDebugDirectionalArrow(GetWorld(), WorldLocation, WorldLocation + Orientation *200.f, 20, FColor::Green, false);
}

FHitResult - это структура, которая проскакивает в любом взаимодействии с физикой в UE, будь то касты или попытки пошевелить какого-нибудь хитрого актора (потому что там внутри все равно касты и свипы). В ней все поля интересные, но начнем с простого.

bBlockingHit отвечает за определение - было ли это столкновение(Blocking Hit)  или просто пересечение (Overlap).По факту тут возвращаются настройки реакции sweep на встречный объект.

bStartPenetrating отвечает за то, начали ли мы наш sweep из физического объекта.

PhysMaterial, HitObjectHandle, Component, PhysicsObjectOwner, PhysicsObject,BoneName, MyBoneName : в этих полях хранится информация об объектах, с которыми наш sweep столкнулся или пересекся. В основном назначение поля понятно из названия, но есть момент: PhysMaterial по умолчанию не передается , а чтобы его передать надо выставить флаг в  FCollisionQueryParams::bReturnPhysicalMaterial (эта структура тоже полна чудес)

TraceStart, TraceEnd отвечают за стартовую и конечную точку нашего sweep.

Distance,Time отвечают за время (параметр от 0 до 1) и расстояние от TraceStart до точки столкновения

И вот мы подходим к интересному:

ImpactPoint точка столкновения, т.е. точка в пространстве, где два коллайдера коснулись.

Location  координаты в пространстве, в которых, если поместить форму, с помощью которой мы совершаем sweep, форма коснется коллайдера в точке ImpactPoint

Normal это условная нормаль: направление прямой, соединяющей центр нашей формы, помещенной в Location и точку ImpactPoint

ImpactNormal это реальная нормаль поверхности, о которую стукнулась наша форма.

Вот небольшая схема для визуализации.

Перепланирование.

Как говорилось раньше, в саму архитектуру планировщиков не заложена идея, что план может стать неактуальным во время его выполнения, а значит внешняя система должна следить за актуальностью плана. Один из методов - это проверка актуальности цели и актуальности всех умных объектов, которые задействованы. Очевидно, что такие проверки надо проводить периодически. Так или иначе, в определенный момент времени нам будет необходимо прервать текущий план и создать новый план. Такой подход вызывает большую нагрузку на производительность, при чем это позволяет отследить только потерю актуальности у плана, а для того чтобы оценить, нет ли у агента поведения оптимальнее, придется постоянно генерировать планы и смотреть, не появилось ли более оптимальное действие.

Коллизии планов

Планы могут обладать коллизиями. Например, если оба агента хотят открыть одну и ту же дверь, первой попыткой решить такую коллизию будет создание запрета на доступность объекта (двери), как только агент начал выполнять план. К счастью, все объекты, с которыми взаимодействует наш ИИ, умные объекты, поэтому реализовать такой запрет не составит труда. Но такой подход генерирует другую проблему: если агент не справился со своим планом (например его убил игрок), а план был актуальный, высока вероятность того, что и другой агент посчитает этот план оптимальным. В итоге у нас получится поведение, где один агент за другим пытаются использовать объект, а их убивает игрок. Такое поведение выглядит глупым, поэтому логично добавить не просто флаг, а тайм аут на использование объекта.

Заскриптованное поведение.

Одним из бонусов GOAP является то, что поведение выглядит динамичным и не заскриптованным, но иногда это является проблемой. Очень часто в играх мы хотим каких-то фиксированных реакций на какие-то события. Игрок проводит добивание, соседние рядом противники начинают разбегаться, командир отряда используют способность, остальные участники отряда пытаются его прикрыть и т.д. В архитектуру GOAP не заложены простые способы реализации таких поведений. Можно, конечно, делать скриптованные цели и под них простые планы с реакциями, но такие вещи быстро уничтожают все изящество и удобство GOAP. Одним из способов такой проблемы может быть использование среднеуровневой логики.

Среднеуровневый логика

Со многими вышеуказанными проблемами столкнулась команда Monolith, которая и придумала GOAP для своей игры F.E.A.R. Одним из подходов, к которым пришла команда Monolith, было отвести планеру место в середине архитектурной иерархии. Под этим подразумевается, что не стоит перегружать планировщика информацией о низкоуровневых вещах. Например какую позу или анимацию сейчас играет персонаж, и добавлять в план действие смены позы. Такие действия усложняют планы и делают их создание более медленным с точки зрения производительности. Анимационная система может сама добавить смену позы или анимацию экипировки оружия перед атакой или началом плана. Это позволяет плану концентрироваться именно на действиях и поведении, а не на навигации, анимациях и подготовке. С другой стороны, не стоит перегружать планировщик и верхнеуровневой информацией. Если один ИИ может выполнять несколько ролей, или у него может быть разное состояние (отравлен, сломлен, напуган), не стоит пытаться поместить это все в состояние мира и заставлять планировщик решать такие задачи. Напишите более высокоуровневую систему, которая будет подменять список задач и действий у вашего агента на соответствующий его роли/состоянию. Это упростит и выбор целей, и построение плана.

Hierarchical Task Network (HTN) Planning

Иерархическая сеть задач является смежными с GOAP подходом. В отличие от GOAP, в котором мы ищем план, перемещаясь по графу действий, пока не получим план, удовлетворяющий наши цели, HTN использует декомпозицию задач превращая их в простые атомарные действия.

Задача (task)

В HTN задачи могут быть двух типов: примитивные и составные. Примитивные задачи - это одно атомарное действие, схожее с действиями в GOAP. Например, атаковать игрока или подобрать оружие. Целью работы модели является создание последовательности примитивных задач. Примитивная задача состоит из оператора и набора эффектов и условий. Составные задачи состоят из набора методов. Каждый метод состоит из условия и набора задач.

Оператор

Оператор - это простое действие, лишенное контекста. Например, атаковать или переместиться куда-то. Именно задача дает оператору контекст, чтобы стать полноценным действием для ИИ агента. Разные задачи могут использовать одинаковые операторы, но разные контексты, условия и эффекты приводят к разнообразному поведению

Эффекты и Условия

По аналогии с GOAP, эффекты - это то, как изменяется состояние мира при выполнении этого действия, а условия - это то, каким должно быть состояние мира, чтобы эта задача имела смысл.

Построение плана.

HTN начинает с высокоуровневой составной задачи, которая последовательно разбивается на подзадачи, используя методы и условия в них. В результате мы получаем план, который выполняет агент. Например, задача “Выковать меч” может быть разбита на подзадачи “Достать Железо”, “Перейти В Кузню”, “Обработать Железо”. В свою очередь, “Достать Железо” может быть разбито на “Перейти на склад”, “Взять Железо” или  “Перейти в шахты”, “Добыть Железо”, в зависимости от состояния мира, в частности - есть ли железо на складе.

Особенности HTN

HTN обладает такими же минусами и плюсами, как и GOAP, так как по сути этот тоже планировщик, только с подходом сверху вниз к поиску плана. Если вас заинтересовала подробная работа HTN, есть отличная статья на эту тему

Групповые Планы.

В заключение, хотел бы упомянуть подход кооперативных планов. Про этот подход рассказывали на GDC . Идея подхода в том, чтобы позволить одному агенту попросить помощи у другого. При составлении плана один агент может использовать другого агента как действие, которое поменяет состояние мира, как полезно для плана первого агента. В этот момент планирование останавливается, и мы запрашиваем другого агента составить план, где целью является то состояние мира, которое первый агент хочет получить в результате действия. Если такой план возможен, и агент не занят чем-то другим, мы сохраняем второй план и продолжаем планировать первый план. Если все получилось, у нас есть два плана, которые мы можем выполнить.

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

Готовые решения

Самостоятельная реализация такой модели выбора поведения может быть нетривиальной задачей, требующей понимания архитектуры современных игр. Реализация должна взаимодействовать с множеством других подсистем для создания правильного состояния мира. Часто встает вопрос оптимизации и организации удобной настройки поведения. Поэтому чаще всего лучше использовать готовые решения. Например, для Unreal Engine 5 есть плагин Hierarchical Task Network Planning AI , позволяющий создавать поведения, используя иерархический планировщик.

В следующий раз мы с вами рассмотрим гибридные ИИ, т.е. ИИ, которые сочетают в себе две модели (например, FSM и Behaviour Tree).

Уровень лента

.Для начала я определился с требованиями к генератору:

1. Размер и положение ленты должно быть удобно для настройки.
2. Лента должна быть процедурно генерируемая.
3. Алгоритм должен быть простой и достаточно быстрый, чтобы я мог использовать её в рантайме со случайными параметрами, чтобы генерировать новые уровни.

С такими требованиями я принял пару решений. За основу взял зацикленный сплайн в USplineComponent.  Для отображения сначала попробовал использовать UProceduralMeshComponent, но потом поменял свое решение в пользу UDynamicMeshComponent. Во-первых, потому что динамические меши добавили в 5.0 и их сейчас активно развивают. Во вторых, для них написано много реализации в UGeometryScriptLibrary_MeshPrimitiveFunctions, куда я могу обращаться за примерами.

Генерация Ориентации.

Способом генерации я выбрал вращение вертикального вектора, в частности:

1. Разбиваем весь сплайн на равные участки нужной длины.(это позволит мне контролировать детализацию ленты)
2. Проходим все участки в цикле, каждый раз поворачивая вертикальный вектор на угол равный 360.0/количество участков.
3. Генерируем вершины нашей ленты, и соединяем их в треугольники, которые отправляем в dynamicmesh.

Для проверки теории я решил быстро реализовать первые два пункта и проверить, что я правильно разобрался в интерфейсе USplineComponent.

UCLASS()
class FPSGAME_API ACRMobiusStrip : public AActor
{
	GENERATED_BODY()

public:
	// Sets default values for this actor's properties
	ACRMobiusStrip();

	UFUNCTION(CallInEditor, BlueprintCallable)
	void  GenerateStrip();

protected:
	UPROPERTY(EditAnywhere)
	float SegmentLenght = 100;
	UPROPERTY(EditAnywhere)
	float SegmentWidth = 500;

	UPROPERTY(VisibleAnywhere,BlueprintReadWrite)
	class UDynamicMeshComponent* MobiusMesh;
	UPROPERTY(VisibleAnywhere,BlueprintReadWrite)
	class USplineComponent* SplineComponent;
	UPROPERTY(VisibleAnywhere,BlueprintReadWrite)
	class USplineComponent* MobiusSplineComponent;
};

N.B. полезный атрибут функции в UE CallInEditor. Он добавляет кнопку в редактор, которая и вызывает функцию. Это очень удобно для тестирования генераторов и неигровых логик.

void ACRMobiusStrip::GenerateStrip()
{
   float splineLenght = SplineComponent->GetSplineLength();
   int numOfSteps = FMath::FloorToInt(splineLenght/SegmentLenght);
   FVector UpVector = FVector::UpVector;
  
   for (int index = 0; index <= numOfSteps; ++index )
   {
      FVector Location = SplineComponent->GetLocationAtDistanceAlongSpline(SegmentLenght * index, ESplineCoordinateSpace::Type::World);
      FRotator Direction = SplineComponent->GetRotationAtDistanceAlongSpline(SegmentLenght * index, ESplineCoordinateSpace::Type::Local);
      FVector DirectionUp = UpVector.RotateAngleAxis(360.0/numOfSteps *index, Direction.Vector());


      DrawDebugDirectionalArrow(GetWorld(), Location, Location + DirectionUp *200.f, 20, FColor::Green, false);
   }
}

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

В результате получаем следующую картину:

Треугольники

Теперь осталось построить прямоугольники на каждом участке, и лента готова.

Подглядев на то, как с UDynamicMeshComponent работают в движке, я увидел два способа: собрать свою версию FMeshShapeGenerator , либо взять меш из компонента и настраивать вершины и треугольники напрямую. Я выбрал второй путь и остался доволен, так как это позволило мне контролировать материалы и UV в одном месте.

Давайте начнем создавать вершины. На каждом участке делаем две вершины в плоскости, для которой наш повернутый вектор будет нормалью, сделав отступ вправо и влево от точки на сплайне.

FVector Vert0 = Location + Rotator.RotateVector(FVector::RightVector) * SegmentWidth /2;
FVector Vert1 = Location + Rotator.RotateVector(FVector::RightVector) * SegmentWidth /2;

Добавим эти вершины в наш меш, сохраним индекс первой вершины:

int StartVertIndex = MobiusMesh3->AppendVertex(UE::Geometry::FVertexInfo(Vert0));
MobiusMesh3->AppendVertex(UE::Geometry::FVertexInfo(Vert1));

Теперь для всех шагов, кроме первого (на первом у нас всего 2 вершины, треугольник не сделать), возьмем вершины с прошлого шага и сделаем из них 2 треугольника.

if (index != 0)
{
   UE::Geometry::FIndex3i Tri(PrevStartVertIndex, StartVertIndex, StartVertIndex + 1 );
   MobiusMesh3->AppendTriangle(Tri);       
   Tri = UE::Geometry::FIndex3i(StartVertIndex + 1 , PrevStartVertIndex + 1,PrevStartVertIndex);       
   MobiusMesh3->AppendTriangle(Tri);
}


PrevStartVertIndex = StartVertIndex;

Получаем следующий меш:

DynamicMesh3* MobiusMesh3 = MobiusMesh->GetDynamicMesh()->GetMeshPtr(); 

Сразу видны три проблемы: первая - это не лента мебиуса, а просто перекрученная лента. И вправду - мой вектор нормали делает полный оборот, и поэтому получается две поверхности. Заменим нашу константу на настраиваемый параметр количества полуоборотов, что даст мне возможность генерировать любые ленты. Вторая проблема - это отсутствие последних треугольников, которые замкнут петлю. С этой проблемой мы разберемся в конце. Последняя проблема - это то, что лента видна только с одной стороны. Эту проблему можно решить с помощью шейдера, но я все равно хотел добавить толщины ленте (так как игрок будет двигаться по ней, он должен иметь возможность увидеть грань).

Прежде чем добавлять толщину, приведу полный код с исправленной проблемой полного оборота.

UCLASS()
class FPSGAME_API ACRMobiusStrip : public AActor
{
	GENERATED_BODY()
	.
	.
	.
	UPROPERTY(EditAnywhere)
	int NumberOfHalfTurns = 1;

	float TotalAngle = 180.0f;
	.
	.
	.
}

void ACRMobiusStrip::GenerateStrip()
{
	float splineLenght = SplineComponent->GetSplineLength();
	int numOfSteps = FMath::FloorToInt(splineLenght/SegmentLenght);
	FVector UpVector = FVector::UpVector;

	TotalAngle = NumberOfHalfTurns * 180.0f;
	
	FDynamicMesh3* MobiusMesh3 = MobiusMesh->GetDynamicMesh()->GetMeshPtr();
	MobiusMesh3->Clear();

	int PrevStartVertIndex = 0;

	for (int index = 0; index <= numOfSteps; ++index )
	{
		FVector Location = SplineComponent->GetLocationAtDistanceAlongSpline(SegmentLenght * index, ESplineCoordinateSpace::Type::Local);
		FRotator Direction = SplineComponent->GetRotationAtDistanceAlongSpline(SegmentLenght * index, ESplineCoordinateSpace::Type::Local);
		FVector DirectionUp = UpVector.RotateAngleAxis(360.0/numOfSteps *index, Direction.Vector());
		FRotator Rotator = FRotationMatrix::MakeFromZX(DirectionUp, Direction.Vector()).Rotator();

		FVector Vert0 = Location +  Rotator.RotateVector(FVector::RightVector) * SegmentWidth /2;
		FVector Vert1 = Location - Rotator.RotateVector(FVector::RightVector) * SegmentWidth /2;
		
		int StartVertIndex = MobiusMesh3->AppendVertex(UE::Geometry::FVertexInfo(Vert0));
		MobiusMesh3->AppendVertex(UE::Geometry::FVertexInfo(Vert1));
		
		if (index != 0)
		{
			UE::Geometry::FIndex3i Tri(PrevStartVertIndex, StartVertIndex, StartVertIndex + 1 );
			MobiusMesh3->AppendTriangle(Tri);			
			Tri = UE::Geometry::FIndex3i(StartVertIndex + 1 , PrevStartVertIndex + 1,PrevStartVertIndex);			
			MobiusMesh3->AppendTriangle(Tri);
		}

		PrevStartVertIndex = StartVertIndex;
	}

Толщина

Теперь добавим толщину: нам понадобятся еще две вершины. Наши старые вершины поднимем на половину заданной высоты (SegmentDepth) вдоль нормали нашей плоскости, а новые опустим вниз.

FVector Vert2 = Location - DirectionUp * SegmentDepth/2 + Rotator.RotateVector(FVector::RightVector) * SegmentWidth /2;
FVector Vert3 = Location - DirectionUp * SegmentDepth/2 - Rotator.RotateVector(FVector::RightVector) * SegmentWidth /2;
.
.
.
MobiusMesh3->AppendVertex(UE::Geometry::FVertexInfo(Vert2));
MobiusMesh3->AppendVertex(UE::Geometry::FVertexInfo(Vert3));

Теперь у нас 4 узла и мы можем собрать верхнюю, нижнюю и боковые плоскости нашей “ленты”.

//up plane
UE::Geometry::FIndex3i Tri(PrevStartVertIndex, StartVertIndex, StartVertIndex + 1 );
MobiusMesh3->AppendTriangle(Tri);
Tri = UE::Geometry::FIndex3i(StartVertIndex + 1 , PrevStartVertIndex + 1,PrevStartVertIndex);			
MobiusMesh3->AppendTriangle(Tri);
			
//bottom plane
Tri = UE::Geometry::FIndex3i(PrevStartVertIndex + 3, StartVertIndex + 3, StartVertIndex + 2 );
MobiusMesh3->AppendTriangle(Tri);
Tri = UE::Geometry::FIndex3i(StartVertIndex + 2, PrevStartVertIndex + 2, PrevStartVertIndex + 3 );
MobiusMesh3->AppendTriangle(Tri);

//left  side
Tri = UE::Geometry::FIndex3i(PrevStartVertIndex + 2, StartVertIndex+ 2 , StartVertIndex );
MobiusMesh3->AppendTriangle(Tri);
Tri = UE::Geometry::FIndex3i(StartVertIndex, PrevStartVertIndex, PrevStartVertIndex+ 2 );
MobiusMesh3->AppendTriangle(Tri);			

//right side
Tri = UE::Geometry::FIndex3i(PrevStartVertIndex + 1, StartVertIndex +1, StartVertIndex + 3 );
MobiusMesh3->AppendTriangle(Tri);			
Tri = UE::Geometry::FIndex3i(StartVertIndex + 3, PrevStartVertIndex + 3, PrevStartVertIndex + 1);
MobiusMesh3->AppendTriangle(Tri);

Запускаем и получаем результат

Теперь давайте замкнем нашу петлю. С помощью блокнота и ручки я сумел понять, какие вершины с какими образовывают треугольник, и написал отдельную логику для последней секции.

//we did half full  turn we need consider it in indexes
if (index == numOfSteps && NumberOfHalfTurns % 2 != 0)
{
	//up plane
	UE::Geometry::FIndex3i Tri(PrevStartVertIndex + 3, StartVertIndex, StartVertIndex + 1 );
	MobiusMesh3->AppendTriangle(Tri);
	Tri = UE::Geometry::FIndex3i(StartVertIndex + 1 , PrevStartVertIndex + 2,PrevStartVertIndex + 3);			
	MobiusMesh3->AppendTriangle(Tri);				
				
	//bottom plane
	Tri = UE::Geometry::FIndex3i(StartVertIndex + 3, StartVertIndex + 2,  PrevStartVertIndex + 1);
	MobiusMesh3->AppendTriangle(Tri);
	Tri = UE::Geometry::FIndex3i(PrevStartVertIndex + 1 , PrevStartVertIndex , StartVertIndex + 3);
	MobiusMesh3->AppendTriangle(Tri);			
				
	//left  side			
	Tri = UE::Geometry::FIndex3i(PrevStartVertIndex + 1, StartVertIndex+ 2 , StartVertIndex );
	MobiusMesh3->AppendTriangle(Tri);	
	Tri = UE::Geometry::FIndex3i(StartVertIndex, PrevStartVertIndex+3, PrevStartVertIndex+ 1 );
	MobiusMesh3->AppendTriangle(Tri);	
}

Теперь наша петля замкнута:

MobiusMesh->SetComplexAsSimpleCollisionEnabled(true);

UV и материалы.

MobiusMesh3->EnableAttributes();

UE::Geometry::FDynamicMeshUVOverlay* UVOverlay 
                           = MobiusMesh3->Attributes()->PrimaryUV();
UE::Geometry::FDynamicMeshMaterialAttribute* MaterialAttribute
                           = MobiusMesh3->Attributes()->GetMaterialID();

UVOverlay->SetTriangle(tid, UVUpTri);
MaterialAttribute->SetNewValue(tid, 1);

MobiusMesh->SetMaterial(0, BaseMaterial);

Я завел поле для материала, в моем классе.

UPROPERTY(EditAnywhere)
UMaterialInterface* BaseMaterial;

Для UV развертки я решил, что у меня будет очень длинная лента в UV пространстве, которую я переадресую на мои треугольники равномерно. Будем добавлять точки к нашему UVOverlay  на каждом шаге цикла, генерируя небольшую полоску в UV пространстве, на которую будем проецировать все наши треугольники в этом шаге цикла.

Добавляем две вершины.

float UVYOffest = SegmentLenght * index/ SegmentWidth;
int StartUVIndex = UVOverlay->AppendElement(FVector2f(0.0f, UVYOffest));
UVOverlay->AppendElement(FVector2f(1.0f,UVYOffest));

Создаем два треугольника в UV пространстве.

UE::Geometry::FIndex3i UVUpTri(PrevStartUVIndex, StartUVIndex, StartUVIndex + 1 );
UE::Geometry::FIndex3i UVDownTri(StartUVIndex+1, PrevStartUVIndex+1, PrevStartUVIndex);

Сохраняем индексы наших треугольников и добавляем адресацию между треугольниками меша и UVOverlay

UE::Geometry::FIndex3i Tri(PrevStartVertIndex, StartVertIndex, StartVertIndex + 1 );
int tid = MobiusMesh3->AppendTriangle(Tri);      
UVOverlay->SetTriangle(tid, UVUpTri);


Tri = UE::Geometry::FIndex3i(StartVertIndex + 1 , PrevStartVertIndex + 1,PrevStartVertIndex);        
tid = MobiusMesh3->AppendTriangle(Tri);
UVOverlay->SetTriangle(tid, UVDownTri);

Повторяем для всех треугольников. Назначаем тестовый материал для дебага UV.

N.B. для последнего шага цикла, когда мы замыкаем петлю, мне понадобилась дополнительная магия с UV, чтобы все красиво сошлось в месте начала петли. Я честно добился правильной развертки методом проб и ошибок, но наверное это можно было вычислить как-то заранее.

В итоге я получил вот такой меш.

P.S.

Финальный код если кто то решит его прочитать

void ACRMobiusStrip::GenerateStrip()
{
	float splineLenght = SplineComponent->GetSplineLength();
	int numOfSteps = FMath::FloorToInt(splineLenght/SegmentLenght);
	FVector UpVector = FVector::UpVector;

	TotalAngle = NumberOfHalfTurns * 180.0f;
	
	FDynamicMesh3* MobiusMesh3 = MobiusMesh->GetDynamicMesh()->GetMeshPtr();
	MobiusMesh3->Clear();
	MobiusMesh3->EnableAttributes();
	MobiusMesh3->Attributes()->EnableMaterialID();
	UE::Geometry::FDynamicMeshUVOverlay* UVOverlay = MobiusMesh3->Attributes()->PrimaryUV();
	UE::Geometry::FDynamicMeshMaterialAttribute* MaterialAttribute = MobiusMesh3->Attributes()->GetMaterialID();
	
	int PrevStartVertIndex = 0;
	int PrevStartUVIndex = 0;
	

	
	for (int index = 0; index <= numOfSteps; ++index )
	{
		FVector Location = SplineComponent->GetLocationAtDistanceAlongSpline(SegmentLenght * index, ESplineCoordinateSpace::Type::Local);
		FRotator Direction = SplineComponent->GetRotationAtDistanceAlongSpline(SegmentLenght * index, ESplineCoordinateSpace::Type::Local);
		FVector DirectionUp = UpVector.RotateAngleAxis(TotalAngle/numOfSteps *index, Direction.Vector());
		FRotator Rotator = FRotationMatrix::MakeFromZX(DirectionUp, Direction.Vector()).Rotator();
		int StartVertIndex = 0;
		if (index != numOfSteps)
		{
			FVector Vert0 = Location + DirectionUp * SegmentDepth/2 + Rotator.RotateVector(FVector::RightVector) * SegmentWidth /2;
			FVector Vert1 = Location + DirectionUp * SegmentDepth/2 - Rotator.RotateVector(FVector::RightVector) * SegmentWidth /2;
			FVector Vert2 = Location - DirectionUp * SegmentDepth/2 + Rotator.RotateVector(FVector::RightVector) * SegmentWidth /2;
			FVector Vert3 = Location - DirectionUp * SegmentDepth/2 - Rotator.RotateVector(FVector::RightVector) * SegmentWidth /2;
		
			StartVertIndex = MobiusMesh3->AppendVertex(UE::Geometry::FVertexInfo(Vert0));
			MobiusMesh3->AppendVertex(UE::Geometry::FVertexInfo(Vert1));
			MobiusMesh3->AppendVertex(UE::Geometry::FVertexInfo(Vert2));
			MobiusMesh3->AppendVertex(UE::Geometry::FVertexInfo(Vert3));
		}

		float UVYOffest = SegmentLenght * index/ SegmentWidth;
		int StartUVIndex = UVOverlay->AppendElement(FVector2f(0.0f, UVYOffest));
		UVOverlay->AppendElement(FVector2f(1.0f,UVYOffest));
		
		if (index != 0)
		{
			UE::Geometry::FIndex3i UVUpTri(PrevStartUVIndex, StartUVIndex, StartUVIndex + 1 );
			UE::Geometry::FIndex3i UVDownTri(StartUVIndex+1, PrevStartUVIndex+1, PrevStartUVIndex);
			//we did half full  turn we need consider it in indexes
			if (index == numOfSteps && NumberOfHalfTurns % 2 != 0)
			{
				//up plane
				UE::Geometry::FIndex3i Tri(PrevStartVertIndex + 3, StartVertIndex, StartVertIndex + 1 );
				int tid = MobiusMesh3->AppendTriangle(Tri);			
				UVOverlay->SetTriangle(tid, UVUpTri);
		
				Tri = UE::Geometry::FIndex3i(StartVertIndex + 1 , PrevStartVertIndex + 2,PrevStartVertIndex + 3);			
				tid = MobiusMesh3->AppendTriangle(Tri);
				UVOverlay->SetTriangle(tid, UVDownTri);
				
				//bottom plane
				UVUpTri = UE::Geometry::FIndex3i  (StartUVIndex, StartUVIndex + 1, PrevStartUVIndex+1 );
				UVDownTri =  UE::Geometry::FIndex3i(PrevStartUVIndex+1, PrevStartUVIndex, StartUVIndex);
				Tri = UE::Geometry::FIndex3i(StartVertIndex + 3, StartVertIndex + 2,  PrevStartVertIndex + 1);
				tid = MobiusMesh3->AppendTriangle(Tri);			
				UVOverlay->SetTriangle(tid, UVUpTri);
			
				Tri = UE::Geometry::FIndex3i(PrevStartVertIndex + 1 , PrevStartVertIndex , StartVertIndex + 3);
				tid = MobiusMesh3->AppendTriangle(Tri);			
				UVOverlay->SetTriangle(tid, UVDownTri);
				
				//left  side
				UVUpTri = UE::Geometry::FIndex3i  (PrevStartUVIndex , StartUVIndex, StartUVIndex + 1);
				UVDownTri =  UE::Geometry::FIndex3i(StartUVIndex + 1, PrevStartUVIndex+1, PrevStartUVIndex);

				Tri = UE::Geometry::FIndex3i(PrevStartVertIndex + 1, StartVertIndex+ 2 , StartVertIndex);
				tid = MobiusMesh3->AppendTriangle(Tri);			
				UVOverlay->SetTriangle(tid, UVUpTri);

				Tri = UE::Geometry::FIndex3i(StartVertIndex, PrevStartVertIndex+3, PrevStartVertIndex+ 1 );
				tid = MobiusMesh3->AppendTriangle(Tri);			
				UVOverlay->SetTriangle(tid, UVDownTri);

				//right side
				Tri = UE::Geometry::FIndex3i(PrevStartVertIndex + 2, StartVertIndex +1, StartVertIndex + 3 );
				tid = MobiusMesh3->AppendTriangle(Tri);			
				UVOverlay->SetTriangle(tid, UVUpTri);

				Tri = UE::Geometry::FIndex3i(StartVertIndex + 3, PrevStartVertIndex , PrevStartVertIndex + 2);
				tid = MobiusMesh3->AppendTriangle(Tri);			
				UVOverlay->SetTriangle(tid, UVDownTri);		
				
			}
			else
			{
				//up plane
				UE::Geometry::FIndex3i Tri(PrevStartVertIndex, StartVertIndex, StartVertIndex + 1 );
				int tid = MobiusMesh3->AppendTriangle(Tri);			
				UVOverlay->SetTriangle(tid, UVUpTri);
		
				Tri = UE::Geometry::FIndex3i(StartVertIndex + 1 , PrevStartVertIndex + 1,PrevStartVertIndex);			
				tid = MobiusMesh3->AppendTriangle(Tri);
				UVOverlay->SetTriangle(tid, UVDownTri);
				//bottom plane
				Tri = UE::Geometry::FIndex3i(PrevStartVertIndex + 3, StartVertIndex + 3, StartVertIndex + 2 );
				tid = MobiusMesh3->AppendTriangle(Tri);			
				UVOverlay->SetTriangle(tid, UVUpTri);
			
				Tri = UE::Geometry::FIndex3i(StartVertIndex + 2, PrevStartVertIndex + 2, PrevStartVertIndex + 3 );
				tid = MobiusMesh3->AppendTriangle(Tri);			
				UVOverlay->SetTriangle(tid, UVDownTri);
				//left  side

				Tri = UE::Geometry::FIndex3i(PrevStartVertIndex + 2, StartVertIndex+ 2 , StartVertIndex );
				tid = MobiusMesh3->AppendTriangle(Tri);			
				UVOverlay->SetTriangle(tid, UVUpTri);

				Tri = UE::Geometry::FIndex3i(StartVertIndex, PrevStartVertIndex, PrevStartVertIndex+ 2 );
				tid = MobiusMesh3->AppendTriangle(Tri);			
				UVOverlay->SetTriangle(tid, UVDownTri);

				//right side

				Tri = UE::Geometry::FIndex3i(PrevStartVertIndex + 1, StartVertIndex +1, StartVertIndex + 3 );
				tid = MobiusMesh3->AppendTriangle(Tri);			
				UVOverlay->SetTriangle(tid, UVUpTri);

				Tri = UE::Geometry::FIndex3i(StartVertIndex + 3, PrevStartVertIndex + 3, PrevStartVertIndex + 1);
				tid = MobiusMesh3->AppendTriangle(Tri);			
				UVOverlay->SetTriangle(tid, UVDownTri);
			}		
		}
		PrevStartUVIndex = StartUVIndex;
		PrevStartVertIndex = StartVertIndex;
	}

	MobiusMesh->NotifyMeshUpdated();
	MobiusMesh->SetMaterial(0, BaseMaterial);
}

Если вы джун или мидл.

Если вы только начали путь в программировании, или еще не до конца уверены в своих навыках, я настоятельно не рекомендую генерировать код с помощью LLM. Когда их обучают, перед компаниями не особо стоит цель отфильтровать материалы, объем данных должен статистически выправить ошибки. А открытые репозитории github - это на 90 процентов неизвестные студенческие или джуновские проекты, качество кода в которых оставляет желать лучшего. Я тут не исключение, мой гитхаб - это кошмар, ибо я заботился о нем только во времена поиска своей первой работы и с тех пор не трогал. Даже страшно представить, что за “чудо-код” я у себя там найду.

Поэтому LLM будет очень часто генерировать сомнительный код.Так что новичкам я рекомендую использовать LLM как личного репетитора или ментора: задавайте вопросы, просите провести ревью вашего кода, но старайтесь избегать именно генерации кода. В целом LLM - это отличный инструмент для обучения, жаль его не было у меня, когда я учил PHP и KOHANA

Если вы сеньор или лид.

Ситуация кардинально меняется, если у вас уже есть интуиция на плохой код, и вы уже умеете делать код ревью. Тут можно оттянуться по-полной. Я  собрал прототип за 5 дней с UI, главным меню и всем игровым циклом, при этом потратив раз в 5 меньше времени на код. В основном я рефакторил слишком простые решения (например атрибуты для моего аналога GAS GPT сгенерировала прямо в лоб, поэтому я их переписал и усложнил, как того требовал дизайн), интегрировал их вместе и настраивал ассеты в Юнити.

Я открыл пару вкладок Deepseek и параллельно отдавал на реализацию разные части прототипа, давая фидбэк и внося корректировки. Эдакий мясной лид нейро-джунов. Кстати, это забавно, но мне кажется, что для сеньора работа с LLM может стать хорошей практикой для общения с джунами.

Я для себя понял пару правил, которые позволили мне получать полезный код от GPT

1. Расписывайте подробно по пунктам, что нужно, короткими предложениями. Представьте, что вы делаете чеклист для Jira или QA. Тогда шансы на то, что LLM что-то не поймет или нафантазирует, сокращаются.
2. Декомпозируйте задачу. Несмотря на то, что сейчас в LLM можно закинуть много контекста, LLM очень часто игнорируют или понижают в приоритете середину запроса. Поэтому лучше работать в несколько этапов: просить что-то, а потом просить дорабатывать что вышло. Например. я сначала попросил собрать мне инвентарь со слотами, а потом попросил сделать систему сохранений, и вышло неплохо и без багов. Я старался держать размер запроса в 3-4 простых пункта для реализации.
3. Задавайте примеры. Если вы знаете, что именно вам нужно и что оно где-то было реализовано (в другом движке или фреймворке), прямо укажите это как пример. На удивление, это срабатывает очень хорошо.
4. Не мучайте LLM багофиксом. Она не сможет, она будет галлюцинировать и оверинженирить. Пофиксите это сами, когда будете интегрировать уже в проект.
5. Помогайте им с архитектурными решениями. Например, скажите, что использовать, как, что будет взаимодействовать.
6. Не доверяйте им интеграцию систем друг с другом. У меня не получилось заставить DeepSeek нормально поженить две системы без глупостей.

В принципе для прототипа мои нейро-джуны справились на ура, игра бегает, багов было мало, и у меня была куча свободного времени. Да, местами код кривоват, и не самый оптимальный, но я знаю кучу проектов, которые релизнулись с кодом хуже. Я был приятно удивлен результатом и рекомендую всем иногда отдавать генерацию кода LLM.

P.S. А еще я скормил Deepseek правила синтаксиса для PCG Gramar, и она с первого раза сгенерила мне код для грамматической генерации в юнити.

Планирование

Основой GOAP является создание и выполнение плана, состоящего из простых действий, с определенной и конкретной целью. Получающиеся из такого планирования поведения очень динамичны, чаще всего соответствуют ожиданиям игрока с учетом текущей обстановки в игре, и в целом отличаются от заскриптованных поведений разнообразием и иллюзией интеллекта.

Состояние Мира

Главным и важным компонентом GOAP является структурированное состояние мира. Наши предыдущие системы ИИ тоже анализировали что происходило в мире (где противник, ранен ли агент, видна ли текущая цель). В случае GOAP состояние мира является не абстрактной концепцией информации, необходимой для работы ИИ, а полноценным объектом в памяти, содержащим информацию о мире в понятном остальному алгоритму формате.

class GOAPWorldState

{

bool bPlayerDead = false;

int AliveAICount = 3;

bool AIHasWeapon = true;

int AmmoAmountInWeapon = 0;

};

Конечно же в реальных системах состояние мира использует контейнеры для записи информации, а не поля, по аналогии с Blackboard. Важно заметить, что состояние мира удобно сделать уникальным для каждого агента. Да, какие-то значения будут одинаковыми (например состояние Игрока) для всех агентов, но часть информации будет иметь смысл относительно конкретного ИИ агента. Такой подход связан с тем, что GOAP перекочевал в геймдев из робототехники, и там схожие алгоритмы работают непосредственно на агенте, который и будет выполнять план, поэтому все остальные агенты как бы не являются ИИ для робота, а являются внешними факторами состояния мира. В геймдеве же очевидно, что планирование и выполнение планов для всех агентов происходит внутри одной программы, а чаще всего внутри одной системы. Поэтому это порождает создание индивидуальных состояний мира для каждого агента, который хочет использовать GOAP.

Цель (Goal)

Цель в GOAP описывается тоже с помощью состояния мира: это набор нескольких полей из состояния мира, значения которых зафиксированы. Например целью может быть поднять предмет, т.е. флаг bHasItem в состоянии мира агента должен иметь значение true. Кроме того у каждой цели есть приоритет или полезность этой цели, т.е. цифровое представление того, насколько эта цель сейчас актуальна для игрока. В роли такого представления могут выступать функции полезности из UtilityBasedAI. В GOAP вместо выбора поведения агент выбирает цель, но для выбора используются аналогичные подходы и алгоритмы как в UtilityBasedAI.

Действия (Action)

Действия в GOAP - это маленькие простые поведения. Чаще всего это комбинации перемещения и либо совершения каких-то действий самим агентом (атака, кувырок, использование способности), либо взаимодействие с каким-то объектом в игровом мире (открыть дверь, поднять оружие, включить тревогу). Кроме самой реализации у действий есть несколько характеристик, необходимых для работы в GOAP.

Первая характеристика - это то, как это действие меняет состояние мира. Чаще всего эта характеристика описывается схожа с целями: это набор полей со значениями из состояния мира, обозначающие изменение состояния мира при выполнении этого действия. Например действие “открыть дверь” описывается полем DoorState = Open.

Вторая характеристика - это требования к состоянию мира для выполнения этого действия. Эта характеристика аналогична первой, но описывает состояние мира, необходимое для выполнения этого действия. Например действие стрельбы требует наличие у агента оружия дальнего боя.

Третья важная характеристика - это стоимость действия. Она описывает то, насколько затратно действие для агента. Эта характеристика появляется из-за того, что при планировании мы будем использовать алгоритмы поиска по графу, а следовательно стоимость позволит выбрать самый оптимальный план.

Smart Objects

В GOAP используется очень удобная концепция умных объектов(smart objects). В игровом ИИ агентам очень часто приходится взаимодействовать с интерактивными объектами в мире - это могут быть кнопки, двери и т.д. Планы и действия в  GOAP чаще всего не привязаны к конкретному агенту или объекту, действие может быть абстрактным (например подойти и провзаимодействовать с предметом). Поэтому необходим ассет, в котором будет храниться информация о том, как взаимодействовать с предметом (например какую анимацию проигрывать), состояние объекта (дверь открыта или закрыта) и т.д. Роль такого асета выполняют умные объекты. Умные объекты представляют собой структуру, в которой хранится вся информация, необходимая ИИ для взаимодействия с нею. Умные объекты чаще всего содержат в себе простой конечный аппарат (FSM) для описания своего состояния и для проигрывания анимаций и эффектов, связанных с взаимодействием с ним (например анимация открытия двери). В большинстве реализаций также существует удобный интерфейс для получения списка умных объектов в заданном расстоянии или на уровне.

Подход умных объектов позволяет легко добавлять новые сущности в геймплей, не меняя ИИ и не исправляя уже существующие объекты. N.B. умные объекты используются не только в GOAP, но и в других системах принятие решения, а также в других игровых системах: например взаимодействия игрока с объектами на карте.

План

Основной целью GOAP является создание и выполнения плана. Под планом подразумевается последовательность действий, которая приводит к выполнению цели агента. Планы статичны и не меняются с момента создания - в этом и основной минус GOAP: для того, чтобы отреагировать на изменившуюся обстановку, нам необходимо снова выполнить планирование, а это ресурсоемкая и не быстрая задача. А поскольку планы и цели у нескольких агентов могут совпадать, то неожиданно получается, что у нескольких агентов планы становятся неактуальны, что создает неравномерную нагрузку на систему ИИ и отрицательно влияет на производительность.

Построение плана

Для того, чтобы построить оптимальный план, мы строим граф, где роль узлов выполняют состояния мира, и действие, которое это состояние сгенерировало, за исключением стартового и конечного узла, у которых нет действий. После чего мы ищем кратчайший маршрут с помощью А* от целевого состояния мира к текущему. Конечно же в реальных имплементациях никто не строит весь граф, а мы сразу начинаем искать кратчайший маршрут с помощью А*, параллельно создавая наш граф. Каждый раз добавляя действия в наш граф, мы генерируем узел, в котором описано состояние мира. Это состояние - комбинация состояния цели и требований, существующих у действий, часть полей в состоянии мира узла совпадает с текущим реальным состоянием. Если мы посчитаем количество полей, которое не совпадает, мы получим удобную эвристическую функцию для А*. (напомню: эвристическая функция - это способ оценки того, насколько узел графа близок к цели)

Давайте рассмотрим пример. У нас существует агент со следующими целями

Также у нашего агента есть набор действия

Давайте наш агент выберет цель Атаковать Врага, и у него на старте есть оружие ближнего боя.

На первом шаге наш граф поиска плана выглядит следующим образом

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

Теперь мы выполнили все требования, которые появились от наших действий в состоянии мира, и при этом пришли в состояние, которое соответствует текущему. Наш план готов и он состоит из двух действий: подойти к противнику и атаковать. Давайте представим, что у нас не получилось подойти к противнику, ведь наши действия не только влияют на состояние, но и проверяют возможность быть выполненными, поэтому логично предположить, что у нас может не быть пути до противника. Тогда А* пойдет разворачивать другую ветку графа, и после двух шагов мы получим следующий граф

Теперь наш план состоит из 3 действий: найти оружие дальнего боя, подойти на расстояние выстрела, и атаковать.
Этот пример хорошо демонстрирует как из простых настроек и действий, генерируется логичное и “умное” поведение.

В следующий раз мы обсудим некоторые особенности работы с GOAP.