General Issues

General Issues

The committee has a general forum to discuss issues that are relevant for all groups. Some discussions are given below.

C vs. C++

If you followed previous discussions of the committee, you might remember another discussion on this. While our approach was to have C++ interfaces (including some XML structures for function parameters), C was brought into the discussions again at our GDC roundtable this year. Concerns with C++ interfaces included (non-)compatibilities between compilers, and missing support for C++ on some platforms (e.g., regarding ABIs).

Thus, it was discussed in the committee again. Hardly everyone supported the C++ route, some detailing negative experiences with a C wrapping approaches, and pointing out that new compiler versions, like gcc 4.0, conform to the C++ ABI. If choosing C++, a potential option for vendors that want to also support C interfaces is for example to provide a C library that the C++ library must be linked against.

Considering that our poll at our 2003 GDC roundtable also resulted in a large majority of the participants for C++, the final decision was made to declare C++ as base for the interfaces. Discussions on what kind of specific language features should or should not get used may of course continue.

Callback Issues

The question of how to realize callbacks is very important for many parts of the interfaces because middleware often needs to call functions from the game. A unified way of handling callbacks would be an advantage because this makes the application of an SDK/middleware much easier.

There are a number of different ways to implement callbacks, for example:

• Direct callback functions (like in DirectX): The client registers a function with the middleware SDK by passing a function pointer so that the SDK can call the function.
• Inheritance: Game objects inherit from the SDK's base objects, and virtual or overridden functions are used as callback mechanism.
• Message passing: Some infrastructure is used to exchange messages between the SDK and game engine.

In contrast to direct callback functions, the inheritance approach is type safe and does not require static functions. It is, however, not that easy to "plug in." (An alternative to direct callback functions might also be the concepts like Boost.Function). Message passing is not really an option because we do not want that our interfaces are dependent on specific additional middleware to realize such mechanisms.

For now, the inheritance approach looks most promising, but the discussions have not yet been concluded.

Call Concept

As an extension of the discussion on "State Handling" of last year's report, here is a brief summary of the discussions. The discussion revolves around the topic of how to structure function calls. These are the main options that were mentioned:

• HW-F: hard-wired functions (which was also called object-oriented)
  Example:
  setBlend( true ) or setBlendTrue()

• HW-V: hard-wired enumerations/values (which was also called state-based)
  Example:
  setTrue( BLEND )

• DD: data-driven way
  Example:
  setTrue( "BLEND" )

Forward/Backward Compatibility: HW-F obviously has compatibility problems. A new function that is added would lead to an error when called in older versions. In the HW-V approach, passing a non-supported value is not a critical problem. DD obviously also has no problems with compatibility.

Performance: DD is very much in the disadvantage because everything that comes in needs to be interpreted. This is bad for low-level things, but probably fine for higher-level calls that are less often needed.

For now, we will mainly use HW-V because of the compatibility, and DD for some more rare/high-level cases.

Action Packages / Behaviors

Behavior/action packages was another topic that was discussed. In this concept, behavior components, such as scripts, animations and sounds, are centrally packaged together including conditions/requirements in order to have one central repository for managing potential behaviors/actions. AI sub-systems, like a finite state machine or a planner, can then reference/trigger these behavior objects.

However, the idea did not spark much positive feedback, and also our GDC roundtable participants were quite unsure about the benefits of such a feature. For example, behaviors/actions that need parameters were seen as a potential problem.