Geeks With Blogs



Add to Technorati Favorites

An Archived Managed World This blog has moved to

Well, I've been reading 3d Game Engine Programming lately and I love what I've read so far. I have decided that I am going to be adopting a similar engine architecture for my game. The architecture is largely based around late-binding modules (aka assemblies) into the game to accomodate a plugin architecture. This allows any in the future to plug in modules based on different APIs that I will use. For the game, I will be using Managed DirectX. However, if someone wanted to implemented a Managed OpenGL renderer for the engine, it is entirely possible and not that difficult (if you know OpenGL that is).

I've now got a prototype architecture up and running as of this evening. The architecture (in its infant state) is based around one statically linked¬†assembly (for now it is a simple project reference in the solution), and one dynamically linked assembly that contains the actual renderer and is loaded at runtime via reflection. The abstract base class for the renderer is implemented in the statically linked assembly so that the game can use the renderer via this base class. This is possible because the actual renderer in the late-bound assembly derives from this base class. Pretty slick. I'm fairly proud of myself. To this point, it is almost a direction translation of the renderer implemented in the book mentioned above. However, the book above is in native C++, so I have had to translate the intent of the architecture into the .NET way of doing things (was quite fun since I've never written or programmed against a runtime “plug-in” architecture before).

I have also implemented all the functionality for logging in the application. The initial plan is to have all modules log to their own log file. Logging will be able to be turned on and off at the flick of a switch. Currently, I have it implemented where logging always occurs if in debug mode. I currently have logging calls placed throughout some of the loading routines. The actual determination of whether to log or not is in the Logger class itself, so the modules aren't having to check whether they should log or not for every call. This may need to be optimized out in the future. But until it is proven that the overhead of the potentially useless method calls is too high, I am sticking to my guns and doing it this way.

Now that I have the bugs worked out in general plugin architecture, the plan is to move the code from my research directory into the final game engine directory and to start game engine development. Before I do that though, I plan on writing up an NAnt build script so that the build order and the moving around of assemblies is handled properly. Because of its flexability, I prefer this way as opposed to pre and post build steps in Visual Studio.

Until next time....

Posted on Sunday, September 5, 2004 3:08 AM Game Development | Back to top

Copyright © Jason Olson | Powered by: