Navigation: Overview >> Working Group on World Interfacing

Working Group on World Interfacing

AI Developers and Middleware vendors from the Game and Simulation Industries together comprise the AI Interface Standards Committee's (AIISC) world interfacing group. We are the central hub, coordinating ourselves with all other AIISC groups to create a standard interface between game AI systems, for example the other AIISC group implementations, and the game world representation / game engine.

Ian Wilson took over the coordinator role from Christopher Reed due to his time constraints this year and is now organizing the group's work and moderates its forum discussions.

The world interfacing group has the most active discussions with close to 1000 forum postings to date. In the past year our discussions moved from building up background knowledge about the many issues involved to beginning to put the points agreed on into a concrete form. To this end we are adopting the standard software development process of creating a set of Requirements with associated Specifications which we will use to create our final interface design. At this stage, the Requirements have been completed and we have created a number of sub-groups to create the Specifications for each of these Requirements. This work is currently ongoing.

While comparing this years report to last years it may seem on the surface that progress has not been fast in fact much progress was made in determining our set of requirements. This process forced us to define exactly what we were going to produce and perhaps just as importantly what we were not going to produce. We now have a clear set of constraints on where we are headed and also a generally much clearer picture of what our interface will look like. This coming year could well see all of our discussions become concrete.

Our overall schedule is to have the Specifications completed by September 2004, the high and low-level Designs completed by December 2004 and an example use case written up by GDC 2005. This may be ambitious given the groups precious time resources but it is a worthwhile goal for us to aim for.

Goals (Requirements)

We would like to define an Application Programming Interface for AI Components that:

  1. Supports a large variety of Game World data
    1. Provides a set of standard data types
    2. Supports easily adding new data types
  2. Supports a large variety of Game Engine architectures and designs
  3. Supports data transfer between AI and the Game World
    1. Supports AI receiving event data from the Game World
    2. Supports AI making available event data to the Game World
    3. Allows for the future implementation of AI requesting data from Game World
    4. Allows for the future implementation of AI sending data to Game World
  4. Supports the API requirements of all groups in the Committee
    1. Supports the "Rule-based Systems" group
    2. Supports the "Pathfinding" group
    3. Supports the "Steering" group
    4. Supports the "Goal-oriented Action Planning" group
    5. Supports the "Finite State Machines" group
  5. Supports all committee wide agreed upon formats
    1. Provides documentation in format readable by a web browser
    2. Provides a High-Level Specification document of the API
    3. Provides a Low-Level Specification document of the API
  6. Supports the adoption and use of AI within the games industry
    1. Supports the reuse of API code, allowing developers to avoid "reinventing the wheel" with each product.
    2. Supports reduced development cycles, allowing developers to use existing solutions with greater productivity and familiarity.
    3. Supports the development of more robust Games, allowing heavily tested and well designed interfaces to be used easily.
    4. Supports the development of 3rd party (or shared) AI authoring tools, allowing developers to focus on game content with an externalized tool.
    5. Provides a set of standard terminology that can be adopted by the Game Industry, allowing better communication and common understanding between development studios for higher productivity.

Terminology

This list is intended to define those terms used within the Game / Interactive Entertainment industries to describe components of Artificial Intelligence systems and the Game Systems that are connected or related to those components.

Terminology

[AI]
[ACTION]
[ACTUATOR]
[AGENT]
[AI SIMULATION]
[COMPUTER GAME]
[CONTROLLER]
[GAME ENGINE]
[ENGINE SYSTEMS]
[ENTITY]
[EVENT]
[FINITE STATE MACHINE]
[GAME SYSTEMS]
[GOAL PLANNING]
[INTERFACE]
[OBJECT]
[OBJECTIVE]
[PATH PLANNING]
[PLAYER]
[RULE-BASED SYSTEMS]
[SENSE]
[SENSOR]
[SIMULATED ENVIRONMENT]
[SOFTWARE SYSTEM]
[STEERING]
[STIMULUS]
[TERRAIN]
[QUERY]
[WORLD]
[WORLD INTERFACE]

As you can see we have yet to fill in the actual definitions for these terms and that is something that we should complete soon with the assistance of the AIISC support team who are compiling a master list of terms.

Concepts

