← All patterns
Behavioral

State

Give each mode of an object its own class so behaviour changes cleanly when the mode changes.

What Is It?

The State pattern moves mode-specific behaviour out of one giant switch and into separate classes. A character controller does not ask “am I jumping?” in twenty places; it simply forwards Tick() to whatever current state object it holds.

Each state implements a small interface — typically Enter(), Tick() and Exit() — and decides for itself which inputs it responds to and which state comes next. JumpState knows that landing is impossible mid-ascent; IdleState knows that pressing jump is fine.

A state machine owns the current state and performs transitions: it calls Exit() on the old state, swaps the reference, and calls Enter() on the new one. That is where animations get triggered, sounds play, and timers reset — once, at the right moment.

When Is It Used?

Use it for anything with distinct modes that respond differently to the same input: player movement (idle, run, jump, fall), enemy AI (patrol, chase, attack), doors, menus and game flow.

It pays off once you notice boolean flags multiplying (isJumping, isFalling, isAttacking) and conditions that check combinations of them. Each combination is really a state.

For two or three trivial modes, an enum with a switch is perfectly fine. Reach for state classes when behaviour per mode becomes large or transitions need setup and teardown.

Interactive Demo

Click the controls and watch the objects collaborate. The console mirrors what the C# code below would log.

Code

Assets / Scripts / Behavioral/ State ›PlayerController.cs
using UnityEngine;

namespace Patterns.Behavioral.State
{
    /// <summary>
    /// Context: owns the state machine and the shared data states need.
    /// Its Update is just "read input, tick the current state".
    /// </summary>
    [RequireComponent(typeof(Rigidbody2D))]
    public class PlayerController : MonoBehaviour
    {
        [SerializeField] private float runSpeed = 6f;
        [SerializeField] private float jumpSpeed = 12f;
        [SerializeField] private LayerMask groundMask;
        [SerializeField] private Transform feet;

        public Rigidbody2D Body { get; private set; }
        public Animator Animator { get; private set; }
        public StateMachine Machine { get; } = new();

        public IState Idle { get; private set; }
        public IState Run { get; private set; }
        public IState Jump { get; private set; }
        public IState Fall { get; private set; }

        public float MoveInput { get; private set; }
        public bool JumpPressed { get; private set; }
        public float JumpSpeed => jumpSpeed;
        public bool IsGrounded => Physics2D.OverlapCircle(feet.position, 0.1f, groundMask);

        private void Awake()
        {
            Body = GetComponent<Rigidbody2D>();
            Animator = GetComponentInChildren<Animator>();

            // Create each state once and reuse it.
            Idle = new IdleState(this);
            Run = new RunState(this);
            Jump = new JumpState(this);
            Fall = new FallState(this);
        }

        private void Start() => Machine.ChangeState(Idle);

        private void Update()
        {
            MoveInput = Input.GetAxisRaw("Horizontal");
            JumpPressed = Input.GetButtonDown("Jump") && IsGrounded;
            Machine.Tick();
        }

        public void Move(float direction) => Body.linearVelocityX = direction * runSpeed;
    }
}
4 files · namespace Patterns.Behavioral.StateC# · UTF-8 · LF

Advantages & Disadvantages

+ Advantages

  • Each mode lives in one class with its own logic, so it is easy to read, change and test.
  • Invalid transitions are impossible by construction — a state simply ignores input it does not handle.
  • Enter / Exit hooks give a single, reliable place for animation triggers and cleanup.

− Disadvantages

  • More classes and more indirection than a simple switch.
  • States often need access to the owner’s components, which can lead to wide context objects.
  • Flat state machines struggle with shared behaviour; you may need hierarchical states to avoid duplication.

Tips

  1. 01Pass a context (the controller) into each state’s constructor so it can read input and move the character without GetComponent calls.
  2. 02Create state instances once and reuse them; allocating a new state on every transition generates garbage.
  3. 03Keep transition logic inside states, and keep the machine dumb — it just swaps and calls Exit/Enter.
  4. 04Unity’s Animator is itself a state machine. Let your code FSM drive gameplay and set Animator parameters from Enter(), rather than reading gameplay state back out of the Animator.
  5. 05Log transitions during development (Idle → Run); it makes bugs in state flow obvious.