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.
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.
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.
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.
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