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.
- 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
- 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
- In Halo: Territory
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.
- Allows designers to have a FSM construction tool
- Gets complicated fast!
- eg; That for 3 encounters, it becomes n² complexity!
- 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)
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.
- 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
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.