Navigation: Overview >> Working Group on Steering

Working Group on Steering

AI game developers, game AI middleware producers, and interested academics form the AI Interface Standards Committee's (AIISC) working group on steering. One of the eight members holds the position of a coordinator, coordinating the groups' discussions and work. Dave C. Pottinger was the first coordinator, but due to time constraints, handed the job over to the current coordinator, Thaddaeus Frogley.

While no final interface has been decided on, the group had very productive periods besides GDC'03, this years' E3, and many job related deadlines of the members, and produced far over 200 discussion contributions. To focus discussion, examples how to apply steering techniques in games were often used. Papers of Marcin Chady and Craig W. Reynolds provided a starting point how steering systems could be architected and helped to develop a common vocabulary. Missing a precise vocabulary can lead to confusion which has been experienced in some arguments, oftentimes ending in the discovery that the different parties talked about the same thing.

Goals for a Steering Interface Standard

The goal of the steering group of the AI Interface Standards Committee (AIISC) is to define a standard interface to ease the integration of a games AI with a steering system. A steering system is a system that proposes movements for agents based on their local surrounding, i.e., using the information about the world delivered by their senses. Therefore, concrete but programming language neutral interfaces will be defined.

First, the steering group has defined what is and what isn't steering, and building upon this, identified the main abstractions and concepts needed to analyze and structure the process of steering an agent inhabiting a games world. This process was guided by different examples, e.g., a scenario similar to "capture the flag".

What is Steering? What isn't Steering?

A steering system controls and implements agent movement, paying attention to multiple goals like not to bump into walls and other agents, while pursuing or evading specific agents, or trying to stay inside a group. It is used for:

Steering is reactive and non-deliberative, and based on the local environment surrounding every single controlled steered entity. It needs to cope and interact with static and dynamic game world objects in an agent's perceived neighborhood.

Steering has nothing to do with:

A steering system cannot be expected to navigate a maze. That is the job of a pathfinder (handled by the working group on pathfinding). Once such a pathfinder/maze-solver outside of the steering system has laid out a path through the maze, the agent's steering system can produce natural-looking motion along this path.

Abstract Concepts and Components of a Steering System

Problems to solve defining a steering system to use in games are:

Different examples were examined, like the already mentioned "capture the flag", where one agent tries to reach the flag while avoiding obstacles and its hunters. The hunting or enemy agents pursue the flag-seeker while avoiding collisions with other hunters and obstacles. The scenario represented only a small part of "capture the flag" but was and is very helpful in thinking about steering.

These examples gave an impression of the steering task's complexity and the need to make it simple to combine steering with other AI techniques, which is an important issue to keep in mind for potential standards.

The way chosen to solve these requirements was to create the steering interface as a "grey box", not a black box. The interface user - the game AI developer - should be able to change and adapt a system conforming to the interface standards to his individual needs while using an established steering foundation that is structured in a way to keep the interface as simple as possible. To meet these needs, the (steering) data to work on is standardized - not the algorithms that use it.

The steering interface standard will define a toolkit of steering-related objects that are glued together through custom code written by the interface user to meet his/her projects needs. This simplifies the task of specifying the interface by putting some burden on the end user but won't impede what game developers want to do.

AIISC steering system overview

Analyzing the steering domain, the following concepts and components describing a steered agent have been identified:

Game world interface
Enables an agent to sense its local environment, e.g., for preventing collisions or for retrieving information about the direction that another agent is facing in to approach it from behind.
Steering behaviors
They are reacting to the surrounding scene provided by the world interface by generating steering goals. Which steering behaviors to use is decided by the game developer. He can also provide his own behaviors. At run-time, the arbitrator dynamically manages the steering behaviors provided by the developer.
Arbitrators
An arbitrator integrates and combines the steering goals produced by the steering behaviors to create the final steering goal intended for the actuator of the agent. The interface user determines which, when and how to use steering behaviors and their outputs by providing his own agent steering arbitrator(s).
Internal information currency
The representation of the steering goals generated by the steering behaviors and the arbitrators. Arbitrators and actuators receive and work on steering goals.
Actuators
Actuators convert a final steering goal into whatever is needed to propose agent movement to the game.

Steering behaviors react to continuous changes of the environment. Furthermore, the whole steering system of an agent can be controlled by the game logic, e.g., through dynamically changing the used steering behaviors, arbitrator(s) and the actuator, or by modifying the states of the different components of an agents steering system.


World Interface

