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
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
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.
Lets make some games!