GDC08 Notes – Building a Better Battle: HALO 3 AI Objectives

1260Eager crowd…

So I made lots of notes on the Building a Better Battle: HALO 3 AI Objectives talk by Damian Isla, and I finally wrote them up! You can find his slides on this page (direct link), and if you don’t have Office 2007, I made a quick printout to PDF from the 2007 viewer, which is oddly smaller then the original file. I’d recommend glancing through it if you read these, since I don’t usually copy all the stuff off the slides if I can help it.

You can also find additional notes by Damian himself here.

Halo 3 AI Objectives

  • Better == bigger (his note, not mine!), so Halo 3, bigger battles!
  • Designer tools talk, not on the individual AI. How to deal with designer control, etc.

Encounter logic

  • Better word then “battle” – can cover more situations
  • One particular fight is being demonstrated

Encounters are systems

  • Lots of guys and things to do
  • The illusion of strategic intelligence
  • Strategy is environment, story and pacing dependant
    • Environment – a certain level of the game
    • Story – in an example encounter, it might be an objective to protect
    • Both done by the level designer – the designer is the “couchcoach deciding the play in football”

Territory control game! The standard way it works:

  • Pushed back to fall back point
  • Pushed to “last stand” point
    • Breaks the AI/team (by killing most of them usually)
    • Player finishes them off
  • +additional spice
    • Snipers
    • Turrets
    • Hunters
    • Dropships
    • Swarms of buggers


  • The mission designers language for telling the AI what it should be doing
    • In Halo: Territory
      • Behaviour: Agressiveness, etc.
      • Rules of engagement
      • Player following
    • Encounter space has different tasks

The engine works on a control stack basis. 3 levels of things to do:

1. Encounter logic → Reassigning tasks (Mission designer / scripting)

2. Task → Noted above what constitutes a task. (Mission designer / scripting)
↓ ――――――――――――――――――――――――――――――――――――――――――――――
3. Squad → Folder of men for duration of life (that’s all there is to it), and is autonomous AI (done by AI engineers/designers). Split because this is not covered in the seminar, the top bits are covered however.

1270Problems with the Imperative method…look at those connections!

Encounter Logic

Several options…

Imperative method

  • Allows designers to have a FSM construction tool
  • Gets complicated fast!
    • eg; That for 3 encounters, it becomes n² complexity!

Declarative method

  • Sims-like
  • Give list of tasks, let system decide what to do.
    • Have structure
    • Reactive priorities – guard A, but B if possible
    • Subtasks – Guard B has 3 parts to guard (as noted previously; initial position, fallback 1/2/3…, final fallback

Behaviour trees are used for the individual AI

  • Choose one at each level, go deeper if chosen
  • Prioritised list

Maybe use task trees? – like the individual AI, use a hierarchical tree?
(check slides for example, pro/cons)

The tool

1280Squad distribution calculation, pretty simple and common sense.

Task logic

Make a decision for 24 guys between 3 equally important objectives – so 8 per generator, and 4 per sub location at objective given there are 2 locations at each generator.

Tasks have:

  • Priority
  • Activation script fragments
  • Capacities (to not fill a tiny room!)

Dynamic plInfo machine!

The UI is a hierarchy.


  • Determine what is active in subtree (some things deactivate on certain conditions)
  • Consider inactive ones to reassign (ones which are now inactive but still have squads assigned to the task)
  • Distribute (equally or not) squads
    • List of squads and list of tasks to go together is the NP-hard bin packing algorithm
    • Lots of info however
    • We can live with sub optimal
    • We also optimise by cost function, also we’re not literally using bins. Squads instead (ie; they cannot be “split up” and squads don’t need fitting in a box), so don’t worry.
  • Cost function weights:
    • Not travel far – Minimise maximum travel distance (2 squads going to 2 locations, don’t just “get nearest squad”)
    • Want to act co-ordinated
    • Balance the tree (of tasks)
    • Get near the player
1285A greedy approach to the situation.

Use a greedy approach to work out the cost function H(s, t) (s = squads, t = tasks).

The performance is O(n²m) but n + m are small, and other performance measures are taken too:

  • Cache H(s, t) results (this causes the biggest amount of processing)
  • Timeslice entire trees
  • Timeslice nodes within trees


Filters on tasks:

  • eg: Sniper only, must (not) be in vehicles, etc.
  • Not a script, but should be!
  • Occupation conditions, not activation conditions
  • Good for the spice

To turn off or pick a task (which is all designer stuff!):

  • Latch on/off (depending on other things)
  • exhaustion of the task – death + living count (for Halo, death is a huge condition, and frequently used)
  • One-time agreement

Case studies: Leaders

  • Leaders + followers
  • Leader provides structure to encounters
  • Leader death “breaks” followers – should make them easier to kill

Two parts to leaders:

  • Leadership-based filters
    • Core task: Leader filter (something only a leader can perform – perhaps a specific position to be in)
    • Peripheral task: “No leader” filter (something only grunts can perform, don’t get the leader doing it!)
  • Broken state (ie; when the squad becomes broken)
    • Cannot redistrubute into other tasks (so stays near current position or doing current activity)
    • NPC’s have own behaviour when broken (charging in a final attack, fleeing, grouping together…)

“Picking up the human” behaviour (in a warthog or whatever) – only one task per encounter – at a high priority. This is when they drive up, and shout “get in”, or get out for the player.

  • Vehicle filter
  • player_needs_vehicle() – this required a lot of tweaking
  • Following player task option
  • Driver player_pickup() behaviour

Badness/Cons with the tool

  • Designer training – not super intuitive
  • Awkward relationship between scripting and objectives – had to use a control variable (set in an ongoing script)
  • tying together allied and enemy “fronts” was complicated – tough to co-ordinate between them
  • Squad level was not the best bucket modifier
    • Sniper rifle members in a human squad cannot snipe (despite being given a sniper rifle – the condition is “everyone has a sniper rifle”)
    • Useful to split squads, but this is currently impossible within the system

And there was no real time for questions (or at least I noted no answers down), so that’s it 🙂 For me, these were a good compliment to the slides (since the slides do a good job actually!), so I hope they’re useful to someone else too.

2 thoughts on “GDC08 Notes – Building a Better Battle: HALO 3 AI Objectives”

  1. Once again, nice notes for someone that didn’t get a chance to go to GDC this year to get a decent feel for a small fraction of what was talked about…

    Just one quick nitpick, right now I’m having a hard time getting the image of couches deciding football plays… I’m guessing they’d be better at it than loveseats, at least.

Comments are closed.