Changes in the world state are propagated via the world interface to the steering system. Every steered agent and its different steering behaviors perceive (agent and steering behavior) relevant entities in their local neighborhood. A representation of the world is needed that allows defining agents, their properties and the entities building the environment. Especially the detection of collisions or of the possibility of collisions must be provided by the world interface.

Typically, agents hold information about their bounding volume, position, mass, linear and angular velocities, linear and angular accelerations, etc. The world is represented through geometric primitives like circular or spherical bounds, convex hulls, lines, or planes. This set of primitives should be extendable by user provided primitives. Other agents and groups of them, obstacles, walls, vector flow fields, paths, and so on, could influence an agent's steering.

Collision detection and testing interface is needed, for example, to find nearby objects or objects that lie on a ray between two points, or to get the time of a potential collision if an agent is moving further in its current direction. This interface - a hot working group discussion topic - might be provided by the AIISC world interfacing group. What to do with this information is decided by the steering behaviors.

Steering Behaviors

Steering behaviors are the key elements of a steering system. Typical behaviors are:

Combined steering behaviors are for example leader following, queuing and flocking.

They might be fed with the data of the agent they are belonging to and information about their surrounding environment, or they might query the world interface by themselves to get the data needed to do their job. In only working on their local world data, steering behaviors are kind of "myopic".

By choosing the right set of steering behaviors, a game developer might be able to achieve an emergent system behavior that helps to avoid situations that need backtracking or planning otherwise and would need to be solved by game components other than the steering system.

Based on their sensed world neighborhood and their agent's state, steering behaviors produce "steering goals" consumed by arbitrators. Steering goals generated by behaviors can potentially also be used as input or hints for other steering behaviors. Steering goals express a behavior-specific recommendation how to move or change the movement of an agent.

Arbitrators

Arbitrators take the steering goals generated by the steering behaviors they are connected to, handle conflicting steering goals and integrate them into the "final steering goal" dedicated to the agent's actuator.

Because establishing a complex "doing-everything-ever-needed-for-arbitration" solution doesn't seem feasible, the interface user should be able to plug in his own arbitrator using a combination of a variety of provided or self-written arbitration strategies. Plug-ins allow for different arbitration for different steering problems or for different arbitration inside one single steering problem.

Typical approaches of arbitration include:

or more complicated game-specific mechanisms.

The AIISC steering interface standardizes arbitration methods not by standardizing mechanisms but by providing prototypes for integrators/arbitrators, standardizing not the code itself but the data - steering goals - over which arbitration may work.

Internal Information Currency

Steering behaviors, arbitrators and actuators communicate via steering goals - the internal information currency of the steering system. Steering goals encode agent movement or movement-changes as recommended by the generating behaviors or arbitrators. Their value type should be standardized and might be a vector-pair with a mechanism to mark a vector as unnecessary, so arbitration or the actuator won't care about it.

The decision to have a steering goal hold two vectors is mainly backed up by two vectors being a super-set of just one, performance-optimization reasons, and the need to specify the direction of motion separately from the view direction of an agent in a 3D world. The vectors building a steering goal can also be seen as values defining the linear and angular velocity by which the producing steering behavior wants the associated agent to move with.

However, until now no real consensus concerning the steering goal vector semantics has been reached.

Actuators

Standardized and user implemented components of an AIISC steering system.

The actuator of an agent takes the final steering goal delivered by an arbitrator. Steering goals are a steering-system specific definition of movement that needn't conform directly with the game-logic way of expressing entity or agent motion. Therefore, the final steering goal is converted into a proposal for the game how the agent should move, e.g., through linear and angular accelerations. It is up to the game to decide what to do with the actuators output.

To allow for direct interfacing with the application and to create whatever is needed by the game-logic coordinating the movement, e.g., a physical simulation component, it is the game AI programmer who provides the actuator and its interfacing with the non-steering systems of the game. The actuator offers a user defined agent- or game-specific meaning to the final steering goal.

Possible outputs of the actuator might be: forces, impulses, velocities, accelerations, displacement vectors or direct movement, that meet the games needs.


State of Work

Currently, the group is in a phase of brainstorming, collecting and discussing high-level concepts. Nothing is implementation-specific or set in stone yet. Terms like "steering behavior" or "actuator" are just concepts and no classes or objects of a programming language.

The litmus test of every steering interface will be test case implementations and its use in real projects.

Group Members

Current members of the working group on steering:

Resource(s)

Navigation: Overview >> Working Group on Steering