I did move on to the next thing; the event system. I coded up a simple framework and slapped it in and it works fine. I went for a message queue and listener approach. Every object has to register itself as a listener for certain messages. When an event is fired, only those objects who have subscribed to get that event receive it. It still needs a lot of work, but it is a start.
 

Not much has happened on the game shell front; actually I take that back, a lot has happened but not really anything immediately obvious.

I have spent a lot of time reading a ton of books on C and game development, trying hard to focus on good OO skills and design as well as learning what libraries are out there and can be leveraged.. Scott Meyer's book have been amazing ( the whole series ), as well as the accelerated C series edited by Bjarne Stroustrup these books are absolutely amazing and have changed the way I write code. The C/C user's journal has also been invaluable in my development.

So I took some time to re-write the object management code, the FuBi system, as well as integrate a scripting language. I choose Lua because it is fairly easy to learn, easy to integrate, pretty extensible, and Lucas Arts used it and that is good enough for me :). The code is now much more de coupled from the rendering engine. In fact it really has no game specific code in it.. All game specific code and behavior has been moved into a DLL plugin system that registers itself at runtime allowing all behavior to be scripted in Lua.

I have also taken the time to update the file compression system to zLib 1.4 and rewrite some of the compression class.

As far as the game engine goes, that seems to stay up in the air. Here it is a year later and Destiny3D is no farther along than Jet3D was at the time and it is kind of disappointing. I'm sure that they are working very hard over there, but it still seems a long way away from being usable. I have been trying out the Ogre engine with a lot of success. It is not a game engine, but only a rendering engine. This is not really a bad thing as you can integrate all the other pieces yourself for whatever kind of game you want. I will post some screen shots on the shots page soon. Right now I have the whole demo being run from a Lua startup script and have MP3 playback ( via FMOD ) and 3D sound ( via DirectAudio ) working. I have also taken the time to write Visual C wizards to generate DLL plugin objects for the game.

I am streamlining and finalizing the Lua integration, and development should speed-up as the entire system is put in place.. I will update the shots page as we test new functionality.

 

Things are moving along well with Destiny3D. I downloaded the pre-alpha release this week.. I compiled and ran the code without any problems. The editor is shaping up nicely and the team is doing incredible work.

I've decided to start a game development project because the market has amassed enough free tools to allow a high quality game product to be produced with reasonable development time and cost. I have put together a talented team of people and a design document is on the way...
 

I thought it would be a good idea to add CRC functionality to the inventory persistence functionality.. This would provided data integrity checking on file loading. The system now has the ability to check the entire data file integrity as well as each object against the original CRC that the object was stamped with when it was persisted to disk. So far it works great, but it forces me to rethink my error trapping design and come up with a more robust way of handling exceptions.
 

I did some regression testing in order to make sure nothing has been broken during my latest updates to the shell. I found that the intro section had been hosed so I ended up fixing it and now it works great.

I have been testing out a debugging tool that monitors memory leaks and the like, and have found a few both in the factory code and in the ZLib DLL. The memory leaks in the factory were simple new/delete errors. I re-downloaded the ZLib source and recompliled the ZLib.dll turning on all the optimizations and ran it through the tool again, and in the end I had no leaks or uninitalized memory reads. So I'm pretty happy with that; although a leak could creep in anytime from a plugin dll.

While I was optimizing the factory I decided to really take the time to benchmark the compressed file save/read funtionality.. so here are the results:

-----------------------------------------------------------------------

#define CLEVEL Z_NO_COMPRESSION
#define CSTRAT Z_DEFAULT_STRATEGY

50,000 products
16,842,240 bytes disk space

12:55:37:0920:PM Found Plugin: light_object.dll ver:1, 0, 0, 4
12:55:45:0100:PM It took 7.173861 seconds to gendata.
12:55:45:0360:PM It took 0.260908 seconds to showProducts.
12:55:53:0833:PM It took 8.478092 seconds to saveData.
12:55:58:0239:PM It took 4.397299 seconds to loadData.
12:55:58:0529:PM It took 0.294308 seconds to showProducts.
12:55:58:0800:PM It took 0.271221 seconds to liquidateInventory.

----------------------------------------------------------------------
#define CLEVEL Z_BEST_SPEED
#define CSTRAT Z_DEFAULT_STRATEGY

50,000 products
210,944 bytes disk space

