Here is a brief overview of the class hierarchy for the object system in my engine. The majority of the design is taken from Dave Eberly's Wild Magic engine, which you can check out here.

However, there are certain things which I do differently than Dave for a number of reasons. I will be explaining these differences over the next couple of posts. There is, of course, no perfect design, so hopefully someone out there can make further suggestions on how to improve the design! Here is the UML class diagram for the three main classes in the object hierarchy*:
<
(* please note that these are not complete class diagrams - only the portion that I am discussing in this post are shown)
<

CObject
So the basis for just about everything in Heiroglyph revolves around accessing the data for the current game world. I chose to use a common base class for all 'objects' in the game application; namely CObject. This class provides the basic interface that will be used to allow these objects to interact with other objects as well as the various utility classes of the engine. The interfaces are made abstract to force the sub-classes to implement them, enforcing the interface for all game objects.

CEntity
The first sub-class to implement the CObject interface is CEntity. This class provides all of the 3D attributes to the object hierarchy. So anything that occupies space, has a position and orientation, or can interact with the 3D world would be derived from CEntity. In addition to providing the data members, CEntity also provides the interface for manipulating these parameters as well.

CNode
CNode provides a method of 'linking' one or more objects to itself. In computer science this is a data structure referred to as a 'graph'. You have probably heard of 'Scene Graphs' quite often in the forums. A scene graph is simply the scene represented through the parent-child links between all of the objects in a scene. This is essentially the same in Heiroglyph, CNode allows one or more entities to be attached to
itself.

For creating more interesting scenes, CNode has been made a sub-class of CEntity. This allows the scene to contain many levels of objects, all linked back to a root node. The links can be made in any way that seems appropriate, but there are advantages to using a logical methodology when creating the scene hierarchy. For instance, if you want to use hierarchical culling of object for rendering, then it makes sense to connect the objects in a 'physical relationship' manner. Then objects that are close together could be culled away by culling a single parent node. This is a simple example, but the point is that the structure that the objects are arranged in can be used to the users advantage in a variety of ways.

Building a Scene
So the basic methodology for creating a scene is as follows:

• Create a root CNode ( called pRoot for this example )


• Create whatever objects are needed for the game world ( this can include other CNodes as well! )


• Link these objects to pRoot or other nodes attached to pRoot

So, why exactly are we creating and linking the scene this way? Since CObject is a super class of all CEntity and CNode sub-classes, all objects in the game now share a common interface:

• Update


• ReadInput


• Draw


• RenderSetup

This may seem overly simple, but this really is all that needs to be done to gain quite a bit of functionality. The key here is that the CNode implements these functions a little different than the other objects. CNode simply calls these functions on all of its children - for example, if you call Update on a CNode, it will call Update on all of its children. If any of the children are CNodes, they will do the same and call Update on all of its children.

So the root node that we connected everything to earlier now provides the complete interface that we need for update and rendering our objects every frame. The games update loop would look something like this:

1. pRoot-->ReadInput( pInput );


2. pRoot-->Update( pTimer );


3. pRoot-->RenderSetup( pRenderer );


4. pRoot-->Draw( pRenderer );

And there you have it, with four lines of code (several) hundreds of objects can be controlled, updated, and rendered.[wow]

Thank you to whoever was the first person to think up the graph design pattern and thank you to whoever first used it for working with game objects, because it makes life a whole lot easier!

More to come on the pro's and con's of this structure, plus some of the differences between my design and Dave Eberly's (mine is just a little less formal...[looksaround])