AI Architecture Patterns

Summary

AI architecture patterns are structural techniques that apply across different decision-making algorithms — finite-state machines, behaviour trees, utility AI, GOAP, and HTN. Many of the hardest problems in game AI recur regardless of which algorithm you choose, and the solutions have been independently reinvented across studios. Understanding these patterns lets you make good structural decisions before committing to a particular decision-making approach.

The primary source for this page is Kevin Dill’s chapter “Structural Architecture — Common Tricks of the Trade” in Game AI Pro 360: Guide to Architecture (Dill, see source-game-ai-pro-360-architecture). The reactivity/deliberation split is from Carle Côté’s chapter “Reactivity and Deliberation in Decision-Making Systems” (Ch. 8).

Key Ideas

1. Hierarchical Reasoning

The complexity of configuring AI scales worse than linearly with the number of options. For FSMs, adding a state can require transitions to every other existing state — O(n²) growth. Breaking the decision-making up hierarchically keeps each reasoner to a manageable size.

Principle: Have a high-level reasoner make broad decisions (e.g. “enter combat”, “follow daily schedule”, “start conversation”), then pass control to a lower-level reasoner that handles the details of each.

• 25 options in a flat FSM: O(25²) = 625 configuration cost.
• 5 reasoners with 5 options each: 5 × (5²) = 125. A 5× reduction from the same number of total options.

Hierarchy is built into behaviour trees (selector/sequence nesting), HTN planners (compound tasks decomposing into subtasks), and hierarchical FSMs. The same principle applies to utility systems (bucketed priorities) and script-based architectures.

2. Option Stacks

Reactive AI evaluates the situation frequently and picks the best current option. This creates a tension: options should be persistent (committing once prevents jitter), but the AI also needs to react instantly to high-priority events and then resume what it was doing.

Option stacks solve the suspend-and-resume problem:

• When a high-priority option activates (e.g. grenade nearby), push it onto the stack rather than replacing the current option.
• When it completes, pop it — the previous option resumes with its internal state intact.
• Options can be several levels deep (strategic mission → react to ambush → dodge grenade).

Stack at frame 0:  [Attack outpost]
Stack at frame 1:  [Dodge grenade] → [React to ambush] → [Attack outpost]
Stack at frame 2:  [React to ambush] → [Attack outpost]   (grenade resolved)
Stack at frame 3:  [Attack outpost]                        (ambush resolved)

Common uses:

• Hit reactions — push an “Is Hit” option that suspends all others while the flinch animation plays.
• Reload — push a Reload option; resume firing the same weapon when done.
• Interrupt and return — any temporary high-priority task that doesn’t represent a lasting decision.

