Working Group on Word Interfacing
Working Group on World Interfacing
The WSDL Document Structure
WSDL Ports
WSDL Messages
WSDL Types
WSDL Bindings
WSDL Example
WSDL Ports
Operation Types
One-Way Operation
Request-Response Operation
AI developers and middleware vendors from the game and simulation industries together comprise the AI Interface Standards Committee's (AIISC) world interfacing group. Our groups' mandate is to define 3 basic elements for interactions with the game's virtual world, which are:
- a) how AI systems acquire data from the game world ("Sensing"),
- b) how AI systems influence the game world ("Acting") and
- c) what format the data is sent and received in.
Ian Wilson (Emotion AI, Japan) has the coordinator role and is organizing the groups' work and moderates its forum discussions.
We welcomed two valuable new members to the group this year. Erwin Coumans from Sony Computer Entertainment Europe who brought with him a close connection to the Collada (http://www.collada.org) data format working group being spearheaded by Sony and Marty Poulin from Sony Computer Entertainment America. Both bring valuable insights to the group. Looking at how the Sony Collada effort has progressed (it is a data format initially aimed at standardizing model data formats and has cross industry support from major game developers to major content creation toolkit makers and hardware manufacturers) it is clear that having broad and formal industry support is key to making an initiative like our gain traction. This could inject much needed energy into our efforts and raise the profile of what we are doing as well as giving it further credibility.
While around 30% of the members of the AIISC are from middleware companies we also need to make a stronger connection at the corporate level with these companies to get their buy in and support for what we are doing. They are the key to the whole effort. While we are aimed at game developers the days of game developers building their own tools are numbered, it makes no sense in terms of cost, time, risk or innovation for most developers. For both developers and middleware vendors one of the major hurdles to adoption is integration with the game engine. This is where our efforts could be of greatest benefit to all parties by defining a standard interface that makes the evaluation and integration of any number of AI middleware essentially "plug and play".
Putting the above two aims together would necessitate game AI middleware vendors supporting our data format and API, and this is where wide industry support, greatly increases our chances of acceptance and creates momentum around the whole AIISC effort.
Following is an overview of our requirements and the major directions our group is taking.
World Interfacing Group - Goals (Requirements)We would like to define an Application Programming Interface for AI Components that:
- Supports a large variety of Game World data
- Provides a set of standard data types
- Supports easily adding new data types
- Supports a large variety of Game Engine architectures and designs
- Supports data transfer between AI and the Game World
- Supports AI receiving event data from the Game World
- Supports AI making available event data to the Game World
- Allows for the future implementation of AI requesting data from Game World
- Allows for the future implementation of AI sending data to Game World
- Supports the API requirements of all groups in the Committee
- Supports the "Rule-based Systems" group
- Supports the "Pathfinding" group
- Supports the "Steering" group
- Supports the "Goal-oriented Action Planning" group
- Supports the "Finite State Machines" group
- Supports all committee wide agreed upon formats
- Provides documentation in format readable by a web browser
- Provides a High Level Specification document of the API
- Provides a Low Level Specification document of the API
- Supports the adoption and use of AI within the games industry
- Supports the reuse of API code, allowing developers to avoid "reinventing the wheel" with each product.
- Supports reduced development cycles, allowing developers to use existing solutions with greater productivity and familiarity.
- Supports the development of more robust Games, allowing heavily tested and well designed interfaces to be used easily.
- Supports the development of 3rd party (or shared) AI authoring tools, allowing developers to focus on game content with an externalized tool.
- 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.
The game development industry is often focused on very low level features in order to squeeze every last drop of performance from a system, however there are a large and growing number of platforms for which games are now developed and as such it would be impossible for us to define a low level system that would be applicable to all platforms. To that end our design is at a higher level. This high level design can be used in its original format or adapted if necessary to specific platforms at a lower level of implementation. Our high level definition is done in two formats that represent the same design but show how it can be implemented in different languages. We have an XML based definition and a C++/Java type definition. These represent a general view of where development is currently and which direction it is taking in the future. It is illustrative rather than complete.
Our current specification has 4 central ideas that define the systems API, these are a) a single, standard, extensible data format is used for all data passing, b) passing data and function calls is transacted via a standard "web service" type methodology, c) receiving data is transacted via a standard "web service" type methodology and d) the game engine can discover from the World Interface which services/methods are available/supported and how they should be called.
While we define an XML type data format for data exchange because we are dealing with a "run time" system it is very probable that this format will be a binary format for faster processing.
The web service methodology is, in its most basic form, a simple standard method of sending and receiving synchronous and asynchronous data to and from an unspecified caller. This is exactly what we would like our interface to accomplish so that it does not require any knowledge of the game world or game engine ahead of time (which we cannot know) but can operate with any engine or world that use the described calling methods and data format. This is the primary aim of the World Interface. Wikipedia defines a web service like this (http://en.wikipedia.org/wiki/Web_service):
A web service is a collection of protocols and standards used for exchanging data between applications. Software applications written in various programming languages and running on various platforms can use web services to exchange data over computer networks like the Internet, in a manner similar to inter-process communication on a single computer. This interoperability (e.g., between Java and Python, or Windows and GNU Linux applications) is due to the use of open standards. ...
World Data FormatThe central theme of our data format is that we use a single data format in a standardized way to encompass all data, thus removing the need for a vast array of specific data types for a vast array of possible objects. For a standard system we could not possibly hope to define every possible data type that developers might use and so a standard type becomes essential.
All data fits into a conceptual "attribute/value" pair format at some level whether it is "temperature : 35", "price : 350" or "speed : 160" etc. Attributes can be nested in a hierarchy to group similar elements. Using an XML schema methodology this data format can grow or shrink depending on the requirements of the system, as long as it conforms to the schema. Defining the schema then is the main task of the group. Again, while we talk in XML terms this methodology is a design and as such independent of platform or language.
The general format of attribute/value pairs is simply this:
<attribute>
<value> </value>
</attribute>
An more concrete example, including a hierarchy, might look something like this (where “element” is the parent node) :
<elements>
<scenario>
<agents>
<agent id=”Akira”>
<mood> +23 </mood>
<energy> tired </energy>
</agent>
<agent id=”Yumiko”>
<mood> +44 </mood>
<energy> full </energy>
</agent>
</agents>
<objects>
<chair> wooden01 </chair>
<chair> leather01 </chair>
<table> steel03 </table>
</objects>
<location> Apartment 101 </location>
<time> 2135 </time>
</scenario>
</elements>
There are a number of model data exchange formats that have been defined to date and we will use these as a guide and if possible extend them so we can gain momentum from their community and adoption. So far these formats have not included other game elements such as events, object meta data (i.e. What an item is as opposed to how it is represented in the game world), relationships etc. These are the elements that, in addition to model data, are required by the AI sub systems. From a developers perspective they can create their own schema that conforms to the general format but is specific to their own content and is used and validated by their own team for in game data.
APIThe first version of the World Interface Standard will be entirely composed of passive SENSOR, CONTROLLER and ACTUATOR requests, forming a one-sided API where all function calls are defined AI components only. The controller component is an addition to the previous specification. These 3 terms are often used in game development (in a SENSE - CONTROL - ACT cycle) but simply mean the following:
A method for the Game Engine to pass world data to the World Interface (sensor)
A method for the Game Engine to call functions in the AI sub systems through the World Interface (controller).
A method for the Game Engine to receive data from the World Interface (actuator)
Note there is no method for the AI sub systems to call functions in the Game Engine.
This makes the interface a passive one, receiving data and allowing data to be taken from it. It does not query the world it self 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 o f game developers) in a much more elegant, simple and powerful design.
The "web service" methodology has a number of features but at its core it is also a simple system that defines 4 ways in which a "service" or more specifically an AI sub system can be accessed. These methods depend on whether data is to be returned and whether the call is synchronous or asynchronous (if the calling function is to wait for return data or if return data can follow later). This allows for important calls to wait for important data to return with and also allows non time sensitive calls to simply "drop off" data or trigger actions and then leave the AI system to process the data when it can. The definitions are as follows:
| Type | Definition |
| One-way | The operation can receive a message but will not return a response |
| Request-response | The operation can receive a request and will return a response |
| Solicit-response | The operation can send a request and will wait for a response |
| Notification | The operation can send a message but will not wait for a response |
Notice that "Request-response", which represents the World Interface making a request to the Game Engine is not supported. In essence "Notification" represents the "sensor" sending data to the interface to update the state model, "Solicit-response" represents the "controller" sending a control request and receiving an error response and One-way" represents the "actuator" by receiving data from the interface.
While the actual web service specification is aimed at, well, web services the methodology is equally well suited to any service based architecture (as our is) where details of one side of the interface are not known ahead of time (again, as ours is). Appendix A has a brief overview of the web service specification and full details are available at the W3C site (http://www.w3.org/2002/ws/) (http://www.oasis-open.org/committees/tc_cat.php?cat=ws).
API Service DiscoveryIn order to fully decouple our systems it is necessary to have in place a mechanism for the Game Engine to query the World Interface to find out what services (AI sub systems and their methods) are available to it and how they should be addressed. This is analogous to the web service UDDI spec (http://www.oasis-open.org/committees/uddi-spec/doc/tcspecs.htm). Again, see wikipedias definition here:
UDDI is an acronym for Universal Description, Discovery, and Integration - A platform-independent, XML-based registry for businesses worldwide to list themselves on the Internet. ...
UDDI is a one of the core Web Services standards. It is designed to be interrogated by SOAP messages and to provide access to WSDL documents describing the protocol bindings and message formats required to interact with the web services listed in its directory.
Obviously for our needs communication is generally going to be within a single machine but this method works if the two applications are part of the same larger application if they are distributed applications or as here entirely separate entities living on the web. Also the protocols employed for inter application messaging are unlikely to be SOAP but rather function calls. However we are looking at the bigger picture of the architecture in general and applying it to our needs. From a purely functional perspective this does what we require of a service discovery mechanism. What we would like this discovery mechanism to accomplish are the following:
- Support querying the interface to find if a module type is available (i.e. Path planning)
- Support querying the interface to find if a specific module is available (i.e. Path planning / gradient fields algorithm)
- Support querying the interface to find what services (public methods) are available, the data they require and the data they return.
We can, of course, explicitly state what services or methods our interface supports or perhaps create a simple configuration file stating the available options but these two options are limited and brittle and do not allow our interface to be truly "plug and play". They are, however, simple.
Group MembersCurrent members of the working group on world interfacing:
- Group coordinator: Ian Wilson - Emotion AI
- Tom Barbalet - Noble Ape
- Axel Buendia - SpirOps
- Erwin Coumans - Sony Computer Entertainment Europe
- John Morrison - MAK Technologies, Inc.
- Gregory Paull - The MOVES Institute
- Borut Pfeifer - Radical Entertainment
- Doug Poston - Conitec
- Marty Poulin - Sony Computer Entertainment America
- Adam Russell - Pariveda
- Duncan Suttles - Magnetar Games
Requirements Sub-Group Members
- Requirement #1 [Data Types]: Ian Wilson, Tom Barbalet
- Requirement #2 [Architecture]: Duncan Suttles, Borut Pfeifer
- Requirement #3 [Data Transfer]: John Morrison, Greg Paull
- Requirement #4 [Other AIISC Groups]: Axel Buendia, Doug Poston
Appendix A
WSDL Documents (Web Service)
A WSDL document is just a simple XML document. It contains set of definitions to define a web service.
A WSDL document defines a web service using these major elements:
|
Element |
Defines |
|
<portType> |
The operations performed by the web service |
|
<message> |
The messages used by the web service |
|
<types> |
The data types used by the web service |
|
<binding> |
The communication protocols used by the web service |
The main structure of a WSDL document looks like this:
|
<definitions> <types> definition of types........ </types>
<message> definition of a message.... </message>
<portType> definition of a port....... </portType>
<binding> definition of a binding.... </binding>
</definitions> |
A WSDL document can also contain other elements, like extension elements and a service element that makes it possible to group together the definitions of several web services in one single WSDL document.
The <portType> element is the most important WSDL element.
It defines a web service, the operations that can be performed, and the messages that are involved. The <portType> element can be compared to a function library (or a module, or a class) in a traditional programming language.
The <message> element defines the data elements of an operation.
Each messages can consist of one or more parts. The parts can be compared to the parameters of a function call in a traditional programming language.
The <types> element defines the data type that are used by the web service.
For maximum platform neutrality, WSDL uses XML Schema syntax to define data types.
The <binding> element defines the message format and protocol details for each port.
This is a simplified fraction of a WSDL document:
|
<message name="getTermRequest"> <part name="term" type="xs:string"/> </message>
<message name="getTermResponse"> <part name="value" type="xs:string"/> </message> <portType name="glossaryTerms"> <operation name="getTerm"> <input message="getTermRequest"/> <output message="getTermResponse"/> </operation> </portType> |
In this example the portType element defines "glossaryTerms" as the name of a port, and "getTerm" as the name of an operation.
The "getTerm" operation has an input message called "getTermRequest" and an output message called "getTermResponse".
The message elements defines the parts of each message and the associated data types.
Compared to traditional programming, glossaryTerms is a function library, "getTerm" is a function with "getTermRequest" as the input parameter and getTermResponse as the return parameter.
WSDL Ports
A WSDL port describes the interfaces (legal operations) exposed by a web service.
The <portType> element is the most important WSDL element.
It defines a web service, the operations that can be performed, and the messages that are involved.
The port defines the connection point to a web service. It can be compared to a function library (or a module, or a class) in a traditional programming language. Each operation can be compared to a function in a traditional programming language.
The request-response type is the most common operation type, but WSDL defines four types:
|
Type |
Definition |
|
One-way |
The operation can receive a message but will not return a response |
|
Request-response |
The operation can receive a request and will return a response |
|
Solicit-response |
The operation can send a request and will wait for a response |
|
Notification |
The operation can send a message but will not wait for a response |
A one-way operation example:
|
<message name="newTermValues"> <part name="term" type="xs:string"/> <part name="value" type="xs:string"/> </message> <portType name="glossaryTerms"> <operation name="setTerm"> <input name="newTerm" message="newTermValues"/> </operation> </portType > |
In this example the port "glossaryTerms" defines a one-way operation called "setTerm".
The "setTerm" operation allows input of new glossary terms messages using a "newTermValues" message with the input parameters "term" and "value". However, no output is defined for the operation.
A request-response operation example:
|
<message name="getTermRequest"> <part name="term" type="xs:string"/> </message>
<message name="getTermResponse"> <part name="value" type="xs:string"/> </message> <portType name="glossaryTerms"> <operation name="getTerm"> <input message="getTermRequest"/> <output message="getTermResponse"/> </operation> </portType> |
In this example the port "glossaryTerms" defines a request-response operation called "getTerm".
The "getTerm" operation requires an input message called "getTermRequest" with a parameter called "term", and will return an output message called "getTermResponse" with a parameter called "value".
- Login or join to post comments
Post to Twitter