What is the Gaming Object Model?
What is the Gaming Object Model?
Introduction
The Gaming Object Model (GOM) is an application programming interface (API) for computer and video games. It defines the logical structure of games and the way a game is accessed and manipulated. In the GOM specification, the term “game” is used in the broad sense.
With the Gaming Object Model, programmers can build games, navigate their structure, and add, modify, or delete agents and items. Anything found in an GOM-compliant game can be changed, deleted, or added using the Gaming Object Model.
As a universal standard interface, one important objective for the Gaming Object Model is to provide a standard programming interface that can be used in a wide variety of environments and applications. The GOM is designed to be used with any programming language. In order to provide a precise, language-independent specification of the GOM interfaces, the specifications have been chosen to be defined in OMG IDL, as defined in the CORBA 2.2 specification.
Note: OMG IDL is used only as a language-independent and implementation-neutral way to specify interfaces. Various other IDLs could have been used. In general, IDLs are designed for specific computing environments. The Gaming Object Model can be implemented in any computing environment, and does not require the object binding runtimes generally associated with such IDLs.
What the Gaming Object Model is
The GOM is a programming API for games. It is based on an object structure that closely resembles the structure of the games it models.
In the GOM, games have a logical structure which is very much like a tree; to be more precise, it is like a “forest” or “grove”, which can contain more than one tree. Each game contains zero or one gametype game object (gob), one agent gob, and zero or more item gobs; the game gob serves as the root of the tree for the game. However, the GOM does not specify that games must be implemented as a tree or a grove, nor does it specify how the relationships among objects be implemented. The GOM is a logical model that may be implemented in any convenient manner. In this specification, the term structure model is used to describe the tree-like representation of a game. The term “tree” is also used when referring to the arrangement of those information items which can be reached by using “tree-walking” methods (this does not include properties). This should not be taken as meaning that the GOM must be implemented as a tree structure. One important property of GOM structure models is structural isomorphism: if any two Gaming Object Model implementations are used to create a representation of the same game, they will create the same structure model.
The name “Gaming Object Model” was chosen because it is an “object model” in the traditional object oriented design sense: games are modeled using objects, and the model encompasses not only the structure of a game, but also the behavior of a game and the objects of which it is composed. In other words, the gobs in the above diagram [not there yet] do not represent a data structure, they represent objects, which have functions and identity. As an object model, the GOM identifies:
- the interfaces and objects used to represent and manipulate a game
- the semantics of these interfaces and objects - including both behavior and properties
- the relationships and collaborations among these interfaces and objects
What the Gaming Object Model is not
This section is designed to give a more precise understanding of the GOM by distinguishing it from other systems that may seem to be like it.
- The Gaming Object Model is not a binary specification. GOM programs written in the same language will be source code compatible across platforms, but the GOM does not define any form of binary interoperability.
- Instead of specifying how objects may be represented in a given programming language, the GOM specifies how games are represented as objects, so that they may be used as object oriented programs.
- The Gaming Object Model is not a set of data structures, it is an object model that specifies interfaces. Although the spec will contain diagrams showing parent/child relationships, these are logical relationships defined by the programming interfaces, not representations of any particular internal data structures.
- The Gaming Object Model does not define what information in a game is relevant or how information in a game is structured. The GOM is simply an API to this information.
- The Gaming Object Model, despite its name, is not a competitor to the Component Object Model (COM). COM, like CORBA, is a language independent way to specify interfaces and objects; the GOM is a set of interfaces and objects designed for managing games. The GOM may be implemented using language-independent systems like COM or CORBA; it may also be implemented using language-specific bindings.
Compliance
The Gaming Object Model consists of several modules: Core, Output, Graphics, Events, Traversal, and Range. The GOM Core represents the functionality used for all games
A compliant implementation of the GOM must implement all of the fundamental interfaces in the Core chapter with the semantics as defined. The other modules are optional.
A GOM application can use the hasFeature method of the GOMImplementation interface to determine whether the module is supported or not. The feature strings for all modules in the GOM are listed in the following table (strings are case-insensitive):
| Module | Feature String |
|---|---|
| Core | Core |
| Output | Output |
| Graphics | Graphics |
| Events | Events |
User Interface Events (UIEvent interface) |
UIEvents |
Game Controller Events (ControllerEvents interface) |
ControllerEvents |
Mutation Events (MutationEvent interface) |
MutationEvents |
| Traversal | Traversal |
| Range | Range |
The following table contains all dependencies between modules:
| Module | Implies |
|---|---|
| Core | Core |
| Output | Output and Core |
| Graphics | Output and Core |
| Events | Core |
| UIEvents | Events and Core |
| ControllerEvents | UIEvents, Events and Core |
| MutationEvents | Events and Core |
GOM Interfaces and GOM Implementations
The GOM specifies interfaces which may be used to manage games. It is important to realize that these interfaces are an abstraction - much like “abstract base classes” in C++, they are a means of specifying a way to access and manipulate an game’s internal representation. Interfaces do not imply a particular concrete implementation. Each GOM-compliant game engine is free to handle games in any convenient representation, as long as the interfaces shown in this specification are supported. Some GOM implementations can be existing games that use the GOM interfaces to access code written long before the GOM specification existed. Therefore, the GOM is designed to avoid implementation dependencies; in particular,
- Properties defined in the IDL do not imply concrete objects which must have specific data members–in the language bindings, they are translated to a pair of get()/set() functions, not to a data member. Read-only properties have only a get() function in the language bindings.
- Games may provide additional interfaces and objects not found in this specification and still be considered GOM compliant.
- Because interfaces are specified and not the actual objects that are to be created, the GOM can not know what constructors to call for an implementation. In general, GOM users call the createX() methods on the Game class to create game structures, and GOM implementations create their own internal representations of these structures in their implementations of the createX() functions.
