Syncing Animations

Export

Animation work in a State Designer graph falls into two separate problems, and they have different answers. Continuous locomotion — matching a walk or run animation to how fast a character is actually moving — belongs to the character controller, not the graph. Discrete animation control — playing an attack, opening a door, advancing a boss phase — is exactly what the Animator Actions and Conditions exist for.

Mixing the two is what makes a graph brittle.

Let the controller own locomotion

A graph that sets a Speed parameter around every movement State couples itself to the Animator Controller. Add animations and the graph fills with parameter States; change a transition in the Animator Controller and the graph has to be reworked to match.

The alternative is to not synchronize locomotion in the graph at all. When the graph sets a destination, the character controller’s velocity changes; a bridge script converts that velocity into the parameters the Animator Controller expects. The graph then knows nothing about animation, and the same setup works with root motion.

An Animator blend tree changes between Idle and Run using a Speed parameter.

This is the arrangement the Animation Sync sample demonstrates: the state machine drives a NavMeshAgent, and the agent’s velocity is converted into the float value that drives the blend tree above. Unity documents the same pattern for the NavMeshAgent in Coupling Animation and Navigation.

The Ultimate Character Controller takes the same approach: a bridge component feeds movement input to the controller, and the controller owns the Animator entirely.

Use Animation-Driven Locomotion for the graph shape, and note its caveat — a production controller needs a script or Actions matched to its own parameter names and blend-tree structure, not the sample’s.

Drive discrete animation from the graph

Locomotion is the exception, not the rule. When an animation is the gameplay beat — a wind-up, a door cycle, a staggered phase change — driving it from the graph is the right call, and State Designer ships a substantial Animator toolkit for it.

Action Use it for
Set Parameter / Set Parameters Setting one or several Animator parameters by name. Parameter hashes are cached.
Play / Set State Playing a named Animator state directly.
Crossfade Blending to a state with an explicit duration, layer, and normalized start time. Can wait for completion.
Wait For Animation Holding a State until an animation finishes, with an optional timeout.
Animate Parameter Over Time Driving a parameter toward a value across a duration rather than setting it instantly.
Set Animation Speed Changing playback speed for slow-motion or staggered beats.
Play Animator State Sequence Running an ordered set of states as one Action.
Sync Animator Layers Keeping layers aligned when an upper-body layer must match the base layer.

Conditions let transitions react to the Animator rather than to a timer, which is what keeps a graph in step with animation it does not own:

Condition Use it for
Is Animation Playing Gating a transition while a state is still active.
Animator Normalized Time Crossed Firing at a specific point inside a clip, such as an impact frame.
Animator Transition Complete For Duration Waiting until a blend has genuinely settled.
Animator State Sequence Observed Reacting once a known sequence of states has played.

Prefer Wait For Animation or a normalized-time Condition over a Timer whose duration happens to match the clip. A timer silently desynchronizes the first time the clip length, playback speed, or transition duration changes.

Keep the Animation and Animator categories straight

Two separate categories ship, and they target different components:

  • Animator Actions and Conditions target an Animator and its Animator Controller. This is what nearly every project should use.
  • Animation Actions target Unity’s legacy Animation component. Crossfade and Play exist in both categories with the same names, so confirm the category when adding either one.

Do not mirror the Animator in the graph

The failure mode to avoid is rebuilding the Animator Controller’s state machine as a State Designer graph, with one State per animation state and transitions duplicating the Animator’s own. Two systems then own the same decision and disagree during blends.

Let the graph own gameplay intent — attacking, opening, patrolling — and let the Animator Controller own how clips blend into one another. Where the graph needs to know what the Animator is doing, read it with a Condition rather than assuming it.