There are a number of potential approaches to designing a World Interface, but bearing in mind the practical realities of game development and that we are designing a general-purpose interface, we are currently moving forward with the following approach:

There is no world

Central to our current design initiative is the principle that our interface specifies only the AI side of the interface. No assumptions are made about the game world or engine. There are many different game architectures and it was decided that attempting to impose a standard on the game engine may prove too difficult initially. By defining only the AI side of the interface, essentially how to pass data to and get data from the AI sub-systems, control is placed in the hands of the developer as to how that fits in with their architecture. However we leave open the possibility of defining both sides of the interface at some future point in time. So in the words of our final discussion post/proclamation;

  1. Whereas, it is critically important that any standard interface be applicable to all GAME ENGINES; and
  2. Whereas, GAME ENGINES should have total control over when and how to execute SENSOR and ACTUATOR requests to optimize performance and compatibility with GAME ENGINE architecture; and
  3. Whereas, the mechanism for interacting with the GAME ENGINE must be highly generic and expandable; and
  4. Whereas, the goals and objectives of this group need to be narrowed and tightened if we wish to make any progress in the short term;

Therefore be it resolved, that the first version of the World Interface Standard shall be entirely composed of passive SENSOR and ACTUATOR requests, forming a one-sided API where all function calls are defined AI components only. A two-sided API including functions defined on GAME ENGINE components and featuring a QUERY mechanism may be included in a future version of the World Interface Standard.

This makes the interface a passive one, receiving data and allowing data to be taken from it. It does not query the world itself or push data back to the world, which would require knowledge of the world and hence a definition of how the world was structured. While it is understood that many developers use query systems it was also felt that moving to an event-based architecture fulfilled our objectives (and the objectives of game developers) in a much more elegant, simple and powerful design.

API Input

This part of our design then has changed from last year where we had events and queries. We now have only events. In terms of inputs we are looking at the following question (and have separated our group into sub-groups to deal with these items):

    Requirement #1 [Data Types]
    This group will investigate what data types we want to support for transferring back and forth
    between AI and the game world.

    Requirement #2 [Architecture]
    This group will investigate the syntactical specifics of the interface, examine the pros and
    cons of a rigid component modeling approach as opposed to a simple class structure, XML Schema,
    GUI-Like approach, etc...

    Requirement #3 [Data Transfer]
    Working closely with group 2, this group will investigate the specific implementation of sending
    and receiving the data types that group 1 is putting together. How does AI make requests? What 
    kinds of data remain persistent, how does an event get fired, etc...

    Requirement #4 [Other Working Groups]
    This group will be responsible for spending some time in each of the other groups forums, discussing
    our plans as they progress with those groups and evaluating how their needs are being met.

While this work is in its preliminary stages we do have some examples of the current, non final, stages of the specifications (see later).

API Output

Again this has changed somewhat from last years report in that our interface is now a passive one that does not push data but instead allows it to be retrieved perhaps by direct calling or through the use of callback type methods. The groups mentioned in the section above will, of course, investigate both the receiving and posting of data (currently often termed subscribing and publishing in Event-based Architectures). While many people familiar with event systems will wonder about an event management system or “broker” it should be noted that to date we have only discussed this in passing and have no current plan to include such a system in the interface.

High-Level Representations

Event Data

Though still at an early stage of discussion the following is an idea proposed for the high-level structure of events. Central to this theme is that all events have a “header” and a “body” whereby the header contains mainly static information about the event which can be processed or routed quickly. Here the interface is passed events and generates events. Conceptually then the information coming to and going from the interface is in the same general format.

<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE GameAI SYSTEM "gameAI.dtd">

<EventHead>
    <EventID> Integer </EventID>
    <EventName> String </EventName>
    <EventCatagory> String </EventCatagory>
    <EventType> String </EventType>
    <EventVersion> Integer </EventVersion>
    <EventTime> Time </EventTime>
    <EventSynch> Bool </EventSynch>
    <PublisherID> Integer </PublisherID>
    <PublisherName> String </PublisherName>
    <SubscriberID> Integer </SubscriberID>
    <SubscriberName> String </SubscriberName>
<EventHead>

<EventBody>
    <Element>
        <Attribute>
            <Value> </Value>
        </Attribute>
    </Element>

.... etc

</EventBody>

Passing these common headers allows us to construct a common language between components while allowing flexibility in the way the data is actually packaged. The XML view above gives a nice conceptual view of this. Here are descriptions of the header elements:

<EventID> An integer ID for the event, each event having a potentially unique ID
<EventName> A string to name the event, i.e. "EnergyPillConsumed"
<EventCatagory> A string to describe the catagory of the event, i.e. "Pacman"
<EventType> A string to describe the type of event, i.e "EnergyPill"
<EventVersion> An Integer to note the version number of this type of event or publishing module
<EventTime> The time the event was created
<EventSynch> If the event is synchronius or asynchronius [[, this needs more explanation - Tom?]]
<PublisherID> An integer ID for the event publishing (creating) module
<PublisherName> An string ID for the event publishing (creating) module
<SubscriberID> An integer ID for the event subscribing (receiving) modules
<SubscriberName> An string ID for the event subscribing (receiving) modules

Standard Data Types

Following from this suggestion we will look at the formats to use for the body of the event / data. This is where we will need to coordinate with the other AIISC groups to determine those formats that are commonly in use in those areas. We will be looking at these themes:

While it will of course be necessary and important to allow the developers to create their own data that conforms to our interface standard we would also like to supply them with a number of ready made and regularly used data types to ease adoption and speed usage of out interface.

Low-Level Representations

With respect to the high-level XML representation of data type formats above we have also created a similar example in a C++ format to show how it could look in a low-level language.

Event Data 

////////////////////////////////////////////////////////////////////////////////////////////////////////////
// Event.h
//
// C++ Event data type.
////////////////////////////////////////////////////////////////////////////////////////////////////////////
struct SEvent
{
    // EventHead
    int EventID;
    char* EventName;
    char* EventCatagory;
    char* EventType;
    int EventVersion;
    time EventTime;
    bool EventSynch;
    int PublisherID;
    char* PublisherName;
    int SubscriberID;
    char* SubscriberName;
    // EventBody
    ...... Required Data Format
};

Using our selected game example “Pacman” here is how a concrete example of the data format described might be used with the header information allowing for routing to specified AI modules behind the interface. Again, this is a preliminary suggestion;

Event.EventID = LastEventID + 1;
Event.EventName = "NewLocation";
Event.EventCatagory = "PinkGhost";
Event.EventType = "Movement";
Event.EventVersion = 110023;
Event.EventTime = 2456978; // Perhaps seconds
Event.EventSynch = SYNCH; // SYNCH / ASYNCH
Event.PublisherID = 10001;
Event.PublisherName = "GhostMovement";
Event.SubscriberID = 11001;
Event.SubscriberName= "PacmanPathPlan";
// EventBody
Event.NewLocation = Vector( x, y, z );
Event.Velocity = 102;
.... etc

Architecture

We also have a current suggestion for the low-level architecture of the interface using a “COM” like approach to handling non-specific and user-defined data being sent to and taken from the interface. Here is an example of how our interface file might look using a COM syntax:

////////////////////////////////////////////////////////////////////////////////////////////////////////////
// IController.h
//
// C++ Controller Interface and related data types.
////////////////////////////////////////////////////////////////////////////////////////////////////////////
struct SAction
{
    // TO BE FILLED IN BY GROUP #1
    // FOR EXMAPLE:
    float mStartTime;
    float mStopTime;
};

struct SSensor
{
    // TO BE FILLED IN BY GROUP #1
    // FOR EXAMPLE:
    float mStartTime;
    float mStopTime;
};

struct SEvent
{
    // TO BE FILLED IN BY GROUP #1 see above for example
};

interface IController : public IUnknown
{
    // TO BE FILLED IN BY GROUP #3
    // FOR EXAMPLE:
    virtual void Event (SEvent& event)=0;
    virtual int ActionRequestCount ()=0;
    virtual SAction& ActionRequest (int index)=0;
    virtual int SensorRequestCount ()=0;
    virtual SSensor& SensorRequest (int index)=0;
};

Bearing in mind how we have defined an event as containing any type of data, it could be that we class all incoming and outgoing data as events. However this is essentially a semantic description and depends on what developers are most comfortable with (i.e. Event, Action, Sensor as in the example above).

Group Members

Current members of the working group on world interfacing:

Requirements Sub-Group Members

Navigation: Overview >> Working Group on World Interfacing