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

“Task”

• 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.

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

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.

Algorithm

• 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

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

Refining

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.