Skip to content

Animation State Machines and transition rules

A state machine is the AnimGraph tool that chooses which animation state is currently feeding the final pose. Transition rules are the gates between those states.

The one-minute version

  • A state is a named subgraph that outputs a pose: Idle, WalkRun, JumpStart, FallLoop, Land, Attack, and so on.
  • A transition is a one-way link from one state to another. If two states need to go both directions, you need two transitions.
  • A transition rule is a small graph that returns true or false. True means "this transition is allowed now."
  • Variables such as GroundSpeed, IsInAir, IsAttacking, and IsDead usually live in the Animation Blueprint because the AnimGraph needs stable values to read while it evaluates poses.
  • Those variables are normally updated in Event Blueprint Update Animation from the pawn/character reference you got during initialization.
  • If a transition works in preview but not while playing, the usual problem is not the state machine drawing. It is that the runtime variables, owner pawn, transition direction, slot/montage override, or active AnimBP instance is not what you think.

What a state machine actually does

An Animation Blueprint has an AnimGraph that must output a final pose. A state machine is one pose-producing node inside that graph.

AnimGraph
-> Locomotion State Machine
   -> current state outputs a pose
   -> allowed transitions may blend to another state
-> Output Pose

Inside the state machine:

Entry -> Idle
Idle -> WalkRun if GroundSpeed > 3
WalkRun -> Idle if GroundSpeed <= 3
WalkRun -> JumpStart if IsInAir
JumpStart -> FallLoop if time remaining is low
FallLoop -> Land if not IsInAir
Land -> Idle or WalkRun after landing blend

Each state contains animation logic. It might be a single sequence player, a Blend Space player, a cached pose, a layered blend, or a more complex pose subgraph.

The state machine owns which pose path is active. It does not itself compute your speed, decide your attack input, or magically know whether the character is falling. Your AnimBP variables provide that data.

States

A state is a pose-producing subgraph with a name. When the state is active, its inside graph contributes the state machine's current pose.

Common first states:

State Typical contents
Idle Idle animation sequence or idle pose.
WalkRun 1D Blend Space driven by GroundSpeed.
JumpStart One-shot jump-start animation.
FallLoop Falling loop animation.
Land One-shot land animation.
Dead Death pose/sequence.

A state is not an event. Naming a state Attack does not make it enter when the player presses attack. A transition rule, montage call, or other animation system must choose it.

State property traps:

  • Always Reset on Entry restarts animation state when entering. Useful for one-shots that should begin from frame zero; bad if you wanted to resume.
  • Entered/Left/Fully Blended State Events can be used for advanced hooks, but they are not the first debugging tool. Prove the transition first.

Transition rules

A transition rule is a graph that returns a boolean.

Idle -> WalkRun transition rule:
    Can Enter Transition = GroundSpeed > 3

WalkRun -> Idle transition rule:
    Can Enter Transition = GroundSpeed <= 3

Transition rules are evaluated as part of animation update/evaluation. They should be cheap and based on variables that were already gathered in the Animation Blueprint's Event Graph. Do not put world searches, damage logic, spawning, SaveGame writes, or expensive gameplay work inside transition rules.

Better pattern:

Event Blueprint Update Animation
-> Is Valid OwnerCharacter
-> Get Velocity
-> Vector Length XY
-> set GroundSpeed
-> Character Movement Is Falling
-> set IsInAir

Transition rule reads:
    GroundSpeed
    IsInAir

The transition rule is now a clean question, not a hidden gameplay script.

Why AnimBP variables exist

The AnimGraph and state machine need stable data while producing poses. That is why beginner locomotion almost always has variables like:

  • GroundSpeed float;
  • IsInAir boolean;
  • Acceleration or IsAccelerating;
  • Direction float for strafe Blend Spaces;
  • IsAttacking, IsDead, IsAiming, or other gameplay-state booleans.

These variables should be copies of animation-relevant state, not the source of truth for gameplay. Health usually belongs on the character or a health component. The AnimBP can copy IsDead from that source so animation can transition to a death pose.

If the AnimBP becomes the only place that knows gameplay state, other systems cannot reason about it cleanly.

Preview vs play

Animation preview can lie in two directions:

  1. Preview variables are hand-authored. You can set a preview GroundSpeed value and see the transition fire even though runtime never updates GroundSpeed.
  2. Runtime owner is missing. In the editor preview, Try Get Pawn Owner can legitimately return None, while in Play-In-Editor it should return the live pawn for a normal character mesh.

When a transition works in preview but not during play, check:

  • is the mesh using the expected Anim Class?
  • is this the live AnimBP instance, not a preview/editor instance?
  • does Try Get Pawn Owner return a valid pawn at runtime?
  • did the cast to your character succeed?
  • are GroundSpeed, IsInAir, and other variables changing during PIE?
  • is the transition drawn in the direction you need?
  • is another transition winning first?
  • is a montage/slot/layer overriding the pose you expect to see?

Use watch values and breakpoints on the AnimBP update event before rewriting the state machine.

When transitions appear to fail

Failure What it looks like What to check
Rule never becomes true State never changes. Watch the variables used by the rule.
Wrong direction A -> B works but B -> A never happens. Transitions are one-way; add the return link.
Competing transitions State changes to a different target first. Transition priorities and Max Transitions Per Frame.
Animation resets/pops One-shot restarts unexpectedly. Always Reset on Entry and transition timing.
Preview works, gameplay does not Runtime variables stay default. Owner pawn, cast, active AnimBP, update event.
Gameplay works, dedicated server differs Notify/state work expected on server. Animation is usually presentation; replicate gameplay state separately.

Failure is not an exception. The state machine just keeps outputting the state whose transition rules currently allow it.

The pattern everyone actually uses

Beginner locomotion:

Event Blueprint Initialize Animation
-> Try Get Pawn Owner
-> Cast To BP_PlayerCharacter
-> store OwnerCharacter

Event Blueprint Update Animation
-> Is Valid OwnerCharacter
-> Get Velocity
-> Vector Length XY
-> set GroundSpeed
-> OwnerCharacter CharacterMovement Is Falling
-> set IsInAir

AnimGraph
-> Locomotion State Machine
   Idle -> WalkRun when GroundSpeed > 3 and not IsInAir
   WalkRun -> Idle when GroundSpeed <= 3 and not IsInAir
   Any relevant ground state -> JumpStart when IsInAir
   FallLoop -> Land when not IsInAir

Attack logic often uses a montage instead:

Character input Attack
-> Play Montage AttackMontage on Mesh
-> AnimGraph has Slot node layered over locomotion

That keeps "one-shot attack" out of a locomotion state machine unless your game actually needs attack as a locomotion state.

Lookalikes - which one do I want?

Tool Outputs Use when
State Machine One current pose path plus blends between states Locomotion and long-running animation modes with clear transitions.
Transition Rule Boolean gate A state should switch when animation variables say it can.
Blend Space Blended pose inside a state Speed/direction should choose between related samples.
Montage One-shot/section-controlled animation through slots Attacks, reloads, emotes, interactions, ability actions.
Animation Notify Timed event from an animation Footsteps, hit windows, sounds, particles, gameplay timing hooks.
Blend by Bool/Enum Direct pose blend based on one value Small graph choices that do not need a state-machine layout.

Rule of thumb: state machines choose modes, Blend Spaces choose samples inside a mode, montages play authored actions, notifies time side effects.

Going deeper