Draft — unlisted and not indexed until published.

Behavior Trees vs GOAP vs Utility AI

Disclosure: some links on this page are affiliate links. If you buy through them we may earn a commission at no extra cost to you. It helps keep the free editor running.

Once you’ve ruled out a plain state machine (see Behavior Trees vs Finite State Machines), three architectures dominate the conversation: behavior trees, GOAP, and utility AI. All three have shipped in acclaimed games. They differ on one axis that matters more than any feature list: who decides the sequence of actions — you, at design time, or the system, at runtime?

The 30-second versions

A behavior tree is an authored priority structure: you write down what to try and in what order, and the tree reactively picks the highest-priority branch whose conditions hold. (Full introduction here.)

GOAP (Goal-Oriented Action Planning) gives the agent a goal (“player is dead”) and a pile of actions, each with preconditions and effects (“Shoot: requires loaded weapon, causes damage”). A planner then searches for an action sequence that reaches the goal — at runtime, per situation. Jeff Orkin’s AI for F.E.A.R. (2005) made the technique famous, and its soldiers’ flanking and improvisation are still cited today.

Utility AI scores every possible action continuously — each action gets a curve-driven number from current state (hunger, distance, ammo, threat) and the best score wins. It’s how The Sims weighs a Sim’s needs, and Dave Mark’s “Infinite Axis” formulation of it is widely used for ambient and sim-heavy AI.

What each one buys you — and costs you

Behavior trees buy legibility and control. The tree is the documentation; designers can read it, tooling can visualize it, and QA can reproduce it. The cost: a BT will never surprise you. If you didn’t author a branch for a situation, the agent has no answer to it.

GOAP buys emergence. The planner finds action chains you never explicitly wrote, which is magic when it works — and the problem when it doesn’t. Debugging means asking “why did the planner choose this chain?”, planning has a real CPU cost, and tuning behavior means indirectly nudging costs and world-state modeling rather than editing a structure. Most games that tried GOAP discovered their design actually wanted authored behavior: predictable enemies that telegraph and can be learned. It shines when improvisation is the point.

Utility AI buys smooth prioritization over many competing motives. Where a BT expresses “flee beats fight” as a hard ordering, utility expresses “flee gradually becomes more attractive as health drops and distance closes” — no thresholds, no branch flapping. The cost is tuning and explainability: behavior lives in curve shapes and weight tables, and “why did he do that?” turns into spreadsheet archaeology.

Head to head

DimensionBehavior treeGOAPUtility AI
Who sequences actionsAuthorRuntime plannerNeither — continuous re-scoring
PredictabilityHighLowMedium
Emergent solutionsNoneThe whole pointSome
DebuggingRead the treeInspect planner searchInspect scores/curves
Designer toolingMature visual editorsRareSpreadsheets + custom UIs
CPU costLow–mediumPlanning spikesScoring every option, often
Sweet spotEnemies, bosses, NPCs, robotsImprovising agents, sim sandboxesAmbient life, colony/sim games

The hybrids real games ship

These compose more often than they compete:

So which should you use?

For the theory behind all three, Ian Millington’s AI for Games (Amazon) covers the field, and Dave Mark’s Behavioral Mathematics for Game AI (Amazon) is the standard utility text. The free Game AI Pro chapters include first-hand writeups of every architecture above.

If a behavior tree is your pick, sketch your agent in the free online editor before writing any code:

▶ Start from the enemy AI example

Recommended reading

Books that go deeper on behavior trees and game AI.

As an Amazon Associate, behaviortrees.com earns from qualifying purchases.