Lessons
How game agents decide, move and read the map
Three families of decision-making, built from scratch and running live: utility scoring, where every option gets a number from response curves; behaviour trees, where a hand-built priority structure is walked every tick; and goal-oriented action planning, where the agent searches for a sequence of actions that reaches a goal. They all drive the same agent in the same small arena, so you can see what each one gets right, what it gets wrong, and what it costs. Then movement: steering as a stack of choices (how an agent moves, follows a path and notices walls, and how those combine), avoiding other agents from a separation force to ORCA, and parties that hold a formation through a doorway. Navmeshes: Recast's build stepped through stage by stage, and Detour against writing your own planner. And terrain analysis: chokes, cover generation stepped through algorithm by algorithm, keeping cover valid as the world changes, and choosing it. Influence and threat maps: whose ground is whose, where an enemy could hit you from, and routes that keep out of sight. Shared knowledge: what a guild, a party and an adventurer each know when parties can only read the guild board at waystones. And party roles: a tank, a cleric and three damage dealers against an orc warchief, with a threat table, triage healing and telegraphed attacks.
Utility
- 1Utility AI, scoring with curvesReplace hand-tuned score arithmetic with a structure that scales: factors describe the world, considerations turn one factor into a 0 to 1 score through a response curve, and a behaviour's score is the product of its considerations. With a live inspector to poke at.
- 2Choosing and committingScoring is half the job. How to pick from the scores (best, weighted random, dual utility), why agents flip-flop between two actions, and the tools that stop it: inertia, commitment, and considerations that don't undo themselves. With the agent fighting live.
Trees and plans
- 3Behaviour treesA behaviour tree is a priority list you can read: selectors try children until one works, sequences run children until one fails, and every node reports success, failure or still running. The same agent driven by a tree, with every node lit up as it ticks, and what reactive and memory composites change.
- 4Goal-oriented action planningInstead of writing what to do, describe what each action needs and what it changes, give the agent a goal, and let a search find the sequence. World state as facts, A* over states, context-dependent costs, and what it takes to execute a plan in a world that won't sit still.
Putting it together
Movement
- 6SteeringA decision says where to go and a path says which way; steering moves the agent along it, a little every frame, without hitting anything. It isn't one algorithm but four choices: how the agent moves, where on the path it aims, how it notices walls, and how those combine. Compared on one course, including how many directions it really needs.
- 7Local avoidanceAgents avoiding each other, where rays are the wrong tool: every position and velocity is already known. A separation force, social forces, velocity obstacles, RVO and ORCA, measured on the same three crowd scenes, with what each agent is weighing drawn live.
- 8FormationsA party that holds a shape in the open and still gets through a doorway. Slots relative to a leader, what to do when a slot ends up inside a wall, falling into single file along the leader's path, and the small tricks that keep it from looking robotic.
Navmeshes
- 9Inside Recast: from triangles to a navmeshRecast is a pipeline, not a black box: triangles, a voxel heightfield, filters, open spans, erosion, a distance field, regions, contours, polygons and a detail mesh. Every stage stepped through on a small scene, with what each one produces and when you could stop there and use it yourself.
- 10Detour, or your own plannerWhat Detour adds on top of Recast's polygons (queries, path corridors, crowds, tiles and temporary obstacles), what it assumes, and when to keep the navmesh but write your own search: custom costs, time-slicing, and vehicles that can't turn on the spot.
Terrain analysis
- 11Reading terrain, clearance and chokesBefore an AI can use terrain it has to describe it. How wide every place is (a distance transform), how space divides into areas joined by narrow openings (a watershed flood), which openings matter (sampled traffic), and why movement and line of sight need separate answers.
- 12Generating coverFive ways to find cover, stepped through: scanning every cell, the Recast-style boundary walk that produces rails and peek points, and three sampling methods for when you can't afford to bake. What each finds, what it misses, and when to use it.
- 13Cover in play, keeping it valid and choosing itBaked cover goes stale the moment something explodes. Tiling the bake and rebuilding only dirty tiles, moving cover that carries its own template, and choosing the best spot with a utility query that knows the difference between hiding and fighting.
Reading the world
- 14Influence and threat mapsTerrain analysis describes the map; influence and threat maps describe the situation on it. Whose ground is whose and where the front line runs, where an enemy could hit you from, by what you know (and what you only knew a while ago), and how a utility score or a path cost reads it.
- 15Shared knowledge, and reading it lateWhat goes on a guild’s, a party’s and an adventurer’s blackboard when parties can only read and post the guild board at waystones. A troll moves, the guild updates its notice, and a party that hasn’t passed a waystone keeps walking to the old place. A versioned log with one watermark per party instead of a copy per party, stale sightings with an age, flushing up and catching up, merging by when things were true, and capping history with snapshots.
Parties
Examples are in C++, with notes on running them as flecs systems. The arena is deterministic: the same seed and the same brain always replay the same fight.
Unit sprites from Tiny Dungeon by Kenney (CC0).