You've gotten to where you can build enemy AI in Behavior Tree. But then you open a new official sample and it uses an unfamiliar second AI tool, "StateTree", and it throws you. You stall on "Behavior Tree or StateTree, which should I actually learn?".
In the UE5 generation, Epic pushes StateTree front and center as an AI-building tool, and adoption in official templates is increasing. This article sorts out how it differs from Behavior Tree at the level of thinking, and rebuilds the exact same patrol-chase-return guard from the Behavior Tree article in StateTree so we can line the two up and compare.
StateTree has moved past experimental into a standard, usable position. Whether you need to enable a plugin varies by version, so check against the UE you're using.
What You'll Learn
- The difference in thinking from Behavior Tree (selecting by priority vs. transitioning from a state)
- StateTree's cast: State / Task / Condition / Transition
- The steps to run it with a StateTree AI Component
- A decision table for which to choose
- Building the same AI and lining up the structures
- Hands-on: rebuilding the patrol-chase-return guard in StateTree
The Difference in Thinking from Behavior Tree
They're both tools for building the same enemy AI, but their starting points are opposite . This is the most important part.

- Behavior Tree: every frame it re-walks the tree from the root and selects "which behavior is highest priority right now". At its center is "selection"
- StateTree: it holds "which state am I in now", and when a condition is met it transitions from the current state to the next . At its center is "state and transition"
Where Behavior Tree "re-selects from the top by priority each time", StateTree "moves to the next, based on the state it's in now". This is easiest to grasp as the proper evolution of the way a state machine with enum and switch thinks. Take that state machine and make it something you build in a dedicated visual editor, hierarchy and transitions included, that's StateTree.
StateTree's Cast
To read a StateTree, get four words down. If you know Behavior Tree, you can understand them by mapping across.

- State: the state the AI is in now, like "Patrolling" or "Chasing". States can be nested into a hierarchy
- Task: the processing run while in that state. "Move to a patrol location", and so on. Close to Behavior Tree's Task
- Condition: the condition for whether it may enter that state (Enter Condition). Close to Behavior Tree's Decorator
- Transition: the arrow moving from one state to another. "When you spot the player, patrol → chase". This is StateTree's star
Where Behavior Tree was a "select a branch of the tree" structure, StateTree is a "connect boxes of state with arrows of transition" structure . If the spec says "when you spot someone while patrolling, go to chase", that arrow appears in the editor as-is.
Running Your First StateTree
The flow of running AI with StateTree is similar to Behavior Tree.

