The question or thesis
If you are studying CRE341 and want the default route for agent AI, start with finite state machines as the prerequisite model, then learn behaviour-trees as the main architecture, then utility-ai as the key extension, with goal-oriented-action-planning and HTN-style systems as advanced contrasts rather than the starting point. In short: behaviour trees are the canonical core, utility AI is the next most useful layer, and player modelling belongs beside that route rather than inside it.
If CRE341 needs a canonical agent AI route, the best default is:
- ai-state-machine-pattern as the prerequisite mental model
- behaviour-trees as the main authored-control architecture
- utility-ai as the first major extension
- goal-oriented-action-planning as the advanced planning contrast
- squad-ai-patterns and HTN as the specialist production layer
- player-modelling as an adjacent AI-and-games topic rather than the core NPC-control path
This recommendation follows the module’s own framing of FSM for simplicity, behaviour trees for reactivity, GOAP for emergent tactics, and utility AI for smooth adaptation. (Prof Charles, CRE341 Wks 3.r1, 4.2, and 5.1, see source-cre341-lectures)
What the evidence suggests
1. Behaviour trees should be the canonical core
Behaviour trees are the strongest default teaching architecture for CRE341 because they sit in the sweet spot between readability, modularity, and practical game usefulness. They are easier to extend than large finite-state machines, but they remain more legible and controllable than full planners. Millington presents them inside the standard production AI toolbox, while Yannakakis and Togelius treat them as one of the major authored-control methods in the field. (Millington, Artificial Intelligence for Games, see source-artificial-intelligence-for-games; Yannakakis and Togelius, Artificial Intelligence and Games, see source-ai-and-games)
For teaching, BTs also align well with Unity thinking:
- clear node types
- repeated ticking from
Update() - easy comparison with the earlier FSM prerequisite
- visible branching logic that students can debug
2. Utility AI should be the second-stage extension
Utility AI is the best next step after BTs because it introduces continuous prioritisation without asking students to author or debug a full planner. It also maps strongly to the character-design side of CRE341, where the lectures frame utility AI as useful for smooth adaptation and expressive NPC behaviour. The Dragon Age: Inquisition case study is especially valuable because it shows a production-ready scoring architecture with clear designer-facing conventions. (Prof Charles, CRE341 Wk 4.2, see source-cre341-lectures; Hanlon and Watts, Game AI Pro 360: Guide to Character Behavior, see source-game-ai-pro-360-character-behavior)
Pedagogically, utility AI teaches:
- action scoring and context-sensitive choice
- the difference between discrete transitions and continuous desirability
- the importance of instrumentation and debugging tables
It is also easier to connect to character-design than GOAP or HTN because it reads as a way of expressing temperament and priority, not only tactical search.
3. GOAP should be taught as the advanced planning contrast
GOAP is important, but it should not be the first canonical architecture. Its value in CRE341 is as the planning contrast to BTs and utility AI: where BTs are reactive and utility AI is greedy, GOAP is deliberative and composes action sequences from world state, preconditions, and effects. This makes it intellectually valuable and historically important, but also harder to author, reason about, and debug in student projects. (Millington, Artificial Intelligence for Games, see source-artificial-intelligence-for-games; Buckland, Programming Game AI by Example, see source-programming-game-ai-by-example)
So GOAP belongs in the route, but as an advanced topic that answers: “What if I want the agent to build a multi-step plan instead of only selecting the best immediate action?“
4. HTN belongs as the production and squad-AI specialism
HTN should be taught after GOAP, not before it, because its main strength is not that it is more general than GOAP, but that it is more structured and production-legible for hierarchical systems. The Killzone 3 case study makes HTN most useful when students are thinking about layered AI, squads, commander logic, and explicit designer control over plan order. (Killzone 3 team, Game AI Pro 360: Guide to Tactics and Strategy, see source-game-ai-pro-360-tactics-strategy)
That makes HTN a strong advanced topic for:
- squad behaviour
- commander/subordinate structures
- complex tactical games
- discussions of predictability versus emergent planning
It is not the best first architecture for general-purpose NPC decision-making in a module route.
5. Player modelling is important, but it is adjacent rather than central
player-modelling should be kept in the CRE341 story because the lectures and Yannakakis/Togelius both treat it as an important AI-and-games topic. But it is not the canonical control architecture for NPC agents. It belongs on the adaptation/analytics/experience-management side of the module rather than in the centre of the authored-NPC-behaviour route. (Prof Charles, CRE341 Wk 4.2, see source-cre341-lectures; Yannakakis and Togelius, Artificial Intelligence and Games, see source-ai-and-games)
In other words:
- behaviour trees, utility AI, GOAP, and HTN answer “How does the NPC decide what to do?”
- player modelling answers “What do we infer about the player, and how might the game adapt?”
That distinction matters pedagogically because otherwise students can leave with a blurred picture of “AI” as one giant category.
Disagreements or tensions
- Best production default vs best teaching default: Utility AI is arguably closer to some modern combat-production practice than BTs, but BTs are still the cleaner teaching spine because they visualise control flow so clearly.
- Emergence vs legibility: GOAP can generate more surprising plans, but that surprise is not always desirable in coursework where debugging and explanation matter.
- Broad AI-and-games field vs agent-AI route: Player modelling is central in AI-and-games research, but secondary in a canonical NPC-control teaching route.
What to investigate next
- Worked Unity/C# teaching examples for behaviour-trees and utility-ai
- A clearer bridge from player-modelling to game-analytics and adaptive narrative systems
Related
game-ai-agent-design · character-design · behaviour-trees · behaviour-trees-vs-goap · utility-ai · goal-oriented-action-planning · squad-ai-patterns · player-modelling · overview-artificial-intelligence-in-games · source-cre341-lectures