Game utility AI explained

What utility AI is (and is not)

Utility AI is a decision-making framework, not a pathfinding or animation system. It answers: given everything I know right now, which action should this agent take? Actions might be coarse (Attack, Flee, Heal) or fine-grained (ThrowGrenade, ReloadBehindCover, FlankLeft).

Each action exposes one or more considerations — small functions that read context and return a score from 0.0 to 1.0. The action's final score is typically the product (or weighted sum) of its considerations. The agent evaluates every enabled action, compares scores, and commits to a winner for some duration or until scores reshuffle enough to warrant a switch.

Utility AI is not machine learning. There is no training loop — designers tune curves and weights until behavior feels right. It is also not GOAP (goal-oriented action planning), which searches action sequences toward a goal; utility picks one action per decision tick unless you layer a planner on top.

The scoring pipeline

A minimal utility system runs each AI tick (often aligned with frame timing or a slower 0.2–0.5 s cadence for expensive agents):

1. Gather context — write perception into a shared blackboard: player distance, line of sight, self health, ammo count, ally positions, cover availability.
2. Filter actions — disable impossible choices (no grenades left, ability on cooldown, action blocked by current animation state).
3. Score each action — run considerations; multiply or combine into a final utility value.
4. Select — pick argmax (highest score) or weighted random sample.
5. Execute — hand off to animation, navigation, and combat subsystems; optionally lock the action for a minimum time to prevent flicker.

The blackboard pattern is the same one behavior trees use: decouple sensing from deciding so multiple AI layers read consistent data.

Considerations and response curves

A consideration maps a raw input (distance to player = 12 meters) to a normalized score. Raw linear mapping rarely feels good — designers use response curves instead:

• Linear — score rises proportionally with ammo count. Fine for simple resources.
• Inverse linear — closer distance → higher attack desire.
• Logistic (S-curve) — flat at extremes, steep in the middle. Ideal for health: fine above 60%, panic below 25%.
• Step / threshold — zero until line-of-sight acquired, then 1.0. Use sparingly; hard steps cause visible snapping unless blended.
• Custom piecewise — designers draw curves in-engine (Unreal's Utility AI plugins, Unity's AnimationCurves on consideration assets).

Example: the Attack action might multiply:

• DistanceToPlayer — peaks at medium range, drops at melee and sniper extremes.
• HasLineOfSight — binary or soft partial cover penalty.
• SelfHealth — high health boosts aggression; low health suppresses unless a Berserk trait inverts the curve.
• AmmoAvailable — zero score when empty, preventing futile attacks.

Final utility = product of considerations. Multiplication means any near-zero consideration vetoes the action — useful for hard gates. Weighted sums are softer when you want partial credit.

Action selection strategies

Argmax (deterministic)

Always pick the highest-scoring action. Predictable and debuggable, but two actions with scores 0.81 vs 0.80 never alternate — players notice repetition. Add a small hysteresis band: do not switch unless the new winner exceeds the incumbent by 0.05–0.10 to stop oscillation at tie lines.

Weighted random (stochastic)

Sample an action with probability proportional to its score. A 0.6 attack vs 0.4 flee split produces varied but believable behavior. Normalize scores to a probability distribution; use a seeded RNG per agent for reproducible QA.

Top-k sampling

Consider only the top three actions, renormalize, then sample. Prevents a 0.01-score absurd action from occasionally firing while still adding variety among plausible choices.

Commitment windows

After selecting Flee, lock for 2–4 seconds unless health drops below an emergency threshold. Prevents the "vacillating enemy" who runs, stops, runs, stops every frame when scores hover near parity.

Classic use cases

Flee vs fight

Two actions compete continuously. As health falls, the flee consideration's logistic curve overtakes attack — no explicit state transition required. Add AllyNearby to boost fight scores for pack hunters, or PlayerIsAiming to spike flee when the player ADS.

Weapon and ability selection

Each weapon is an action: shotgun scores high at close range, sniper at long range, grenade when cluster density of enemies exceeds a threshold. Cooldowns gate disabled actions before scoring runs.

Cover and positioning

Generate candidate cover points (navmesh queries), score each with DistanceToCover, CoverQuality (height, angle to threat), FlankPotential, then move to the winner. Utility excels when the choice set changes every tick as the player moves.

