🤖 Lesson 6.3: An Enemy State Machine

What Is a Code FSM?

A finite state machine is a system that is always in exactly one of a fixed set of states, and moves between them by well-defined transitions. You already met one: the Animator, where states were clips and transitions were parameter conditions. That machine decides which animation plays.

The FSM you build now lives in a plain C# script and decides which behaviour runs — where the agent goes, whether it attacks, what it's thinking. The two machines cooperate: your code FSM decides "I'm chasing," then tells the Animator "play the run animation." Same concept, two layers.

Every FSM does three things each frame, and it's worth naming them because the code splits along these lines:

• Sense — gather facts about the world (how far is the player? can I see them?).
• Decide — given the current state and those facts, should I transition?
• Act — run the current state's behaviour (patrol, chase, attack).

The Enemy State Diagram

Before any code, draw the machine. This is the single most useful artifact in AI work — it shows every state, every transition, and the exact condition on each. Here's the enemy we're building, drawn in the dark node-editor style so it reads like the Animator from Module 1:

💡 Draw it before you code it. Every arrow in this diagram becomes one if in your transition logic, and every box becomes one method. If you can't draw the machine, you don't yet understand the behaviour — and no amount of code will rescue that.

States as an Enum

For a three-state enemy, the simplest solid approach is an enum plus a switch. (Larger AIs graduate to a class-per-state pattern, but an enum is perfectly professional here and far easier to read.) Start with the scaffold:

using UnityEngine;
using UnityEngine.AI;

[RequireComponent(typeof(NavMeshAgent))]
public class EnemyAI : MonoBehaviour
{
    enum State { Patrol, Chase, Attack }
    State state = State.Patrol;          // default state (the orange box)

    [Header("References")]
    [SerializeField] Transform player;
    [SerializeField] Transform[] waypoints;

    [Header("Ranges")]
    [SerializeField] float sightRange  = 12f;
    [SerializeField] float attackRange = 2f;
    [SerializeField] float giveUpTime  = 4f;   // seconds out of sight before returning to patrol

    NavMeshAgent agent;
    Animator animator;
    int wpIndex = 0;
    float lostTimer = 0f;

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

    void Update()
    {
        Decide();   // maybe change state
        Act();      // run the current state
    }
}

The Update loop is deliberately two lines: first Decide whether to switch states, then Act on whatever state we're in. Keeping those separate is what keeps the machine readable as it grows.

Deciding: The Transitions

The Decide method is Figure 1 turned into code — one branch per state, checking that state's outgoing arrows. Notice the small but vital detail: we use different ranges for entering versus leaving chase, and a timer before giving up. That's hysteresis, and it stops the enemy flickering between states when the player hovers right at a boundary.

void Decide()
{
    float dist = Vector3.Distance(transform.position, player.position);
    bool canSee = CanSeePlayer();   // built in the next lesson; distance-only for now

    switch (state)
    {
        case State.Patrol:
            if (canSee && dist < sightRange)
                TransitionTo(State.Chase);
            break;

        case State.Chase:
            if (dist < attackRange)
            {
                TransitionTo(State.Attack);
            }
            else if (!canSee)
            {
                // count how long we've lost sight; only give up after giveUpTime
                lostTimer += Time.deltaTime;
                if (lostTimer >= giveUpTime)
                    TransitionTo(State.Patrol);
            }
            else
            {
                lostTimer = 0f;   // still see them — reset the give-up clock
            }
            break;

        case State.Attack:
            if (dist > attackRange)
                TransitionTo(State.Chase);
            break;
    }
}

void TransitionTo(State next)
{
    // one place to run "on enter" logic per state
    state = next;
    lostTimer = 0f;

    switch (next)
    {
        case State.Patrol:
            agent.isStopped = false;
            agent.SetDestination(waypoints[wpIndex].position);
            break;
        case State.Chase:
            agent.isStopped = false;
            break;
        case State.Attack:
            agent.isStopped = true;   // stop moving to swing
            break;
    }
}

Routing every state change through one TransitionTo method is the trick that keeps FSMs sane. It's the single place for "when I enter this state, do X" — start the patrol path, stop the agent to attack, reset a timer. Scatter that logic across Decide and you'll forget a reset and spend an evening debugging a stuck enemy.

Acting: Driving the Agent

Act runs the behaviour of whatever state we're in right now. This is where the NavMeshAgent from the last two lessons finally earns its keep — each state points it at a different destination:

void Act()
{
    switch (state)
    {
        case State.Patrol:
            // reuse the waypoint loop from Lesson 6.2
            if (!agent.pathPending && agent.remainingDistance <= agent.stoppingDistance)
            {
                wpIndex = (wpIndex + 1) % waypoints.Length;
                agent.SetDestination(waypoints[wpIndex].position);
            }
            break;

        case State.Chase:
            // keep steering toward the player (throttled, not every frame)
            agent.SetDestination(player.position);
            break;

        case State.Attack:
            // stopped; just face the player and let the attack animation play
            FacePlayer();
            // (fire the actual attack on an Animation Event or a cooldown timer)
            break;
    }
}

void FacePlayer()
{
    Vector3 dir = player.position - transform.position;
    dir.y = 0f;
    if (dir.sqrMagnitude > 0.001f)
    {
        Quaternion look = Quaternion.LookRotation(dir);
        transform.rotation = Quaternion.Slerp(transform.rotation, look, 8f * Time.deltaTime);
    }
}

Three states, three completely different uses of the same agent: Patrol cycles waypoints, Chase continuously re-targets the player, Attack freezes the agent (isStopped) and just rotates to face. The FSM decides which of these runs; the agent handles the actual locomotion.

💡 Where does the attack happen? Notice Attack doesn't deal damage here. In a real game you'd trigger an attack animation and land the hit on an Animation Event (Module 1) at the exact frame the weapon connects, or gate it behind a cooldown. We'll wire real damage in Module 7 (Health & Damage with Interfaces).

Feeding the Animator

Right now the enemy behaves correctly but looks frozen — it slides around in a T-pose. The fix ties this lesson back to Module 1: the FSM sets Animator parameters so the visuals track the behaviour. The cleanest hook is right inside TransitionTo and by feeding the agent's own speed to a Float:

void Act()
{
    // ... the switch above ...

    // Drive the locomotion blend tree with the agent's real speed
    // (0 when attacking/idle, up to full speed when chasing).
    if (animator != null)
        animator.SetFloat("Speed", agent.velocity.magnitude);
}

void TransitionTo(State next)
{
    state = next;
    lostTimer = 0f;

    switch (next)
    {
        case State.Patrol: agent.isStopped = false;
                           agent.SetDestination(waypoints[wpIndex].position); break;
        case State.Chase:  agent.isStopped = false; break;
        case State.Attack: agent.isStopped = true;
                           if (animator != null) animator.SetTrigger("Attack");   // one-shot swing
                           break;
    }
}

This is exactly the SetFloat("Speed", …) / SetTrigger("Attack") pattern from Lesson 1.2 — the FSM is just the thing setting those parameters now. Feeding agent.velocity.magnitude into the Speed float means your Module 1 blend tree automatically eases from idle to walk to run as the chase speeds up. The two state machines finally click together: your code FSM picks the behaviour, the Animator FSM picks the pose.

Hands-on Challenge

Summary

🚀 What's Next?

The enemy's one cheat right now is that stubbed CanSeePlayer() — it "sees" through walls and in every direction. In Lesson 6.4: Sensing the Player (Mini-Project) you'll build a real vision cone with distance, Vector3.Angle, and a line-of-sight Raycast, then drop it into this FSM to create a proper patrolling guard.