TECHNOLOGY

The game engine behind "8" is being made with a middleware application called Quest3D ( http://www.Quest3D.com ). Quest3D is a visual programming environment that gives the user easy access to all features of DirectX. It is also very extensible through a C++ SDK. We chose to use an authoring environment that would allow for the design to be driven by art rather than technology.

Quest3D has a very rapid prototyping phase. It enables non programmers to quickly create a wide range of visual effects and behaviours. One of the challenges when designing the system architecture is to keep this feature. As the project grows very large, it is very easy to introduce too many dependencies and lose this advantage. The architecture presented here is intented to keep this advantage while maintaing the standard design goals of modularity, extensibility and simplicity.

The main feature of the design is that game elements are defined as small modular units that specify the look and behaviour of a single item, for example a rock, table or the static elements of a room. The core game functions then use these modular units to populate the world.

Using this structure, the game is easily extensible. Adding another room, item or behaviour is a matter of creating the new modular unit. Each item is independent of all the others providing a very modular structure and because there are minimal dependencies between items the resultant code is much more straightforward.

There are three major segments to the architecture

  • Content
  • Implementation
  • Game functions


Content
This is the mesh, texture and sound data for the game. This is treated as a separate segment so it can evolve independently as it grows larger and we require the workflow to become more automated.

Implementation
This is where the game sits. Defined here is the static world, interacting entities, their behaviours and the Girl. At the moment there two classes -rooms and interacting objects- but the architecture is not limited to these.
Static elements
The static world and standard elements of all the interacting entities and the girl are defined by a minimum set of standard functions referenced by Game functions.
Object Interaction
Which objects interact and the way they interact with each other is defined here. When communicating between objects, Quest3D is a weakly typed language. This means objects can use special function calls to interact with other objects appropiately without worrying about type conflicts.
For example if you have is a fire object that burns things, it burns other objects via the 'getBurned' function. When another object is placed in it, the new object is checked if 'getBurned' function exists. This is done in an analogous way to the Python dir function. If the burn function does exist in the new object then it is called and the new object burns in the correct way.
This weakly typed function checking avoids a lot of issues with multiple inheritance and class structures that would be necessary in a more strongly typed language like C++. Used in conjunction with 'mini-world' test cases this allows non-programmers to quickly develop the required look and behaviour of objects.

Game functions
These are the system rules of the game and provide the glue logic that holds everything in place. There are three communication mechanisms supported between Game functions and Implementation
Game function -> Implementation via standard function calls
This is the means by which the Game functions co-ordinate the behaviour of the world.
Implementation -> Implementation via special fuction calls
This is how the world is populated with objects and interaction. Using special function calls and matching them with the weakly typed mechanisms allows almost infinite extensibility of behaviour in the world
Implimentation -> Game function via an interface class
This allows the implementation to make requests to the Game functions. The most typical use is start a movie or quit the game. Placing all this backward communication in a single place has three benefits
  • the Game functions are hidden from the Implementation increasing modularity
  • the functions seen by the Implementation can be cast into a form that makes convenient to the Implementation (the Adapter or Bridge pattern)
  • the Game functions can reject the request if it does not make sense