Squad and role assignment

Roles (Suppress, Flank, Revive) are actions with considerations for team spacing and player threat vector. Only one agent should reviving at a time — add a blackboard flag ReviveInProgress that zeros other agents' revive scores.

Life simulation and strategy

The Sims-style needs (hunger, social, hygiene) are considerations on actions like Eat, Chat, Shower. Strategy games use utility for unit ability firing when dozens of situational factors interact.

Utility AI vs FSMs and behavior trees

Shipping games often hybridize: an FSM handles locomotion states; a behavior tree runs combat combos; a utility layer above picks which BT profile (aggressive, defensive, support) is active based on scores. Do not force one pattern to solve every problem.

Multiplayer and performance

In authoritative multiplayer, AI decisions must run on the server (or a designated simulation host) so all clients see the same action. See multiplayer netcode for replication basics — utility scores themselves rarely cross the wire; only the resulting action and movement do.

Performance tips:

• Throttle scoring — full evaluation every 0.25 s is enough for most humanoid NPCs; stagger agent ticks across frames.
• Cache blackboard writes — perception sensors update once per tick, not per consideration.
• Cap candidate sets — score the nearest five cover points, not every navmesh polygon.
• Early-out filters — skip scoring when the agent is stunned or in a scripted sequence.

Debugging and tuning

Utility AI is invisible when it works and baffling when it does not. Build tooling from day one:

• Score overlay — on-screen bar per action showing live utility; highlight the winner in green.
• Consideration breakdown — click an action to see each factor's raw input, curve output, and product step.
• Curve editor in data — designers adjust S-curves without recompiling; version curves in source control.
• Replay hooks — record blackboard snapshots when a "wrong" decision fires; replay scoring offline.
• Unit tests on curves — assert Flee utility exceeds Attack when health = 0.1 and no allies nearby.

When an enemy feels dumb, resist adding special-case code. First check whether a consideration is flatlined (always 0 or always 1) because the curve domain does not match your level metrics — a distance curve tuned for 30 m arenas fails in a 5 m corridor.

Common mistakes

• Too many actions — twenty micro-actions per tick; consolidate or hierarchicalize into role selection then sub-utility.
• Multiplying correlated considerations — distance and time-to-target often measure the same thing; double-counting skews scores.
• No commitment window — actions flip every frame at score ties.
• Ignoring animation gates — utility picks Reload while a melee swing is mid-swing; filter by anim state.
• Designer-blind curves — programmers hardcode exponentials in C#; iteration stalls.
• Deterministic argmax only — bosses feel robotic; mix stochastic selection for grunts, argmax for elites if desired.
• Skipping playtest telemetry — log action distribution; 95% attack means flee curves are miscalibrated.

Production checklist

• Define the action set and blackboard schema before writing considerations.
• Implement hard filters (cooldown, anim lock, resource empty) before scoring.
• Author response curves in data, not scattered magic numbers in code.
• Choose selection mode (argmax, weighted, top-k) per agent archetype.
• Add hysteresis and minimum commitment time to prevent flicker.
• Build live score overlay and per-consideration breakdown for QA.
• Throttle evaluation cadence and stagger ticks for crowd scenes.
• Run server-side in multiplayer; replicate resulting actions only.
• Log action histograms in playtests; retune curves from data.
• Document when to use utility vs BT/FSM so the team does not hybridize accidentally.

Key takeaways

• Utility AI scores actions from normalized considerations each decision tick — smooth analog preferences without transition spaghetti.
• Response curves (logistic, inverse, piecewise) are the primary designer tuning surface.
• Selection strategy matters as much as scoring: argmax for predictability, weighted random for variety.
• Hybrid stacks are normal — utility picks roles; BTs and FSMs execute them.
• Debug visualization and playtest histograms separate polished AI from random curve twiddling.

Related reading

• Game behavior trees explained — selectors, sequences, blackboards, and when BTs beat utility
• Game state machines (FSM) explained — explicit states, transitions, and animation layering
• Game difficulty curves explained — tuning challenge so AI aggression matches player skill
• Pathfinding and A* in games explained — navigation after utility picks a cover point or flee vector