A player crouches behind a crate. The guard turns, pauses, and walks away. Did the guard see them? Did the crate break line of sight, or did the guard's patrol simply time out? If your playtesters cannot answer that question, your stealth is not hard — it is opaque. The fix is almost never smarter AI. It is a perception model with numbers you can state out loud, a small set of named states, and a signal for every transition between them.
This is a workflow for designing enemy AI that reads as fair, written for teams that do not have an AI programmer sitting next to the designer.
Start with senses, not behaviour
Most enemy AI bugs that players report as "unfair" are perception bugs. Before you write a single behaviour tree node, write down what your enemy can sense and with what limits.
A workable default for a third-person or top-down game:
| Sense | Parameter | Example value |
|---|---|---|
| Sight | Cone angle | 90° horizontal |
| Sight | Max range | 18 m |
| Sight | Close-range bubble (ignores cone) | 3 m |
| Sight | Line-of-sight checks | 3 rays: head, chest, feet |
| Hearing | Walk radius | 6 m |
| Hearing | Run radius | 14 m |
| Hearing | Gunshot radius | 40 m |
| Memory | Last-known-position held for | 12 s |
The close-range bubble matters more than it looks. Without it, a player can stand behind a guard's shoulder, inside the cone's blind wedge, and feel like they are exploiting a bug — which they are. With it, "don't touch them" becomes a readable rule.
Note also that sight should not be binary. Use an accumulating awareness value instead of an instant trigger. A simple model: each frame the enemy has line of sight, add points scaled by distance, player movement speed, and light level. A typical tuning is 0 to 100 awareness, filling in about 1.5 seconds at close range in bright light, 4 seconds at maximum range in shadow, and draining at roughly half the fill rate when sight is broken. That asymmetry — fast fill, slow drain — is what makes breaking line of sight feel like a real decision rather than a reset button.
Four states, not fifteen
Every extra state is a thing the player must learn to recognise. Four is usually enough, and each one needs a distinct read at a distance.
Unaware
Patrolling or idling on a fixed route. The player's job here is prediction, so the route must be legible: visible waypoints, a pause at each one, a consistent loop. Randomised idle wandering feels alive and ruins planning. If you want variation, randomise the pause duration (say 2–5 s), not the path.
Suspicious
Awareness crossed a low threshold (around 30 of 100) or a sound landed in range. The enemy stops, turns toward the stimulus, and holds for 2–3 seconds. Critically, this state should be survivable: the player who freezes or backs off should get away with it. If suspicion always escalates, it is not a state, it is an animation.
Alert
Awareness hit 100, or a body or open door was found. The enemy moves to the last known position, calls out, and other enemies within the alert radius are pulled up to Suspicious — not straight to Alert. Chaining full alerts across a level turns one mistake into a room wipe and teaches players to reload rather than adapt.
Searching
The enemy lost the player but has a last known position. Give searching a hard budget — 15 to 25 seconds — and a visible pattern: check the last known position, then two or three nearby cover spots, then walk back to the patrol route. An unbounded search is the single most common reason players quit a stealth section. The de-escalation path matters as much as the escalation path, and it should be the same route backwards: Searching drops to Suspicious, Suspicious drops to Unaware, never a silent snap back to normal.
Make every transition visible
The rule: no state change without a signal the player can perceive from gameplay distance. Three channels, and you want at least two firing on every transition.
- Animation and pose. Weapon lowered when Unaware, raised in Alert, head-turning sweep in Searching. Silhouette change beats colour change on a small screen.
- Audio. A bark on entry to Suspicious ("Hm?") and Alert ("Over there!"), and critically a de-escalation bark ("Must've been nothing") so the player knows the threat has passed. Write barks as part of the state table, not as a late audio pass.
- UI. An awareness meter above the enemy, or a directional indicator, filling as awareness accumulates. Even if you plan to hide this on higher difficulties, build it first — it is the fastest debugging tool you will have.
A short checklist to run against each enemy before it ships:
- Every state has a unique pose readable at 20 m
- Every transition has at least two signals
- De-escalation is signalled, not silent
- Suspicious can be escaped by standing still
- Searching has a time cap
- Awareness fill rate is tuned per light level and distance
- Sound radii are debug-visualised in engine
- Group alerting raises nearby enemies one step, not two
Write the state table before the behaviour tree
The artefact that saves the most time is boring: a table of states, entry conditions, exit conditions, duration and signals. One row per state, filled in before anyone opens a behaviour tree editor.
| State | Enters when | Exits when | Duration | Signals |
|---|---|---|---|---|
| Unaware | Default; search budget expires | Awareness ≥ 30, or sound in radius | — | Weapon low, hum/whistle |
| Suspicious | Awareness ≥ 30 or sound | Awareness = 100 → Alert; awareness < 10 for 3 s → Unaware | 2–3 s hold | Turn to stimulus, "Hm?", meter visible |
| Alert | Awareness = 100, or body found | Loses sight for 4 s → Searching | Until contact lost | Weapon raised, shout, meter full |
| Searching | Lost contact from Alert | Budget ends → Unaware; regains sight → Alert | 15–25 s | Head sweep, flashlight, "Where'd they go?" |
This table is a design document, not a programmer's note. In GameDesignerX, it sits naturally in the mechanics module with the perception numbers alongside it, so when a playtester reports "the guard saw me through a wall," you can check which value was wrong instead of reopening the engine. Log the tuning changes you make from each test in the decision log — perception values get re-argued more often than almost anything else, and "we tried 24 m range in build 0.7.2 and it made rooftops useless" is worth keeping.
Tune with two tests, not opinions
The detection-distance test. Walk a tester straight at an enemy from 30 m in a straight line and record where awareness hits 100. Do it in bright light, in shadow, crouched and running. You should be able to predict all eight numbers before you run it. If you cannot, your model has a hidden variable.
The escape test. Trigger Alert deliberately, then break line of sight and hide. Time how long until the enemy returns to Unaware. Anything over about 40 seconds reads as punishment. Anything under 10 reads as if the AI has no memory. Run it in three different room layouts, because cover density changes the answer more than the parameters do.
Both tests take ten minutes and will tell you more than an afternoon of behaviour tree tweaking. Readable AI is mostly honest numbers and loud transitions — the cleverness is optional.