12:59:20:0810:PM Found Plugin: light_object.dll ver:1, 0, 0, 4
12:59:27:0500:PM It took 6.692598 seconds to gendata.
12:59:27:0760:PM It took 0.261881 seconds to showProducts.
12:59:30:0474:PM It took 2.710131 seconds to saveData.
12:59:34:0900:PM It took 4.432538 seconds to loadData.
12:59:35:0181:PM It took 0.273875 seconds to showProducts.
12:59:35:0451:PM It took 0.273369 seconds to liquidateInventory.

-----------------------------------------------------------------------

#define CLEVEL Z_BEST_COMPRESSION
#define CSTRAT Z_DEFAULT_STRATEGY

50,000 products
210,944 bytes disk space

01:01:44:0837:PM Found Plugin: light_object.dll ver:1, 0, 0, 4
01:01:51:0116:PM It took 6.275208 seconds to gendata.
01:01:51:0367:PM It took 0.258504 seconds to showProducts.
01:01:54:0091:PM It took 2.716792 seconds to saveData.
01:01:58:0567:PM It took 4.506057 seconds to loadData.
01:01:58:0837:PM It took 0.271229 seconds to showProducts.
01:01:59:0108:PM It took 0.274240 seconds to liquidateInventory.

Looks like I'm getting a 98.75% compression ratio...

Still waiting for the FuBi article to be published... I wrote the author and it will be a few more weeks until it will be ready, I'm sure he is busy working on Dungeon Seige which is his latest project where FuBi was used...

I continue to monitor the Genesis and Jet3D forums and it looks like an alpha will be out by end of summer. I am probably looking at September befor anything usuable will be out... I will continue to add to the gameshell to make sure all the tools are in place before the engine is released. I have had to spend a lot of time getting my new home together so my time is limited anyway...

 

Hopefully in the next week or so I will get my hands on some very interesting code from one of the presenters at this year's GDC called "FuBi: Automatic Function Exporting for Scripting and Networking". I would love to use this code to implement solid scripting of both the factory and the plugins. We'll see how it goes, at this time the site still list the source code as 'coming soon'.
 

The main benefits of this system is now all creator and product code is now loaded at runtime from separate DLLs. This decreases A LOT of the dependances between the factory and the objects that it creates. This is what I had envisioned from the beginning. Creating new objects is easy with a simple interface template I have created. You just drop the DLL into the factory directory and either restart the factory or send a plugin refresh command and it will load all the plugin creators from the directory... It really saves on compile time to have all the objects in separate libraries..

The only thing to watch out for is to be aware of the DLL process boundary. This is why all plugin objects must override the destroy() method so that you can call:

game_object->destroy();

instead of:

delete (game_object);

The destroy() method just calls:

delete this;

But it calls it internal to the DLL process that created it so it can be properly handled. The next step in this process is to design a mechanism to notify the factory that a plugin has been unloaded and to release all objects of that type, otherwise when a liquidation command is issues to the factory; the following line will cause a exception:

game_object->destroy();

Because the DLL process has been removed from memory along with all the object references it has created. Therefore liquidate must be called every time a DLL is unloaded. I must implement a liquidate method that selective releases only those objects in the factory that are associated with the plugin.. This system is starting to look really good.. I just hope Destiny comes out soon...
 

I am also dealing with the problem of data file versioning and do not want to have the same problem many game vendors have when they release a patch for their game that makes the users save games invalid. I have gone down many paths to try to make this happen but have not settled on an adequate answer.. I am trying to abstract out a better singleton class to apply to the Factory, but that is not quite working yet. I am also trying to add some reference counting code to help track down and eliminate memory and resource problems..

Anyway I guess the biggest news is the GWExplorer app I wrote in MFC to help test the factory and investigate factory created data files.. The app can ready any factory created data file regardless of version. This is because it only reads and verifies the data format, and does not look at the object internals. The app would have to know too much about the format and the object's key code to load it so I decided to just read each object's header.. It is my first real MFC app from scratch and it wasn't easy.. The MFC docs aren't that great (what a surprise) but I got a tree control to work as well as HTML support and dockable toolbars so I am pretty happy with it. It serves its purpose. Check out the screen shots page for some pix of it...

I am also looking at an interesting plugin architecture that I saw implemented on flipcode.com in the 'code of the day' section. More on that later...
 

In order to increase code manageability I decided to break all the separate factory services into separate modules containing the class definition in the header (.h) file and the class declaration in the module (.cpp) file.. This is general practice and would help me to better manage the code... This is what I thought, little did I know this would start my trip on the nature trail to hell..

