Happy new year

Hello you! What a pleasure to see you again! REALLY! Although there were no new posts during the last 2 months, I`ve been coding a lot and rewrote hundreds (or thousands of lines) of BlueWar.

Why did I do that? Because it wasn`t perfect. When I began the development of BlueWar, I was a little silly boy that wanted to know how real games were made. That boy had no idea of how all those models in a game were organized, the most complex data structure he knew was a list.

Although I had refactored my code a lot since the very beginning, there still were some design decision left from that past decade which I wanted to eliminate:

data structure:

  1. file types
    Although most files were logically named and most class definitions were separated from their declarations, all the code was in .h files that got included in one WinMain .cpp. This allowed much faster complete-rebuild-times, but also forbid partly rebuilding.
  2. class hierarchy
    The object base class was extended by objectfight (game objects that are able to fight). There was another class for moving objects (objectmove). Now this design produced many problems: there could be no classic RTS unit, because a unit hast to move AND fight. So objectmove was changed to inherit objectfight, but this meant that the game would not be able to handle civil moving units. What a shame!

The first problem was (uneasily) solved by (just) renaming lots and lots of source code files and (even more embarrassing) adding thousands of #include directions to all those files. This took quite some time and revealed even more problems: because there was more than one code file, static variables that were defined in a header file were not unique! I know this is a child`s mistake, but hey, I quickly fixed it by using really unique statics (defined in cpp`s) and some Singletons as I don`t really like the length of code that Singletons produce:
compare “GameManager::getSingletonPtr()->doSomething()” with “GameManager.doSomething()”!

Perhaps I will try to combine both by overloading or “#define” the “->” operator, but I will need to investigate further.

To introduce a solution for the second problem I implemented a plugin system (you know already, as you read my last post, didn`t you? ;)). PlugIns take over the responsibity of the old inheritances of different object classes. So there is an unlimited number of possibilities to combine different plugins for different behaviours, functions, etc.

While implementing various plugins, I realized that there had to be a simple way for plugins to communicate to each other. So I introduced PlugInInterfaces, abstract base classes for different pluginTypes. The object class holds smart pointers to these interfaces and plugins that are inheriting from the interface classes can register themselves as a “FightInterface”, “MoveInterface”, “AI interface”, or whatever. The interfaces are now also used by “outsiders” as the ActionManager, who calls “attack” to the “FightInterface”.

To enhance the amount of new code even more (is there really some “old” code left?), I also switched to a new CVS version of Ogre, CEGUI and plsm2, which isn`t as easy as the last time due to thousands of interface breaking changes. Main problems are the new OIS (solved by now), and CEGUI 0.5 (I`m still fighting to let my code cooperate with the new coordinate system).

Best wishes for a great year 2007!

And HAPPY CODING for those of you who believe in code…


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s


%d bloggers like this: