Gaming Object Model Requirements

General Requirements

Listed below are the general requirements of the Gaming Object Model.

1. The Object Model is language neutral and platform independent.
2. There will be a core GOM that is applicable to all gaming modules.
3. The Object Model can be used to build and deconstruct a game.
4. The Object Model will not preclude use by either agents external to a game’s contents, or scripts embedded within the game itself.
5. Consistent naming conventions must be used through all levels of the Object Model.
6. A UI component will not be required for a conforming implementation of the Object Model.
7. The specific object models for each module will be driven by the underlying constructs of those module types.
8. It must be possible to extract a game’s information and input structurally identical information back into game (both data streams can be represented by the same raw structural model).
9. The Object Model will not expose the user to problems with compatibility, playability, or networking issues.
10. The Object Model will not preclude other mechanisms for manipulating games.

Structure Navigation

This refers to the navigation around a game’s structure, such as finding the goal of a given game agent (e.g., player), or what items are in a agent’s possession.

General Requirements

1. All of a game’s contents, including agents and items, will be programmatically accessible and manipulable.
2. There will be a way to uniquely and reproducibly enumerate the structure of static games.
3. There will be a way to query for objects and properties, subject to security and privacy considerations.
4. Basic low-level functions (get first, get next, etc.) will be provided, along with convenience functions that build upon them, but have a consistent access method.

Non-Core Requirements

These are specific to non-core modules.

1. All objects known to the game engine are exposed.
2. Unknown entities and items are exposed.
3. Implied properties are exposed even if not explicitly defined in the game (time, spacial dimensions, etc.)
4. There will be guidelines for the inclusion of new game objects and properties in the object model.

Game Manipulation

1. There will be a way to add, remove and change agents and/or items
   (if permitted by the Game Type Definition and not precluded by
   security or validity considerations) in the game’s structure.


2. There will be a way to add, remove and change properties (if not precluded by security or validity considerations) in the game’s structure.


3. Operations must restore consistency before they return.


4. A valid static game acted upon by the GOM will deliver a
   consistent reproducible game structure.

Object Manipulation

1. There will be a way to determine the containing object from any property of the game (subject to security considerations).


2. There will be a way to manipulate (add, change, delete) objects.
   

Event Model

The event model must be rich enough to create completely interactive
games. This requires the ability to respond to any user action that
may occur in the game. Therefore, many of these requirements only
apply if a UI component is involved.

1. All objects will be capable of generating events.


2. There will be interaction events, update events, and change events.
   


3. The event model will allow responses to user interactions.


4. The event delivery mechanism will allow for overriding of default
   behavior.


5. Events will bubble through the structural hierarchy of the game.
   


6. Events are synchronous.


7. Events will be defined in a platform independent and language neutral
   way.


8. There will be an interface for binding to events.

Graphic Display Object Model

A graphic display is one model for manipulating the output of
the game. The graphic display object model exposes the ability to create,
modify, and associate visual elements with the game. The graphic display
model will be extensible to other output formats in the future.

1. All graphic elements will be represented in the object model.


2. There will be a graphics model. The graphic object model will be
   defined as part of an output model, where the core part of
   the model may be applicable to other output types.


3. Elements and properties of individual graphic displays can be
   added, removed and changed.


4. All elements of a graphic display can be added, removed, and changed in the
   object model. This includes but is not limited to:
   
   
   
   1. sprites
   
   
   2. polygons
   3. wireframes
   4. NURBS
   5. voxels
   
   
   6. colors and textures
   
   
   7. lighting
   
   
   8. other effects
   
   

Error Reporting

1. The GOM will provide a game-wide error logging and reporting
   mechanism.


2. Error reporting will be primarily via exceptions.


3. The GOM error state can be queried.

Game Engine (GE) Information

These are requirements for information about the game engine environment,
if applicable

1. There will be a way of obtaining relevant information about the
   display environment, including the GE brand information and version
   number.


2. A way of determining support for a
   game type will be available.