Game Engine Bindings

Blender Game Engine

As the base engine for prototyping this network library, Blender has some bindings implemented already in the bge_game_system module. The network system is designed such that bindings are injected (at runtime) into the game_system, enabling a complete separation between implementation and user modules.

To inject the BGE bindings, simply import the bge_game_system library. Currently, the following aspects of the system are modified by bindings:

• ResourceManager - setting the base data path and current engine identifier.
• DelegateByTag - metaclass leveraged by ComponentLoader for loading Actor components, also used by other systems for runtime injection.

Let's take the Actor class as an example. In order to support engine specific functionality like model instantiation, physics information and other features, we first discretize it into components. These components are black-box, with the default actor class failing to load such components without any concrete implementation. Why do this in-place, and not make use of an ActorFactory? Simply, using such a factory would not permit Actor inheritance in generic code. This would prevent ease of cross-platform deployment, both of the standard library and user code itself. Instead, using the ResourceManager environment identifier, we lookup the appropriate component loader for the current engine, and ask for the necessary components for the actor instance.

This allows the BGE to load objects in the required manner which may not be the same for other engines. To support the fact that certain engines might require additional data to load the same components, a definition file for the Actor is utilised with sections devoted to each engine. The component loader for the environment is provided with the appropriate section.

Some specific systems, like the InputManager and MouseManger, are currently implemented as Singletons, with a generic interface to provide engine events. This might be changed in future to avoid global namespace where avoidable.

The largest aspect to the BGE bindings is the gameloop, which features a lot of repeated code for profiling, due to a slightly verbose API, but also ties in most of the game together. It is not practical, nor ideal to produce a closed gameloop at this stage, since many users may wish to extend rather than embed, and as such, there can be no base class for such a feature. In the future, a reference implementation in psuedo code, or for pure-python may be written.