Halo 3

From AIGPG Wiki
Revision as of 14:33, 6 August 2011 by Dave Mark (Talk | contribs)
Jump to: navigation, search

Halo 3
Developer: Bungie
Publisher: Microsoft Game Studios
Year: 2007
Platforms: X360
Genre: FPS
AI Era: Tactical Reasoning

Halo 3 is a first-person shooter game taking the player on a series of missions that engage in combat against various forms of alien life.


Description of AI Behavior

The enemy agents in Halo 3 exhibited typical shooter game behaviors including moving, shooting, using cover, etc. Additionally, they acted in small tactical groups inside the scope of a battle and the battle as a whole exhibited large-scale coordination of all the units so that large team-based goals were accomplished.

Notable Behaviors

The large-scale battle management was a hallmark of the Halo 3 AI. By approaching the entire encounter as a system that can be managed, the perceived result of battles was that all the enemies were working together toward a common goal such as coordinating the defense of a key target.


Declarative Logic

This section is based on
first-hand knowledge
by AIGPG member,
Damián Isla.
What does this mean?

Halo 2 used hand-designed imperative logic for the behaviors of the agents. That is, designers specified hard rules that the agents followed. The problem with this was that the complexity didn't scale to the levels desired for the design of Halo 3. Instead, Halo 3 utilized declarative logic.

The underlying approach to this is similar to what is used in games such as The Sims where objects have "affordances" that can be measured and rated.

Encounter Zones

This section is based on
first-hand knowledge
by AIGPG member,
Damián Isla.
What does this mean?

The battle management system in Halo 3 utilizes designer-placed zones where the activity takes place. This approach is likened to the "choreography" of the encounter.

The encounter zones are, in effect, a strategic layer only. Once in the zone, the behavior of each agent is autonomous and, therefore, defined by the agent itself (subject to parameters of the zone).

Designer-placed zones in Halo 3
Designer-placed zones in Halo 3

As criteria of the zones are met, they change so that the location of the "choreographed" activity changes. For example, a zone could be set up that once the enemy loses a certain number of units, they would fall back to a 2nd zone. If they lose more units, they could be set to fall back again. The result is that it appears that the player is pushing the enemy back to successive strategic locations.

In addition to the territory for each zone, the designer can specify the rules that are in effect for the zone. This includes:

  • The aggressiveness of the unit
  • The rules of engagement
  • Whether the enemies will follow the player

Task Trees

This section is based on
first-hand knowledge
by AIGPG member,
Damián Isla.
What does this mean?

Instead of specifying details of "who should do what and when", the designers were able to simply enumerate the tasks that needed doing as part of the mission (usually attached to the encounter zones above) and the system would figure who should do them. Tasks are given relative priorities. For example, a "plain language" version of this would read:

“The most important thing is to guard the door, but if you can, also guard the hallway”

This could simply be accomplished by setting the values of guarding the door to a numerical priority higher than that of the guarding the hallway. Note that the priorities here are not for the individual actors but for the encounter as a whole.

Tasks can also have sub-tasks. This would read:

“Guarding the hallway means guarding the front, the middle and the rear of the hallway.”
A tree of tasks
A tree of tasks

While the structure of tasks and sub-tasks may look similar to the structure of a behavior tree, there is a significant difference. While a behavior tree is generally trying to parse out the single action to take at a given time, the task tree is attempting to intelligently distribute enemies across all of the possible tasks.

The tasks are self-describing given:

  • a priority,
  • a script fragments specified by the designer to determine when the task is activated,
  • a capacity for the task that is used for assigning the resources.

The approach for distributing the tasks is to "pour the squads into the top of the tree" and allow them to filter down to the most important tasks that need to be filled right now. As tasks are enabled and disabled, squads can be reassigned throughout the tree. For example, if a higher priority task is enabled, squads will be "pulled up" from lower priority tasks until the higher priority task is filled.

Squad Distribution

This section is based on
first-hand knowledge
by AIGPG member,
Damián Isla.
What does this mean?

The distribution of squads across the task tree follows the following procedure:

  • Consider a sub-tree fragment
  • Determine which tasks are active (using the script fragments)
    • Any squads assigned to a deactivated task are reassigned up to the parent
  • Divide tasks into groups of equal priority
  • Consider the group with the top priority
  • Collect squads from:
    • The parent
    • Tasks with lower priority than the current group
  • Distribute squads across tasks in the priority group
    • Recurse down the tree so that tasks that are parent tasks can distribute their squads accordingly
  • Move to the next lower priority group and repeat until there are no more tasks at that level

The mapping of squads to tasks needs to respect two factors:

  • Respect the capacity constraint of the task
  • Minimize the cost function for the task

The capacity restraints are slightly more complicated than simply (proposed < maximum) because agents are being assigned by squad rather than individually. Squads may be different sizes at any given time based on initial size and losses within the squad. This approach is solved using a classic bin packing approach but with tolerances for sub-optimal results. One reason for this is that the focus is on the cost function rather than the optimal arrangement of squads.

Coordinating movement
Coordinating movement

The cost function helps to determine which distribution of squads to tasks is the most preferable. It takes into account the following preferences:

  • Minimize travel distance per squad
  • Act in a coordinated fashion with other squads
  • Balance the task tree
  • Get near to the player

While iterating through all the possible squad-to-task mappings was potentially expensive (O(n2m)), it was manageable due to the small numbers of squads and tasks. Regardless, they made a point to cache the costs of actions since that was the most expensive portion of the process. Additionally, the entire tree was time-sliced. Considering that there were numerous trees processing for different types of enemies, they would restrict that only certain trees were being processed at certain times.

Filters were added to restrict types of agents were available to be assigned to a task. These included the type of characters, status of characters (in or out of vehicles), etc. This was done by returning an infinite value from the cost function so that the agent would not be considered for that task.

Behavior Trees

This section
needs input
from an AIGPG member.
What does this mean?

Individual agent actions are performed by behavior trees as they were in Halo 2.


What Worked

Declarative Approach

The declarative approach in the strategic system allowed for more flexibility than the traditional imperative approach. Additionally, it required less direct control of agents. Designers could set concepts rather than individual behaviors.


The hierarchical nature of the strategic system allowed for more modularity and scalability. Because of the modular nature of the task system, the O(n2) complexity of a rule-based system was avoided. Instead, the system was simply O(n).

Designer Tools

Because of the way the system was organized, it allowed for creation of designer tools to streamline the production of the encounters. It was flexible enough to incorporate many of the designers' desired features.

What Didn't Work

Designer Training

Because of the complexity of the designer authoring tools, designers needed to be trained on the use of the tool, the terminology, and the logical progression of how the canonical system worked.

Scripting vs. Objectives

There were sometimes awkward relationships between the scripting system and the objectives-based system.


There were sometimes difficulties in "tying together" allied and enemy fronts so that battles seemed properly "aligned".

Squad Bucketing

There were situations where the squad level wasn't the best arrangement of resources. For example, if you gave a sniper rifle to someone, he was still a member of the parent squad rather than occupying the "sniper" task.

Lessons Learned

This section
needs input
from an AIGPG member.
What does this mean?

Reception by Public



  1. Building A Better Battle: The Halo 3 AI Objectives System (slides), Damián Isla, GDC, 2008
  2. Building A Better Battle: The Halo 3 AI Objectives System (video), Damián Isla, GDC, 2008

External Links


Personal tools