[ Deep Dive ]

HTN vs GOAP, when to choose which

Both planning paradigms ship AAA games. Where each one wins, where hybrids work, and why Intent Forge is GOAP — said honestly. If your project is HTN-shaped, use HTN.

Paradigm compareCited

If you've decided you want planning over hand-authored control flow, the next question is which planning paradigm. The two that have shipped AAA games for the last 20 years are:

• GOAP (Goal-Oriented Action Planning) — forward state-space search from current to goal. F.E.A.R. (2005), Tomb Raider (2013), Middle-earth: Shadow of Mordor (2014).
• HTN (Hierarchical Task Network) — decomposition from high-level tasks down to primitives via designer-authored methods. Killzone 2 (2009), Transformers: Fall of Cybertron (2012), Horizon Zero Dawn (2017), and continuing into the Decima Engine's more recent titles per Guerrilla's 2024 AI and Games Conference talk [17].

This page is the honest comparison. Intent Forge is GOAP; the reasons are below. If your project is HTN-shaped, use HTN.

What GOAP is

You write a set of atomic actions, each with:

• Preconditions: what world state must be true
• Effects: how the world state changes after the action runs
• Cost: how expensive this action is to perform

You write goals: target world states.

The planner does the rest. It searches forward from the current state, picking applicable actions, until it finds a sequence that satisfies the goal. The designer writes goals + actions; the planner writes the sequence.

Authoring philosophy: declarative. You tell the system what you want, not how to do it.

What HTN is

You write a hierarchy:

• Tasks: high-level operations like "AssaultBuilding"
• Methods: ways to accomplish a task, each a sequence of sub-tasks
• Primitives: leaf actions that actually execute

The planner decomposes tasks into methods into sub-tasks into primitives until it reaches an executable plan. The designer writes the decomposition strategy; the planner walks it.

Authoring philosophy: procedural. You tell the system how to do things, in what order, under what conditions.

The core trade-off

The fundamental trade-off: GOAP is more emergent and lower-overhead; HTN is more controlled and higher-overhead. Neither is universally better.

When GOAP wins

Small-to-medium action sets (10–30 actions)

At this scale, the planner finds plans in microseconds. Authoring an HTN decomposition for 20 actions is more overhead than just writing the 20 actions — you'd be enumerating decompositions you don't need.

Behaviour mix you can't fully script ahead

A companion AI whose goal mix shifts based on player state, terrain, combat. The designer can't pre-script every transition; GOAP's emergent planning handles cases the designer didn't think of.

Indie / mid-scale teams

HTN authoring takes more dedicated AI engineering time. GOAP is more designer-accessible — a designer with no engineering background can add a new action without help.

When you actively want emergent behaviour

If "the AI did something I didn't program" is a feature (sims, RPGs, sandboxes), GOAP delivers it. If it's a bug (boss choreography), HTN is safer.

When HTN wins

AAA authoring scale (100+ behaviours)

This is the biggest HTN argument. At AAA scale, behaviour combinatorics explode. A 100-action GOAP archetype has a search tree that's painful to debug; a 100-task HTN decomposition is structured into named clusters the designer can reason about.

Killzone 2's AI shipped ~150 actions across ~20 tasks. Horizon Zero Dawn's machines have HTN-driven behaviour graphs that the designers visualised, debugged, and balanced over a multi-year production. That tooling doesn't exist for GOAP at the same scale.

Tight QA / predictability requirements

If your game has cinematic combat sequences where the AI must do specific things in specific orders for the encounter design to work — HTN's bounded decompositions make this provable in a way that GOAP's emergent search isn't.

When the designer's intent IS the gold standard

HTN encodes "we want the AI to do A then B then C, but if X, then B-alt; if Y, fail back to D." That's literally how some designers think about AI behaviour. Force that into GOAP and you'll be writing artificial preconditions to force the planner down specific paths — fighting the framework.

When hybrids fit

Both paradigms compose well with Behavior Trees and StateTrees. The canonical hybrid: BT/ST for the high-level state machine, planner for the in-state behaviour.

• Combat ↔ Patrol ↔ Death is a BT outer shell
• Inside Combat, an Intent Forge plan picks the next combat action
• Inside Patrol, a different plan picks Sleep / Eat / Investigate
• BT manages the transitions between top-level states

This is supported via the dispatcher abstraction. It's how many real projects ship.

A less-common hybrid: HTN at the strategic layer, GOAP at the tactical layer. HTN decomposes "AssaultBuilding" into sub-tasks ("Flank," "Suppress," "Breach"), and each sub-task fires a GOAP plan on the per-unit Intent Forge component. This works but requires substantial custom glue — neither paradigm ships this directly.

Why Intent Forge picked GOAP

Three reasons:

1. Market fit. Marketplace / Fab buyers are indie / mid-scale. The action-set sizes that hit GOAP's sweet spot are exactly the action-set sizes those teams build at. AAA studios that need HTN scale typically have their own in-house AI engineers and don't buy plugins.

2. Authoring accessibility. "Add a new IntentAction asset" is a designer-doable operation. "Add a new task + methods + decomposition tree" requires more thought. Lower friction for the target audience.

3. The stability story. The anti-flap toolkit is the framework's signature differentiator, and it specifically addresses the instability that emerges from goal-priority-driven planning. HTN's bounded decomposition has different stability problems — the toolkit wouldn't transfer cleanly.

What about other paradigms?

• Utility AI: not a planner. Reactive scoring per tick. Best at sub-second tactical decisions (combat moves, animation selection). Often used alongside a planner.
• Behavior Trees: hand-authored control flow, not a planner. Best at designer-scripted behaviour. Often the outer shell of a hybrid.
• State machines / StateTree: same family as BT — hand-authored, not planned.
• Reinforcement learning: research-grade for game AI. No AAA shipping titles use it for primary AI behaviour today (NPCs in ML-Agents demos don't count). Maybe in 5 years.

Recommended reading

• Humphreys, T. (2014). Exploring HTN Planners through Example. Game AI Pro 1, Ch. 12. — Best introduction to HTN for game devs.
• Champandard, A. (2007–2015). AiGameDev archive. — HTN perspectives from F.E.A.R. through Killzone era.
• Orkin, J. (2006). F.E.A.R. GOAP paper [1]. — The reference point.
• Conway, C. (2015). GOAP, 10 Years Later. GDC [3]. — Retrospective on what GOAP learned and where it's going.
• Guerrilla / Decima Engine (2024). HTN Planning in the Decima Engine. AI and Games Conference [17]. — The most recent production HTN talk; useful counterpoint to the GOAP record.
• Jacopin, É. (2025). AI Planning Analytics — From F.E.A.R. (2005) to Assassin's Creed: Shadows (2025). [14] — Twenty-year planner analytics study spanning both paradigms in shipped titles.
• See the Planner Algorithms page for the algorithm-side trade-offs.