Implementation sketch (Unity C#):

// The option stack is agnostic to the underlying decision architecture
public class AIOptionStack : MonoBehaviour
{
    private Stack<IAIOption> _stack = new();
 
    public void Push(IAIOption option)
    {
        if (_stack.TryPeek(out var current)) current.Suspend();
        _stack.Push(option);
        option.Enter();
    }
 
    public void PopCurrent()
    {
        if (_stack.TryPop(out var finished)) finished.Exit();
        if (_stack.TryPeek(out var resumed)) resumed.Resume();
    }
 
    public void Tick()
    {
        if (_stack.TryPeek(out var top)) top.Update();
    }
}
 
public interface IAIOption
{
    void Enter();
    void Update();
    void Suspend();
    void Resume();
    void Exit();
}

The option at the top of the stack has exclusive control. When it finishes (PopCurrent()), the one below resumes.

3. Blackboard (Knowledge Management)

See blackboard-architecture for the full concept page.

Short version: a shared key-value store that multiple AI components read from and write to — used to cache expensive queries (LOS, paths), coordinate multi-agent behaviour (target assignment, cover reservation), and pass output from one reasoner to another. Two-level split (character blackboard + global blackboard) is a common practical pattern.

4. Intelligent Objects and Terrain

Rather than encoding all world knowledge inside the NPC, push intelligence into the objects, terrain, and events of the world itself.

The Sims advertisement system: Objects advertise the actions they afford and how to perform them. The NPC reads the advertisements and picks one — the NPC itself needs very little hard-coded knowledge. Consequences for DLC: new objects contain new behaviours, so expansion packs require no changes to the executable (Dill, Ch. 2, see source-game-ai-pro-360-architecture).

Red Dead Redemption hotspot system: The town environment contains hundreds of hotspots, each storing who can use it, what time of day it is valid, and a behaviour tree for characters on it. Some hotspots require multiple characters (a poker game, a bar conversation). The town’s NPCs themselves carry very little intelligence — the world carries it (Dill, Ch. 2).

Darkspore ability system: Hundreds of unique abilities each carry their own AI-relevant intelligence, allowing them to function correctly without changes to the central AI code (Dill, Ch. 2).

Event-carried intelligence: A school fire event can carry information about how different categories of people (children, teachers, firemen) should respond. The event is smart; the agents just need to ask it.

Implication for Unity design: A SmartObject or Hotspot component on world objects can hold behaviour descriptions, preconditions, and state that NPCs discover via raycasts or trigger zones. This scales much better than encoding every world interaction in an NPC’s decision tree.

5. Modularity and Considerations

Modular AI factored into small reusable components eliminates duplicate code and raises the level of abstraction during configuration.

Considerations are modules that evaluate one aspect of the world and return a value (Boolean for rule-based/FSM transitions, or float for utility scoring). The same HealthCheck consideration applies to “should I flee?”, “should I heal?”, and “should I call for help?” — write it once, use it everywhere.

Weight functions map a raw input (health, ammo, distance) to a normalised 0–1 utility value. A small library of weight functions (linear, quadratic, logistic, piecewise) handles most mapping needs and can be applied consistently as reloadable data assets.

Target selectors are modular components that specify what the AI is targeting. They decouple “find the best enemy” logic from the actions that use a target, and can be stored on the blackboard so characters can communicate about targets.

This approach was formalised in Dill’s GAIA architecture (used on Red Dead Redemption, Zoo Tycoon 2) and later expanded in the Modular AI chapter (Dill and Dragert, Ch. 21, Game AI Pro 360: Guide to Architecture).

6. Reactivity vs Deliberation (Architectural Separation)

Côté identifies a common structural pitfall: treating reactivity and deliberation as the same problem and solving them with one model (Côté, Ch. 8, see source-game-ai-pro-360-architecture).

Property	Reactivity	Deliberation
Trigger	High-priority interrupt (perception event, damage)	Task completion, context invalidation
Goal	Instant action — short duration	Sustained action — held as long as valid
Example	Hit reaction, dodge, verbal bark	Patrol, combat, chase, conversation
Decision model	Rule-based or lookup; must be fast	FSM, BT, planner; can be richer

The problem with unifying them: If you add reaction states (Hurt, Suffocate) to a deliberation FSM, every deliberation state needs transitions to every reaction state. Adding a new reaction state means adding transitions from every existing deliberation state — O(n×m) growth.

The solution: Separate modules connected by an Action Selector:

Stimuli
  │
  ├─► Deliberation Module → deliberate action description
  │
  └─► Reactivity Module → reaction action description
              │
              ▼
        Action Selector ──► Action to Execute

The Action Selector sequences deliberation and reactivity: reactions interrupt deliberate actions and the deliberation module resumes afterwards. Each module can use its own decision model and conceptual representation independently.

Three-layer hybrid architecture (Côté’s extension):

1. Deliberating Layer — manages when to engage actions (FSM, BT, planner working with high-level task descriptions)
2. Sequencing Layer — Action Selector; arbitrates between deliberation and reactivity
3. Controlling Layer — pool of concrete action implementations, each with their own decision models for execution

This closely parallels the three-layer hierarchy in squad-ai-patterns and the sense/think/act cycle in game-ai-agent-design.

AI Level-of-Detail (AI LOD)

Performance budget for AI is finite. The LOD Trader pattern (Sunshine-Hill, Ch. 11, Game AI Pro 360: Guide to Architecture) dynamically assigns computational budget:

• Distant or off-screen NPCs run cheaper decision loops (fewer queries, lower update frequency, simplified world model).
• An LOD manager tracks all active AI agents and their current LOD level, adjusting based on distance, visibility, and frame budget.
• Transitions between LOD levels must be smooth — abrupt changes in behaviour fidelity are noticeable to players.

In Unity, LODGroup handles mesh LOD but not AI LOD. An AI-specific LODScheduler component reads player distance and sets an AILODLevel enum on each NPC. Lower LOD levels skip expensive BT subtrees or reduce update rate via InvokeRepeating with a larger interval.

Production Rules in Games

Production systems (ordered if-then rule sets) are an alternative or complement to BTs for specific domains. When rules are few, data-driven, and need rapid authoring by designers, a production rule system is simpler than a full BT.

• 1849 (Zubek, Ch. 15): a city-builder used production rules for NPC daily activity selection — short rules like “IF hungry AND food available THEN eat” are readable by designers and easy to reorder.
• EA Sports titles (Schiel, Ch. 16): production rules supplemented by machine learning for emergent team sport AI behaviours.

Production rules are effectively a flat priority-ordered rule-based AI (Dill’s overview in Ch. 2). They suffer from the same scaling problem as FSMs if the rule count grows large — at that point, BTs or utility systems scale better.

Runtime Compiled C++ (RTCC) for AI Iteration

A recurring workflow problem in game AI is compile-iteration time. Scripting languages (Lua, Python, custom DSLs) solve this at a performance cost. RTCC (Binks, Jack and Wilson, Ch. 12, Game AI Pro 360: Guide to Architecture) compiles and hot-reloads native C++ at runtime, achieving scripting-speed iteration with native performance.

For Unity/C# teams, this concern is partly addressed by the C# compilation pipeline and Play Mode hot-reload. The architectural lesson is: decouple AI configuration from the AI algorithm. Whether the configuration is in Lua, JSON, or a ScriptableObject, the ability to change and reload it without restarting the game has a significant positive impact on AI development velocity (Dawe, Ch. 4, see source-game-ai-pro-360-architecture).

In Practice: Choosing Architecture Patterns

Situation	Recommended pattern
NPC needs to respond to hit, then resume previous task	Option stack
Multiple systems query the same LOS result	Blackboard caching
Multiple NPCs need to coordinate target selection	Global blackboard
World has many interactive objects with their own AI logic	Intelligent objects (SmartObject/Hotspot)
AI code is duplicated across many similar NPCs	Modularity via considerations
Reactive barks/flinches are cluttering the main FSM	Reactivity/deliberation separation
NPC count × AI fidelity exceeds frame budget	AI LOD
Designers need to tweak simple rule sets without code changes	Production rules

Related

• blackboard-architecture — full concept page for the blackboard pattern
• game-ai-agent-design — overview of AI decision-making algorithms (FSM/BT/Utility/GOAP/HTN)
• behaviour-trees — the most common architecture; hierarchy and modularity are especially relevant here
• utility-ai — considerations and weight functions map directly onto utility scoring
• squad-ai-patterns — three-layer hierarchy and the deliberation/reactivity split at squad level
• npc-performance-at-scale — AI LOD and scheduling for large NPC populations
• ai-state-machine-pattern — FSM architecture, option stacks often built on top of FSMs
• goal-oriented-action-planning — the GOAP world-state model is a form of shared knowledge store
• source-game-ai-pro-360-architecture — primary source (Dill Ch. 2, Côté Ch. 8, and others)