Halo 3 Objective Trees: A Declarative Approach to Multiagent Coordination

1. Halo 3 Objective Trees: A Declarative Approach to Multiagent Coordination Damián Isla Bungie Studios

2. Expectation Management • Objective Trees are a scripting method • The Declarative Approach is an authoring paradigm

3. Agenda • Encounter Design • Halo 2: Imperative Method • Halo 3: Declarative Method • Results and Conclusions

4. Encounter Design

6. Encounter Design • Encounters are Multiagent Systems • lots of guys • lots of things to do • Encounters are Puzzles • Encounters are Dynamic • they collapse in interesting and fun ways Encounters reflect • the strategic intelligence of the characters • the “story” of the encounter

7. Encounter Design Designer provides the strategic intelligence AI acts smart within the confines of the plan provided by the designer

8. Player Approach

9. Player Approach

10. “Task”

11. Task The Mission Designers’ language for telling the AI what to do • Territory • Behavior • aggressiveness • rules of engagement • inhibitions Encounter logic = The transitioning of AI squads from one task to another

16. The Control Stack Encounter Logic Task Mission designers Squad AI engineers, AI designers Individual

17. Halo 2: The Imperative Method

18. The Imperative Method Give the designers an FSM construction tool < 25% alive? < 75% alive?

19. Problems with the Imperative Method

20. Problems with the Imperative Method Generator 1 Explicit transitions  n2 complexity Generator 3 Generator 2

21. Halo 3: The Declarative Method

22. But first, here’s a refresher

23. Imperative const char *lol_search(const char *buff, long len) { for (short i= 0; i < len-2; i++) { if (buff[i]==‘L’ && buff[i+1]=‘O’) { short i2=i+2; while (i2<len-1 && buff[i2]=‘O’) { i2++; } if (buff[i2]==‘L’) { return &buff[i]; // yes!!! } } } return NULL; }

24. Declarative LO+L

25. The Declarative Method For us: Enumerate “tasks that need doing” in the environment Let the system figure out who should perform them

26. The Declarative Method Similar to “affordances”

27. The Declarative Method Tasks have structure • Relative priorities • “The most important thing is to guard the door, but if you can, also guard the hallway” • Are made up of sub-tasks • “Guarding the hallway means guarding the front, the middle and the rear of the hallway.” • Finite capacity • “Guarding the rear of the hallway is a three-man job”

28. Behavior Trees hide cover (Handling Complexity in the Halo 2 AI, GDC 2005) Takeaways: • Prioritized-list decision scheme • Behaviors are self-describing grenade fight melee shoot root uncover search pursue idle sleep We are not making a single choice. We are finding a distribution across all choices.

29. Task Trees? Generator 1 Generator 3 Generator 2

30. Task Trees? 8 8 8 0 0 0 generator 1 8 0 0 0 forward forward forward root generator 2 fallback fallback fallback 8 laststand laststand laststand 24 guys generator 3 8

31. Halo 3 AI Objective Trees The structure: • A Tree of Prioritized Tasks • Tasks are self-describing • priority • activation script-fragments • capacities The Algorithm: • Pour squads in at the top • Allow them to filter down to the most important tasks to be filling RIGHT NOW Basically, it’s a plinko machine.

32. The Dynamic Plinko Machine • Tasks turn themselves on and off • Squads pulled UP, on activation of a higher-priority task • Squads pushed DOWN, on deactivation of the task they’re in

33. 3 GeneratorsRevisited root root g1_group g1_group g1 alive g1 alive max 10 max 10 g1 laststand g1 fallback g1 fallback >50% >50% g1 forward g1 forward >75% >75% g2_group g2_group g2 alive g2 alive max 10 max 10 g2 laststand g2 laststand g2 fallback g2 fallback >50% >50% g3_group g2 forward g2 forward >75% >75% g3_group g3 alive g3 alive max10 max10 g3 fallback g3 fallback >50% >50% g3 laststand g3 forward >75% g1 laststand g3 forward >75% g3 laststand

34. task name other stuff priority condition runtime feedback

35. The Algorithm

36. The Algorithm • Consider a subtree fragment • Determine which children are active • Squads in inactive tasks assigned back up to parent • Consider top priority group • Collect squads to attempt to distribute • Squads currently in parent • Squads in lower-priority tasks • Distribute Squads • Recurse for children in top priority-group • Iterate to next “priority group”

37. Squad Distribution Formally, we have • set S of nsquads • set T of m tasks Now, find a mapping Such that: • Task-Capacity Constraints are respected • Cost function H(F) is minimized

38. Squad Distribution • Respect Task-Capacity Constraints # guys assigned to task t ≤ capacity(t) (BTW, this is called bin-packing. And it’s NP-Hard.) 8 12 15 8 5 1

39. Squad Distribution • Minimize cost function H(F)

40. Squad Distribution • Minimize cost function H(F) • H(F) gives us a basis for choosing one distribution over another • H(F) allows us to weigh competing concerns

41. Squad Distribution • Minimize cost function H(F) A class of cost functions: We use

42. A Greedy Approach while (S is not empty) find pair (s,t) that give the minimum H(s,t) for all S x T (where adding s to t would not exceed t’s capacity) if (s,t) assign(s, t) capacity(t) = capacity(t) - size(s) S = S – s else end

43. Refinements

44. Filters Particular tasks only available to particular kinds of guys E.g. • Must be of character type X • Must be in vehicles • Must NOT be in vehicles • Snipers “Filters” • Specify occupation conditions (as opposed to activation conditions) • “Trivially” implemented as an inf return value from H(s, t) • Helpful for the “spice”

45. Further Task Refinements Activation • Latch on • Latch off / exhaustion Exhaustion • Death count • Living count Assignment • One-time assignment

46. Case Studies

47. Case Study #1: Leadership Want to have leaders and followers • Brute and three grunts • Brute Chieftan and brute pack Gameplay • Leaders provide structure to encounter • Leader death “breaks” followers

48. Case Study #1: Leadership Two Parts: • Leadership-based filters • Core task: “leader” filter • Peripheral tasks: “NO leader” filter • Task “broken” state • Task does not allow redistribution in or out while broken • NPCs have “broken” behaviors

49. Case Study #2: Player pickup Vehicle encounters are not fun without a vehicle Gameplay • When the player needs a vehicle, allies go pick him up

50. Case Study #2: Player pickup Implementation: one dedicated player-pickup task per encounter Three parts: • vehicle filter • player_needs_vehicle() script function • driver player_pickup behavior And that’s it!