🎬 Lesson 1.2: States & Transitions

A State Is a Pose in Motion

A state is simply "the animation the character is doing right now." A character standing still is in its Idle state; start moving and it switches to a Run state; press the jump button and it enters a Jump state. Each state plays one motion (a clip or a blend of clips), and the Animator's job is to move between them at the right moments.

Here's the exact same character — Timmy, our rigged robot — sitting in three different states. These are real renders from Unity, each captured while its state was active:

Same GameObject, same Animator — three different states. The interesting question is: what makes Unity switch from one to the next? That's what the rest of this lesson answers.

Reading the Animator Window

Open Window ▸ Animation ▸ Animator (or double-click an Animator Controller). You'll see a dark grid canvas holding boxes and arrows, with a Parameters panel on the left. Here is the state machine we're about to build, drawn exactly as the Animator window lays it out:

💡 Why a diagram and not a screenshot? Unity's node-editor windows (the Animator, Shader Graph, Timeline) are drawn with a technology that can't be captured cleanly as an image. Throughout this course those windows are rebuilt as precise diagrams from the real setups — every node, colour, and label matches what you'll see on screen. All in-game renders (like the three states above) are genuine Unity captures.

Creating States

Every clip you drop into the Animator becomes a state. There are three easy ways to add one:

1. Drag a clip from the Project window straight onto the Animator canvas — it becomes a state with that clip as its motion.
2. Right-click the canvas ▸ Create State ▸ Empty, then assign a clip in the Inspector's Motion field.
3. Right-click ▸ Create State ▸ From New Blend Tree (we'll use this in Lesson 1.3).

The first state you add is automatically the default state — shown in orange and wired from the green Entry node. It's whatever the character does the instant the game starts, so it's almost always Idle. To change which state is the default, right-click any state ▸ Set as Layer Default State.

Parameters: The Switches

A state machine needs inputs to decide when to switch. Those inputs are parameters — named values you add in the Parameters panel and change from your game code. There are four kinds:

• Float — a decimal number, e.g. Speed. Great for "how fast am I moving?"
• Int — a whole number, e.g. a WeaponType index.
• Bool — true/false, e.g. Grounded. Stays set until you change it.
• Trigger — a special bool that flips itself back to false the moment it's consumed by a transition. Perfect for one-shot events like Jump or Attack.

In Figure 1, the panel holds a Speed float, a Jump trigger, and a Grounded bool. Your code sets these; the transitions read them.

Transitions & Conditions

A transition is the arrow from one state to another. To create one, right-click a state ▸ Make Transition, then click the target state. Select the arrow and the Inspector shows its Conditions — the parameter tests that must all be true for the transition to fire.

In our machine:

• Idle → Run fires when Speed > 0.1 (the player started moving).
• Run → Idle fires when Speed < 0.1 (the player stopped).
• Any State → Jump fires when the Jump trigger is set — from any state, so you can jump whether idling or running.

The teal Any State node is a shortcut: an arrow from it means "this transition can happen no matter which state we're currently in." It saves you drawing a Jump arrow out of every single state.

Conceptually, every frame the Animator asks a simple question:

Figure 2: The Animator re-evaluates transitions every frame based on the current parameter values.

Has Exit Time

Not every transition waits on a condition. Select a transition and you'll see a Has Exit Time checkbox. When it's ticked, the transition fires automatically once the current clip reaches a certain point — no parameter needed.

• Condition-driven (Has Exit Time off): switch the instant the condition is met. Use for responsive controls — Idle→Run should happen immediately when the player moves.
• Exit-time-driven (Has Exit Time on): let the clip finish, then switch. Use for one-shot animations — our Jump → Idle transition waits for the jump/land animation to play out before returning to Idle.

Driving It from Code

The Animator won't change parameters by itself — your gameplay script does, by grabbing the Animator component and calling SetFloat, SetBool, or SetTrigger. Here's a minimal driver that feeds our three parameters:

using UnityEngine;

public class CharacterAnimDriver : MonoBehaviour
{
    Animator animator;

    void Awake()
    {
        animator = GetComponent<Animator>();
    }

    void Update()
    {
        // however you read movement — this is just an example magnitude
        float speed = new Vector2(moveX, moveZ).magnitude;

        animator.SetFloat("Speed", speed);      // drives Idle <-> Run
        animator.SetBool("Grounded", isGrounded);

        if (jumpPressed)
            animator.SetTrigger("Jump");         // fires Any State -> Jump once
    }
}

Notice the parameter names in quotes must match the Parameters panel exactly — they're the contract between your code and the state machine. Set a float continuously, set a bool when its condition changes, and trigger a one-shot action.

A Peek at the Real Thing

Timmy's actual controller in our project is a little more advanced than Figure 1: instead of separate Idle and Run states, it uses a single blend tree that smoothly mixes Idle, Walk, and Run based on the exact Speed value — which is why the run render above shows a natural lean rather than an on/off switch. That's the subject of the next lesson.

🔎 Look for yourself: open Assets ▸ …ThirdPersonController ▸ Character ▸ Animations ▸ StarterAssetsThirdPerson.controller in the Animator window. You'll spot the same Speed, Jump, Grounded, and FreeFall parameters driving states named Idle Walk Run Blend, JumpStart, InAir, and JumpLand.

Hands-on Challenge

Summary

🚀 What's Next?

Our Idle and Run were separate states with a hard switch between them. Real locomotion feels smoother because it blends — walking eases into jogging eases into a sprint as speed rises. In Lesson 1.3: Blend Trees we replace the Idle/Run pair with a single blend tree driven by that same Speed float.