My First Experience with Unreal Engine State Trees

Leaving Behavior Trees for State Trees

I’m still in the early stages of developing the AI for my game.

Like many Unreal Engine developers, I started with a simple Behavior Tree containing just a few basic actions:

• Wander
• Chase
• Attack

At that point, it was more than enough to get my first zombie moving around and interacting with the player.

As the project evolved, however, I started questioning whether Behavior Trees were the best fit for the kind of game I’m building.

Since my game is a multiplayer open-world survival game, performance has always been one of my biggest concerns. While researching different AI architectures, I came across State Trees.

After spending some time learning how they work, I found them much easier to reason about.

What immediately caught my attention was their event-driven approach to state transitions. Instead of constantly evaluating a behavior hierarchy, the AI spends most of its time executing its current state and only transitions when something meaningful happens.

My Current State Tree

Here’s what my State Tree looks like today.

I’m still learning, so I fully expect this structure to evolve as the project grows. This isn’t meant to be a “perfect” architecture — it’s simply where I am in my journey right now.

One thing I immediately enjoyed was how natural it felt to react to gameplay events.

Instead of building large trees full of decorators and services, I can simply notify the State Tree when something important happens.

For example, when my AI Perception component detects a player, I send an event to the State Tree.

void AZombieAIController::EvaluateBestTarget()
{
    if (bIsTreeBlocked)
    {
        return;
    }
    TArray<AActor*> SeenActors;
    AIZombiePerception->GetCurrentlyPerceivedActors(
        UAISense_Sight::StaticClass(),
        SeenActors
    );

    ...

    if (BestTarget)
    {
        SendEventToStateTree(TEXT("AI.PlayerDetected"));
    }

    ...

}

void AZombieAIController::SendEventToStateTree(FName GameplayTagName)
{
    if (StateTreeComponent)
    {
        StateTreeComponent->SendStateTreeEvent(
            FGameplayTag::RequestGameplayTag(GameplayTagName)
        );
    }
}

In this example, I’m using Unreal’s AI Perception System to determine the best target — currently the closest visible player.

Once a valid target is found, I simply send the AI.PlayerDetected gameplay tag to the State Tree using SendStateTreeEvent().

From there, the State Tree evaluates any transition listening for that event and changes state accordingly.

Gameplay Tags

Another thing that quickly became apparent is how important Gameplay Tags are when working with State Trees.

Every event that triggers a transition is represented by a Gameplay Tag, which first needs to be registered inside the editor.

Once the tag exists, configuring transitions becomes very straightforward.

Each state can simply listen for the events that matter to it.

First Impressions

Coming from Behavior Trees, this event-driven workflow feels much easier for me to understand.

Rather than constantly thinking about decorators, services and execution flow, I can focus on what actually happened in the game.

A player was detected.

The target was lost.

The zombie became stunned.

Those gameplay events naturally drive the AI to its next state, making the overall behavior much easier to read and maintain.

I’m still at the beginning of this journey, so I’m sure my State Tree will change significantly over time.

But after my first few days experimenting with it, I already feel much more comfortable building my AI this way.

Thanks for reading!

I’m still learning my way through State Trees, so this article reflects my current understanding rather than a definitive guide.

If you have suggestions, different approaches, or tips from your own experience, I’d love to hear them. One of the best parts of game development is learning from other developers.

Thanks for reading!