Gaming Object Model FAQ

Maintained by: Mark Cidade

This document contains what would probably be the most frequently asked questions about the Gaming Object Model. It is not intended to replace any specifications or other documents. Please send suggestions or comments about this FAQ to the address above.

General

What does GOM stand for?

The Gaming Object Model. This means that I am developing a model in which a computer or video game contains objects (players, items, etc.) that can be manipulated. So you will be able to delete, add, or change a game, change its content or add, delete or change an object.

Why should I support or use the GOM?

The GOM API is a viable candidate for a standardized, versatile view of a game’s contents. By supporting the GOM API, a game not only allows its data to be
manipulated by other routines, but does so in a way that allows those manipulations to be reused with other GOMs, or to take advantage of solutions already written for those GOMs. This interoperability also allows programmers who invest in learning to use the GOM calls to apply those skills to other GOMs.

The intent is that–if you stick with the standardized APIs–any GOM implementation can be plugged together with any GOM-based game. But this applies to larger-scale programming as well, as with distributed-enviroment on-line multiplayer games; for example, a server-side solution might be built out of the following reusable components, which may or may not all share a single GOM implementation:

• A central gameworld database which presents its contents as a GOM tree. (Note that the underlying data presented via a GOM need not itself be tree-like. The GOM is a tool for manipulating data, not a data structure itself.)
• [???]

If a better implementation of one of these modules becomes available (a faster parser, for example) or if an additional/different processing stage is required, you should be able to unplug the existing connections and plug in the new component with minimal recoding.

(The goal is “no recoding”, and that is already the case for many applications, but at this writing the GOM APIs are not yet complete enough to promise this for all applications. In particular, some of the tools needed to construct a GOM “from scratch” are not yet exposed in the published APIs, and the GOM has not yet defined a representation for the Game Type Definition information.)

Similarly, while all GOM implementations should be interoperable, they may vary considerably in code size, memory demand, and performance of
individual operations. So the ability to unplug and replace the GOM itself may also be very useful. For example, since some parsers can write into a
user-provided GOM, you may be able to parse a game’s state directly into the above-mentioned database.

There is one potential downside to using the GOM: As with any generalized set of interfaces, the GOM calls can be used to solve a very wide range of problems, but may not be the optimal solution for any specific problem. The advantages of interoperability and familiarity to users will more than compensate for this in many games, but you will find that some asks may call for other interfaces in addition to, or instead of, the GOM. For example, your application may wish to use custom interfaces internally for performance reasons, yet be able to import/export/expose its data via the GOM for convenient access from outside.

What is the current state of the GOM specification?

The GOM Core Interfaces are still being defined, so there isnt much in the way of a useable specification just yet.

What is a GOM implementation?

A GOM implementation (also called a host implementation) is that piece of software (or hardware) which takes the parsed game and makes it available for processing via the GOM interfaces. A home video game console can contain a hosting implementation, for example.

What programming languages can I use with the GOM?

This will depend on what hosting implementation you want to use it
with. Your favourite game engine might implement a JavaScript or UnrealScript interface, so you can use those scripting languages within the game itself to manipulate the game. Your favourite level or character editor might implement a Visual Basic or Java interface so you can write an executable in those languages that talks to your editor to manipulate the game. You might be able to write a game in C++ that uses the GOM interface to transfer information from the game in your machine to an online gameworld database via an ODBC driver. I am writing a set of interfaces; different developers will be able to implement these interfaces in different ways. It is unlikely that any one company will give you a choice of C++ and Java and Visual Basic and QuakeC and Python and ???, but interfaces in all these languages will be possible, since the GOM itself is language-neutral.

If the GOM is language-neutral, what language do you specify the interface in?

The Object Management Group Interface Definition Language (OMG IDL) was chosen as it was designed for specifying language and implementation-neutral interfaces. Various other IDLs could be used; the use of OMG IDL does not imply a requirement to use a specific object binding runtime.

I expect that the GOM can be implemented using CORBA, COM, or Java Virtual Machine runtime bindings. I expect that many implementations of the GOM will use bindings to various programming languages. The GOM might specify bindings for Java and ECMAScript (the standardization of JavaScript/JScript by the European Computer Manufacturer’s Association (ECMA) defined by ECMA-262) as appendices to the specification; other language bindings (for example, ANSI C++, QuakeC, or VBScript) may be supplied by other interested parties. Obviously it would be good if different implementations in other languages are consistent with each other.

What is the relationship between COM or CORBA and the GOM?

The Gaming Object Model, despite its name, is not an object model
in the same way as the Component Object Model (COM). The COM, like CORBA, is a language-independent way to specify interfaces and objects; the Gaming Object Model is a set of interfaces and objects designed for managing computer and video games. The GOM may be implemented using language-independent systems like COM or CORBA; it may also be implemented using language-specific bindings.

What does it mean to be compliant with the GOM specification?

A GOM-compliant game is one that responds to all the GOM API calls with the results documented in the GOM specification. You are not required to implement the optional modules (Output, Traversal, Ranges, Events or the specific event sets) in order to claim compliance, but if your GOM does not completely implement these it should respond “false” to the relevant hasFeature queries.

In many situations, it is possible and desirable to add features to
a GOM without breaking compliance. The simplest and safest way to do so is to define a new set of APIs which the objects in your customized GOM could support, so the behavior of the standard GOM API can be left unchanged.

Technical Notes

Why doesn’t the GOM specify anything regarding memory management?

The GOM specification won’t define any methods related to memory
management (such as to release an object). This is because while the GOM is a programming language independent API, the way one deals with memory is very language specific. Therefore any method related to memory management that is required by a particular language, needs to be specified in that language binding.

Why are the GOM APIs “interfaces” rather than “classes”?

Interfaces are widely used in many object-oriented languages, for example Java, and have several advantages when designing an API. They are similar to abstract classes, but all the methods are abstract. Variables in an interface must be constants. The key point with interfaces is that they do not constrain implementations. The methods defined in an interface must give the correct results, but the implementation is free to do anything it needs to. Thus, for example, even if one interface inherits from another, this does not mean that the implementation must share any code.

Interfaces are implemented by classes. Any given class is free to
implement more than one interface (e.g., an interface specified by the GOM and some extensions). When a class implements more than one interface, it must provide an implementation for all the abstract methods in each interface, but again, need not share code or any other implementation details.