GPI Design

In order to describe the system as it develops and allow everyone to see what's going on and how the different pieces of the GPI fit together, I will be using UML (Unified Modeling Language) diagrams. If you are new to UML (as I was) you can check out some tutorials or you can probably figure it out enough on your own to follow the diagrams. Keep in mind that I'm learning UML as I go so if I screw it up please let me know so that I can fix it.

With that said, here is a quick crash course in the subset of UML that I will be using. The diagrams show the relationship between classes in the GPI library. A line is an association. Lines with diamonds represent ownership of another class object. For example, a Game contains some number of DisplayAreas. The numbers by the links (as you may have guessed) represent the number of objects present in the relationship. The lines with triangles represent inheritance. Finally, the icons represent the visibility of a function or variable and should be familiar to MSVC++ users.

Below is a diagram of the very basic engine outline. My idea here is that a game contains a bunch or areas on the screen where different information is displayed. This information comes in the form of the actual playing area (where we see what's going on in the game world) but also in simpler objects such as information displays (like high score, etc.), labels for these displays, and general background art.

Each area is a sort of container where an actual object is displayed on the screen. Objects are a generalization of anything in the game world. This will be the largest inheritance hierarchy in the system since each object type in the game will be located in the tree somewhere.

Each of these 3 classes are only used to define the interface for different categories of game components and so should be virtual. As these broad concepts are specialized further down the inheritance tree some of the functions will be filled in and the final components which are derived specifically for a certain game will (obviously) have a full implementation. The idea, however, is to encapsulate common functionality at the highest possible level.

The next diagram depicts some possible derived classes. This inheritance structure will be fleshed out more as the project proceeds, but I'm including this just to give people a general idea what to expect in the end.

Here the DisplayArea and Object trees are fleshed out more. There are two special types of DisplayAreas. A StatusArea provides not extra functionality, but the Object it will contain is a StatusObject which will have added functionality which will need to be utilized to render this Object. A ControlArea is an invisible area that accepts input from the mouse and then passes it on to an associated object. I'm not certain if this is the best way to handle mouse input at the moment, but its an idea that I've been tossing around.

There are also 3 specializations of the general Object class. First, a ConrtolledObject has an additional Controller property which allows the Object to be updated on its own. In contrast to the ControlledObjects are StaticObjects which can only have their properties changed by the CollisionTest() function. Finally, there is the StatusObject class which represents some sort of information about the game world which can be displayed in a StatusArea.

Finally, there is a new Controller class and Keyboard class which is derived from it. These classes allow an object to be controlled by user input (as in the Keyboard) or by AI (to be added later...)

This is the extent of the current GPI framework and is the basis I will be extending to provide the functionality for the upcoming game projects. Stop by the message board and let me know what you think of this framework.