- Create a StateTree asset: create it new in the Content Browser and set the Schema to StateTree AI (specifying it's an AI StateTree)
- Place States: make States like "Patrol" and "Chase", and assign a Task (like Move To) to each
- Connect Transitions: set the condition and destination for moving to the next state on each State
- Run it on the Pawn: put a StateTree AI Component on the Pawn (or AI Controller) the AI drives, and assign the StateTree asset you made
Now the StateTree runs when you place the Pawn. Data you want to use across states, like the target and patrol location, you define in StateTree's Parameters . These are the "AI shared notes" that correspond to Behavior Tree's Blackboard. That you need NavMesh as the foundation for movement is the same as with Behavior Tree.
Which to Choose
"Behavior Tree or StateTree, which should I write in?" This is easiest to decide by the AI's personality .

| For AI like this | Recommendation | Reason |
|---|---|---|
| Clearly-defined states (patrol/chase/return, a gimmick's open/close) | StateTree | States and transitions become the diagram directly. Reads like the spec |
| Complex priority-based interruption (weighing many behaviors each time) | Behavior Tree | The re-select-from-root-by-priority structure suits it |
| Prioritizing existing assets / information volume | Behavior Tree | Lots of info and existing projects, abundant learning material |
| Wanting to match official samples | StateTree | Adoption is increasing in UE5-generation samples |
When you're torn, start with StateTree if the states are clearly defined. UE5-era official samples increasingly use it, and the available material should keep growing. That said, if you're stuck right now, Behavior Tree's larger body of information can get you moving faster.
Rather than one being the right answer, it's about what suits the AI . StateTree for AI and gimmicks with crisp states, Behavior Tree for AI where priority maneuvering is the lifeblood. And as noted above, you can call StateTree from Behavior Tree, so there's a road to combining both .
Hands-On: Rebuilding the Guard in StateTree
A stealth guard, a horror wanderer, an action patrol soldier. "Normally patrols, chases when it spots you, returns to its post when it loses you" is the basic form of AI. Here we build the exact same spec as the Behavior Tree article in StateTree and line the two structures up to compare.
We're building a guard that circles patrol points, switches to chasing when it spots the player, and returns to patrol 5 seconds after losing sight . The behavior is identical to the Behavior Tree version, and the difference shows in how it looks in the editor .
First, let's line up how the structure looks when you build the same AI in Behavior Tree and StateTree.

In Behavior Tree, "chase" and "patrol" branches sit under the root Selector, and a Decorator's condition selects a branch. In StateTree, "Patrol" and "Chase" States sit as boxes, and transition arrows connect them. The spec "on spotting, Patrol → Chase" and "5 seconds after losing sight, Chase → Patrol" reads directly as arrows.
StateTree Structure
| Element | Contents |
|---|---|
| State "Patrol" | Task: pick a patrol location → Move To. Transition: to "Chase" on spotting the player |
| State "Chase" | Task: Move To the target. Transition: to "Patrol" 5 seconds after losing sight |
| Source of spotting | Sight from AI Perception. Write the target to Parameters |
| Parameters | TargetActor (Object), PatrolLocation (Vector). Blackboard equivalent |
How Transitions Are Thought Of
StateTree (AI Schema)
├ State: Patrol
│ Task: FindPatrolLocation → Move To(PatrolLocation)
│ Transition: TargetActor is valid → to Chase
└ State: Chase
Task: Move To(TargetActor)
Transition: lost TargetActor for 5 sec → to Patrol
The key is that the transition conditions gather in one place as "arrows leaving that state" . In Behavior Tree you expressed interruption with the Decorator's Observer aborts setting, but in StateTree "the condition to leave Patrol" and "the condition to leave Chase" are written together on each State.
Verifying It
When you Play, the behavior is exactly the same as the Behavior Tree version . The enemy walks patrol points, switches to chasing when the player enters its sight, and returns to patrol 5 seconds after losing sight.
Here's how to narrow it down when it doesn't work.
- Won't move to Chase → check Patrol's Transition condition (is
TargetActorvalid). Is AI Perception writing to Parameters - Stays in Chase forever and won't return → check Chase's Transition "5 second" timer, or the process that clears
TargetActor - Doesn't move at all → is a StateTree AI Component on the Pawn with the asset assigned. Is there NavMesh
Two things to take away.
- For the same AI, the line count is about the same: for a patrol AI like this, Behavior Tree and StateTree take about the same effort. What differs is "how it looks", and StateTree makes transitions a diagram straight from the spec
- The difference shows when you add interruption: add "flinch for 1 second when hit, no matter which state you're in", and StateTree expresses it with a shared Transition while Behavior Tree uses a high-priority branch. Strengths and weaknesses show here. Build both from the same subject first, and compare-read against Behavior Tree
Bonus: Good to Know for Later
You can call StateTree from Behavior Tree. UE5.4 and later have a node that runs a StateTree from a Behavior Tree task (BTTask_RunStateTree). You can do "run the big picture on Behavior Tree's priority, and leave the fine state transitions to StateTree". You don't have to commit fully to one or the other.
A seamless evolution from the state machine. If you're used to "deciding the state to one" in a state machine with enum and switch, StateTree fits right in as its extended form. Think of it as replacing the match (branching per state) you wrote in code with boxes and arrows in a visual editor.
Try it small first. Rather than building complex AI in StateTree right away, grasping the feel of State, Task, and Transition with a simple 2-3 state gimmick (a door's "closed → open → closed") is the recommendation. Once you get the mechanism, applying it to enemy AI is quick.
Summary
StateTree and Behavior Tree are siblings with opposite thinking.
| Aspect | Behavior Tree | StateTree |
|---|---|---|
| Thinking | Re-select by priority from the root | Transition from the current state |
| Star | Branches of the tree (Selector/Sequence) | Boxes of state and arrows of transition |
| Good at | Complex priority-based interruption | Clear states and gimmicks |
| Shared data | Blackboard | Parameters |
And the thing you must not forget is that both are current and coexist . Not a replacement; choose by the AI's personality, and combine when needed.
With this, you won't be thrown when you see StateTree in a new sample. Does your game's enemy AI have crisp states, or is priority maneuvering its lifeblood? That answer tells you which to write in.
Further Learning
- Building Enemy AI with Behavior Tree — building the same AI in BT (compare-reading recommended)
- A State Machine with enum and switch — the foundation of StateTree's thinking
- Making Enemies Spot You with AI Perception — the source of spotting events
- NavMesh Setup and Optimization — the foundation of AI movement