The code compiled fine, but during the linker process I got link errors complaining about undefined externals, which meant that most likely the template generated code had very different signatures than what needed to be there.. After some research I found out that template class definitions and declarations have to be in the same translation unit, which meant that I had to move all my declaration code into the header (.h) files... After doing this I tried to re-compile. As usual compilation went find, but the linker again complained. This time is was a multiple declaration error. This meant that every (.ccp) module that used the (.h) file was also including the class declaration code.

At this point I was pretty pissed.. I was damned if I did and damned if I didn't. After some more research it seems that the C++ standard does have a language construct for this exact situation. The 'export' keyword was designed to let all translation units know about the template definition so that you can break the code into (.h) and (.cpp) files. This would solve my problems.

The bad news is that Micro$oft decided in their infinite wisdom not to implement the export keyword, even though it is part of the C++ standard... So I began my search for another solution. This lead me to an article on Implicit Instantiation which means in every (.cpp) file I have to implicitly instantiate an object template of a specific type, like the following line:

template class Factory<base_product>

This statement creates an instantiation of Factory without reserving any storage for an object; code is generated for all members. This technique works but is not as clean as using export. I was hoping to compile the factory code into a (.lib) file to cut down on compile time, but now there are files internal to the factory that are dependant on derived products, and need to be implicitly instantiated using those derived types. This means I must recompile as well as add new code for every new derived object I add to the factory. But for now this works and I'll just wait for Visual C++ ver 7.0 or a service pack to hopefully fix the problem. I must say I'm fairly disappointed in Micro$oft's implementation of the C++ language, not surprised, just disappointed. Hopefully I can clean the code up a bit more and make it a bit easier to use in projects, because the next step is to put it through the paces and see how it performs in the game shell.
 

The cooler thing I have implemented is file compression... This just plain rocks.. I ended up using the Zlib compression library, which is open source. It is the same algorithm used for gzip, zip, and PNG. I also found some interesting code that extends the iostream class to use the Zlib package.. I tweaked the code and merged it into the inventory code which allowed the objects to save themselves out to a compressed stream.. I reworked the file saving code to only open and close the stream once, which made it a hell of a lot faster... To test the object saving system I created a loop to create 50,000 objects and then saved them to disk... The uncompressed version was about 2.5Mb, where the compressed version was 68kb that is a 98% compression. It is amazing that the difference in load and save time is not noticeable, although I have not clocked it in the code; which I will do as soon as I get the timer class linked in.. The cool thing is that if I can get the network code to work on Windows 9.x I could push the compressed info across the network and expand it on the other side, which is really cool. Anyway that is the newest info...
 

Lately I have continued work on the object based class system and made it a playground to test out different object creation and storage methodologies as well as some network stuff.. The object system now really is made up of three tightly coupled parts: factory, warehouse, and patent office. First you register you new component object class with the patent office as a blueprint. They you can call create, and the factory will use the registered blueprint to create the new object; only objects with registered blueprints can be created. The object is then stored in the warehouse inventory. The inventory allows you to query the object pool and get a pointer to any object stored there, it also handles inventory cleanup on factory destruction; which is a simple form of garbage collection. Each object has a simple COM-like interface to allow for perfect backwards compatibility. I'm still exploring the last bit..

The warehouse/inventory paradigm allowed me to implement a scheme where every object knows how to persist itself and initialize itself from disk.. This allows me to iterate through the warehouse inventory and save each object's state out to be later read back in. This will come in very handy in the future for saving game state.

In order to allow a future integration with a scripting system and cut down on redundant code, I have implemented a simple command system in the object architecture. Basically it is a simple STL map container that stores the name of the command with a pointer to the function that implements it. This allows the shell to make calls to the factory and access functions in both the warehouse and the patent office though just one function for example:

EXAMPLE: executeCMD("save_inventory","inventory.dat");

The warehouse object is a protected member of the factory object which allows inventory saving. The only function exposed to the global interface is the executeCMD function which has a specific set of commands that it can process. There is a simple internal function for adding new commands.. This will allow easy scripting of the object factory as well as cut down the amount of code needed to expose the internal interface of the three components of the object system to the outside shell.

I have spent a lot of time implementing a test harness to make sure each part of the system works as expected and can catch errors on failure. I also created a HTML logging system to help me monitor the system as it runs. The next big implementation will be exception handling. The system really needs some form of centralized error reporting and handling routines. The log reports the errors but does little to recover from them in a elegant manner. I will be looking into Structured Exception Handling (SEH) to accomplish this task.

I think the game shell will benefit greatly from a solid and well thought out object system that will be a foundation for all the parts of game play that need some sort of life span and state management... Well that's it for now... Who knows when I will post again...