Enemies mostly follow a short script
When an enemy spots you, shouts, runs over and then wanders back to its post after you hide, it can feel like it is thinking. In most games it is following a small set of rules that choose between a few behaviors. The most common tool for this is the finite state machine, a way of describing a character as always being in exactly one state at a time, with clear rules for moving to a different one.
The appeal is that it is easy to understand, easy to debug and cheap to run. A designer can draw it on paper, and a programmer can turn that drawing into code with little guesswork.
States and transitions
A state is one named behavior. A transition is a rule that says, “if this condition becomes true while in this state, switch to that one.”
Take a guard in a stealth game. A set of states might be:
- Patrol: walk between a few fixed points.
- Investigate: walk to a spot where a noise was heard and look around.
- Chase: move toward the player.
- Return: go back to the patrol route.
Now add transitions. From Patrol, hearing a noise leads to Investigate. From Investigate, seeing the player leads to Chase. From Chase, losing sight of the player for a few seconds leads to Return. From Return, reaching the route leads back to Patrol. The guard has four boxes and four arrows, yet it can produce a satisfying cycle of alertness and calm.
Why this works on players
People are quick to read intent into movement. When an enemy pauses, turns its head and then walks toward a sound, players assume it has noticed something. The state machine does not need to understand anything; it only needs to produce actions in a sensible order, with readable signals along the way. A short animation or sound when switching state, such as a raised weapon or a shout, tells the player what changed. Without such signals, the same logic can feel arbitrary.
Timing matters too. A delay between seeing the player and starting to chase gives the player a moment to react. That delay is a design choice, not a technical limit, and it strongly affects whether an encounter feels fair. How enemies are arranged in space is a topic for encounter design, but the behavior rules decide how each one acts once the player arrives.
What a state needs to do
Each state generally has three jobs:
- Enter: do something once when the state begins, such as play a sound or set a timer.
- Update: do the repeating work each frame, such as moving a little closer to a target.
- Exit: clean up, such as stopping a sound.
The update step runs inside the main loop, so it must be quick; some games check visibility less often for distant enemies.
Making enemies feel different
One state machine layout can drive many enemy types by changing the numbers. A nervous enemy might switch to Chase at a larger distance but give up sooner. A stubborn one might have a long timer before returning to patrol. A ranged enemy might add a state in which it keeps its distance. Because the structure stays the same, designers can build variety by adjusting values instead of writing new code each time. This is also a good place to tune difficulty, since reaction time and persistence affect how demanding a fight feels.
For movement itself, the Chase and Return states usually rely on a separate system that finds a route around obstacles, as described in character pathfinding. The state machine decides what the enemy wants; the pathfinding decides how it gets there.
A small worked example
Suppose a guard enters Chase when the player is within 8 meters and in view, and returns when the player has been out of view for 4 seconds. If the player breaks line of sight at second 10, the guard keeps chasing until second 14, then switches to Return. The numbers are hypothetical, but they show the idea: each rule is a plain comparison, and changing a single number changes the feel. A 2-second timer would make the guard easy to escape, while a 10-second timer would make it relentless.
Where state machines struggle
The approach has limits, and it helps to know them.
Growing complexity. Adding states often means adding transitions from many existing states. With ten states there can be dozens of arrows, and a change in one place can break another. Some teams group states into layers, so that a “combat” group contains its own smaller set of states.
Flicker. If the condition for entering a state and the condition for leaving it are nearly identical, an enemy can swap back and forth every frame. A common fix is to make the exit condition slightly looser than the entry one, or to require a minimum time in each state.
Predictability. Players eventually learn the rules and exploit them. For some games that is part of the fun, and for others designers add small random delays or choices to keep enemies less mechanical. If you use randomness here, the same ideas from random seeds apply, because it affects whether a bug can be reproduced.
Missing context. A basic state machine reacts to the current situation without remembering much. More flexible systems, such as behavior trees or goal-based planning, handle richer decisions but are harder to build and to debug. Many successful games still use plain state machines because the simplest tool that works is usually the best.
A practical tip
Draw the states as boxes and the transitions as arrows before writing code. If you cannot explain each arrow in one sentence, the design is probably too tangled. Showing the current state as text above the enemy’s head makes odd behavior much easier to diagnose.