Summary
Game AI agent design is the study of how to make NPCs, enemies, companions, and other autonomous agents behave in ways that are readable, purposeful, and fun to play against. In practice, students usually arrive here through questions like “how do I make enemy AI?”, “should I use behaviour trees or GOAP?”, or “how smart should an NPC be?” The answer is that good game AI is not about maximum intelligence; it is about the right level of intelligence for player experience, production cost, and design clarity. Millington’s production-focused textbook and Yannakakis and Togelius’ field overview together show that the topic spans both classical NPC control and the broader AI-and-games research landscape. (Millington, Artificial Intelligence for Games, see source-artificial-intelligence-for-games; Yannakakis and Togelius, Artificial Intelligence and Games, see source-ai-and-games)
(Prof Charles, CRE341 Wk 5.1, see source-cre341-lectures)
What is AI?
Russell and Norvig identify four definitions of AI:
| Frame | Definition | Notes |
|---|---|---|
| Thinks like humans | Cognitive science approach; models tested against psychology | Rarely the game goal |
| Acts like humans | Turing Test (1950) — observable behaviour matches human output | Common game goal |
| Thinks rationally | Aristotelian logical reasoning | Brittle in open environments |
| Acts rationally | Acts to achieve goals given current beliefs | Most applicable to game agents |
Game AI primarily pursues acting rationally in the context of entertaining human opponents — including deliberate sub-rational behaviour.
Artificial stupidity
“Real people are stupid… sometimes! There can be much humour in a well-designed stupid-bot!” — Falstein, The 400 Project — Rules of Game Design
Game AI design rules (Falstein):
- Make the effects of the AI visible to the player — players should understand why the NPC did what it did
- Add a small amount of randomness to AI calculations — prevents deterministic exploitation; makes the AI feel alive
- Create AI in the mind of the player — the player’s perception of intelligence matters more than the actual algorithm
Design principle: opponents should be beatable. Unpredictability and minor mistakes make agents more entertaining than optimal opponents.
Autonomous agents
“An autonomous agent is a system situated within and a part of an environment that senses that environment and acts on it, over time, in pursuit of its own agenda and so as to effect what it senses in the future.”
Physical autonomous agent movement has three layers (each can be swapped independently):
| Layer | Responsibility | Example |
|---|---|---|
| Action Selection | Choose goals; decide which plan to follow | ”Attack nearest enemy” |
| Steering | Calculate desired trajectory to satisfy goal | Reynolds steering behaviours |
| Locomotion | Execute physical movement from A to B | NavMesh agent, Rigidbody physics |
Separating these layers allows independent improvement or replacement of each component. See also steering-behaviours.
Agent architectures
Utility-based agents
Choose actions based on utility functions that evaluate expected benefit. Each possible action receives a score; the agent selects the highest-scoring action given its current state. Scales well to large action sets but requires careful tuning of utility functions.
Maslow’s hierarchy applied to agents
Agent needs can be modelled hierarchically (analogous to Maslow’s human needs pyramid):
- Base needs: survival, health, immediate safety
- Mid needs: territory, resources, social behaviour
- Higher needs: goal pursuit, self-improvement
Higher-level behaviours only activate when lower-level needs are satisfied, producing naturalistic prioritisation without complex branching logic.
Behaviour Trees
See also behaviour-trees for a dedicated page.
A Behaviour Tree (BT) composes AI behaviours hierarchically using a tree structure of nodes. Execution flows from root to leaves; each node returns Success, Failure, or Running.
Node types
| Node | Symbol | Behaviour |
|---|---|---|
| Selector | ? | Tries children left to right; returns Success on first success (OR logic) |
| Sequence | → | Runs all children; returns Failure on first failure (AND logic) |
| Decorator | Diamond | Wraps a child; modifies its result (invert, repeat, delay, limit) |
| Leaf | Rectangle | Executes an action or checks a condition |
Example structure
Root (Selector)
├── Flee Sequence (Sequence)
│ ├── Is health low? (Condition)
│ └── Move away from enemy (Action)
├── Attack Sequence (Sequence)
│ ├── Can see enemy? (Condition)
│ └── Attack enemy (Action)
└── Patrol (Action)
Priority is expressed by child order. The Selector tries Flee first, then Attack, then Patrol — health preservation takes precedence over combat.
Why BTs over state machines:
- Reusable subtrees (share “attack” logic across different enemy types)
- Priority expressed structurally, not via explicit transition rules
- Easier to debug (clear execution path is traceable)
- Better for reactive agents with many competing behaviours
Resources:
- Chris Simpson’s Gamasutra guide on Behaviour Trees (canonical intro)
- HTN (Hierarchical Task Networks): combines BT-style composition with planning (aiandgames.com)
Goal Action Planning (GOAP)
See also goal-oriented-action-planning for a dedicated page.
GOAP is a deliberative planner architecture for game AI. Rather than a fixed behaviour tree, the agent dynamically constructs a plan — a sequence of actions — to reach a goal from the current world state.
Core components
| Component | Description |
|---|---|
| World State | Current facts about the world (and agent’s inventory/status) |
| Goal | Desired world state the agent wants to reach |
| Actions | Available atomic operations; each has preconditions and effects |
| Planner | Searches for a valid action sequence that transitions from current state to goal state |
| Plan | Ordered sequence of actions output by the planner |
Why GOAP over a fixed BT?
A BT encodes behaviours the designer anticipates. GOAP lets the agent compose novel plans from available actions — the agent can respond to situations the designer did not explicitly script, because any valid chain of actions leading to the goal is acceptable.
Classic example (F.E.A.R.): The enemy AI could kill a player with a gun, kick a table for cover, throw a grenade through a window, or sprint to a flanking position — all emergent from the same GOAP planner deciding the cheapest action sequence toward “enemy dead”.
Trade-offs
| Behaviour Tree | GOAP | |
|---|---|---|
| Expressiveness | Reactive priorities, hierarchical | Deliberative, plan-based |
| Complexity | Moderate | Higher (planning search cost) |
| Designer control | High (explicit tree) | Lower (emergent plans) |
| Surprising behaviours | Limited | Can surprise designers and players |
| Best for | Reactive, time-critical agents | Complex multi-step goal achievement |
Multiple plans can also be sequenced (e.g. “get weapon” then “kill enemy”) for longer-horizon behaviour.
Hierarchical Task Network (HTN) planning
HTN planning is a structured alternative to GOAP. Rather than searching an unconstrained action space for a path to the goal, HTN decomposes tasks top-down through a hierarchy of methods — conditional decomposition rules authored by the designer.
Structure
| Term | Definition |
|---|---|
| Task | An abstract or primitive unit of work (e.g. behave, combat-behaviour, shoot-at-enemy) |
| Compound task | A task that decomposes into subtasks via methods |
| Primitive action | A leaf task with no further decomposition — directly executable |
| Method | A rule: if preconditions hold, decompose this compound task into [list of subtasks] |
| Domain | The complete set of tasks and methods for a character type |
Execution
The planner attempts methods in declared priority order. The first method whose preconditions are satisfied is applied, producing subtasks that are in turn decomposed until all tasks are primitive. Execution proceeds through the resulting flat plan.
Task: behave
Method 1 [precondition: health < 20%] → flee-to-safety
Method 2 [precondition: isMedic AND allyNeedsHealing] → heal-ally
Method 3 [precondition: hasSquadOrder] → execute-squad-order
Method 4 [precondition: canSeeEnemy] → combat-behaviour
Method 5 [precondition: always] → idle-patrol
Priority is unambiguous — Method 1 always beats Method 2, regardless of relative utility scores. This is the key advantage of HTN over GOAP or utility AI for hierarchical squad bots: designers can predict and guarantee plan priority (Killzone 3 team, Chapter 4, see source-game-ai-pro-360-tactics-strategy).
Replanning
The HTN planner does not replan every frame. Replanning is triggered by:
- A plan step completing (needs next step).
- A continuation condition failing — a check run every tick that validates the current plan is still applicable. If false, the agent replans immediately.
- A new external order arriving (e.g. squad commander sends a new objective).
- A fixed-rate background check (safety net for edge cases).
Bounding replanning to events rather than running it every frame keeps computational cost predictable.
HTN vs. GOAP
| HTN | GOAP | |
|---|---|---|
| Priority control | Explicit — method order | Implicit — action costs |
| Designer legibility | High — the domain reads like a flowchart | Lower — emergent from cost functions |
| Surprising behaviours | Rare (predictable decomposition) | Common (novel plans) |
| Best for | Hierarchical bots with clear priority ordering | Multi-step goal pursuit in open environments |
See squad-ai-patterns for a full production example of HTN at multiple hierarchy levels (individual bot, squad, commander).
Intelligent interactive storytelling
One of the core challenges of game AI is making NPCs behave consistently with narrative context in real time. Research and commercial projects are now combining game engines with large language models (LLMs) to produce dynamic narrative agents.
The following architecture (from a CRE341 research/consultancy project) illustrates one approach — a live-action theatre system where both human and AI actors participate in a shared interactive story:
IoT Devices ──────┐
Human Actors ─────┤──→ Interface ──→ Story Elements ──→
Human Director ───┘ ├──→ Unity App ──→ AI LLM Avatar
└──→ Networked Environs Manager
ChatGPT / Local LLM ──→ Story Sync
Components:
| Component | Role |
|---|---|
| IoT Devices + Human Actors + Director | Real-world inputs providing scene context |
| Story Elements (from file) | Authored scaffolding: characters, goals, narrative constraints |
| Unity App | Manages virtual environment and scene state |
| AI LLM Avatar | NPC driven by ChatGPT or local LLM; responds dynamically to scene state |
| Networked Environs Manager | Coordinates multiple Unity instances and actors |
| Story Sync | Keeps AI dialogue consistent with current narrative state |
The LLM generates contextually appropriate dialogue within the authored story constraints — neither fully scripted nor fully emergent. For the narrative design context, see narrative-design and generative-ai-game-dev.
Skills and behaviours split
In complex commercial AI systems, the action selection layer is often subdivided further. The Last of Us (Naughty Dog) uses a two-tier structure described by Botta (Game AI Pro 360, Ch. 1, see source-game-ai-pro-360-character-behavior):
- Skills: High-level behavioural modes managed by a prioritised FSM. A skill decides what the NPC is trying to do — pursue the player, investigate a sound, patrol a route. Each skill is a discrete, named mode; only one skill is active at a time, and higher-priority skills interrupt lower-priority ones.
- Behaviours: Modular, reusable implementations of individual capabilities — move to a location, play an animation, play a sound. Behaviours implement how the active skill achieves its goal. Multiple behaviours can run concurrently; they compose freely.
This split means skill code stays clean (decision logic only) and behaviours stay reusable across character types. A “Throw Brick” behaviour is shared by Ellie and enemy Infected without duplication.
Data-driven character types
An extension of this principle: all character types share a single AI class, differentiated entirely by data files. In The Last of Us, every Infected type (Runner, Stalker, Clicker, Bloater) runs the same C++ code. The data file for each type specifies which skills are available, which behaviours those skills activate, and all tuning values. New character types (Stalkers were added months before ship) require no code changes (Botta, Ch. 1, source-game-ai-pro-360-character-behavior).
This is the game AI equivalent of the component pattern: no character-type conditionals in code.
For a more detailed treatment of the commercial utility AI pattern (Dragon Age: Inquisition’s Behaviour Decision System), see utility-ai.
Challenges of digital game AI
- Intelligent interactive storytelling — NPCs must behave consistently with narrative context (see above)
- Dynamic learning and behaviour — agents that adapt to player tactics (see machine-learning-games)
- Representing emotion — credible emotional responses that serve the game’s tone
Recommended teaching order for CRE341
For CRE341, the most teachable route is not to treat every architecture as equally central. A better default is:
- ai-state-machine-pattern as the prerequisite architecture
- behaviour-trees as the canonical core
- utility-ai as the first major extension
- goal-oriented-action-planning as the advanced planning contrast
- HTN via squad-ai-patterns as the specialist production layer
- player-modelling as an adjacent AI-and-games topic rather than the core NPC-control path
This ordering fits the lecture framing particularly well: behaviour trees for reactivity, GOAP for emergent tactics, utility AI for smooth adaptation, and player modelling as part of the broader character/adaptation discussion rather than the default agent-control architecture. (Prof Charles, CRE341 Wks 4.2 and 5.1, see source-cre341-lectures)
See overview-cre341-agent-ai-route for the full argument and trade-offs.
In practice (Unity)
- Unity NavMesh + NavMeshAgent handles Locomotion and pathfinding (see Wk 3 practicals)
- Behaviour Trees: no native Unity support; common libraries include Behaviour Designer, NodeCanvas, or a custom implementation
- GOAP: custom implementation typical; the GOAP tutorial series by Holistic3d (referenced in lectures) is a common starting point
- The ai-state-machine-pattern page covers the simpler State Pattern approach, appropriate when BTs or GOAP are overkill
Related
- ai-state-machine-pattern — simpler alternative; OOP State Pattern for 3–5 behaviours
- behaviour-trees — dedicated BT page with Unity-oriented implementation notes
- goal-oriented-action-planning — dedicated GOAP page
- behaviour-trees-vs-goap — side-by-side comparison of the two most likely student-facing architecture choices
- fuzzy-logic-for-games — graded decision-making for AI
- steering-behaviours — Reynolds’ steering provides the Steering layer beneath Action Selection
- utility-ai — scoring-based action selection; Dragon Age: Inquisition Behaviour Decision System
- influence-maps — spatial data structure for threat/control reasoning; Paragon bots
- npc-perception-systems — vision cones, awareness timers, logical sound events, exposure maps
- buddy-ai — companion AI design; Ellie (The Last of Us) follow system and shooting permission model
- combat-coordinator-pattern — global role registry for coordinated multi-NPC combat
- npc-performance-at-scale — open-loop action queues, daily scripts, hierarchical pathfinding for 1000+ NPCs
- machine-learning-games — RL, neural networks, and GA for adaptive agent behaviour; AI type taxonomy
- genetic-algorithms — evolving agent behaviours as an alternative to hand-designed rules
- player-modelling — AI-and-games view of modelling player behaviour and experience
- overview-cre341-agent-ai-route — recommended canonical teaching route for CRE341 agent AI
- overview-artificial-intelligence-in-games — synthesis page tying classical and modern game AI together
- history-of-game-ai — theory-history view of how authored AI, planning, and broader AI-and-games strands developed
- narrative-design — AI and interactive storytelling interaction
- character-design — character-as-system philosophy; Utility AI; player modelling; LLM NPC architecture; social simulation
- generative-ai-game-dev — LLM-based interactive storytelling; generative AI tools for game dev
- squad-ai-patterns — three-layer hierarchical AI with HTN at individual and squad level; Killzone 3 reference implementation
- tactical-position-selection — position query language for shooter AI
- mcts — Monte Carlo Tree Search for strategy games
- strategic-ai-rts — strategic-scale AI; Lanchester models; region-based reasoning
- source-cre341-lectures
- source-game-ai-pro-360-character-behavior
- source-game-ai-pro-360-tactics-strategy