Geeks With Blogs

News

Series

Add to Technorati Favorites


An Archived Managed World This blog has moved to http://www.managed-world.com/blog

After talking last night about integrating a collaboration pattern I was working on at work with a coworker, I have decided to go a different route. I stubbed out the framework tonight for a Microkernel that will drive the game engine. The current version as it exists tonight is very simplistic. The only current functionality in this Microkernel is the ability to add a Task for per-frame processing.

This new Microkernel should help decouple my system a bit more and make it easier to enhance. For instance, instead of your "usual" game loop where you might actually see direct calls to game objects to update themselves, in this system you basically see one call to the TaskMaster within the Microkernel instead. So, if I have a GameStateManager and GraphicsDriver that both need to be updated once per frame, they would register tasks with the Microkernel. This means that when I am "boot-strapping" the game, I essentially am hooking up the components into the TaskMaster. In the case above, you would see something like "taskMaster.Attach(new CallbackTask(gameStateManager.OnUpdate));" and "taskMaster.Attach(new CallbackTask(graphicsDriver.OnUpdate));".

Where this tasking system really starts to shine is when you start doing animations. For instance, if I am implementing a 3-second respawn feature into my game, I can create a special task like "new WaitTask(TimeSpan.FromSeconds(3));" and then attach a SpawnTask as a child task to the WaitTask (so that it is automatically called when the wait time has elapsed). That's just one minor example. There's a whole slew of other examples if we go into the GUI world.

Eventually this TaskMaster will grow and probably have the ability to do "time sharing". I'm thinking of adding that feature in the future so that I can time slice the Tank AI since the AI will be implemented in scripts by the end user (yes, you programmers). This will ensure that a Tank doesn't hog too much time when updating itself and should ensure that every tank is on a level playing field when it comes to processing time.

Tomorrow I will probably start on a MessageProcessor to the Microkernel that will enable cross-sub-system communication within the engine. After that, the Microkernel will probably be done for a while. I might eventually expand the Microkernel to support a virtual file system as well for game files, but I don't want to put the cart in front of the horse here. The more I think about, the more I feel that this is almost like implementing a mini-OS in software that is specialized to running a game. Pretty fun stuff.

There are some other things I've been thinking about though. I've been thinking about introducing a service layer that would host services that would be stateful and would basically drive the underlying functionality in the engine. You might see a GraphicsService, a ScriptingService, a PersistenceService, a GameObjectService, etc. Then the various Message handlers would communicate with a ServiceLocator to get references to the different services in order to do their deeds. This pattern is an adaptation of the pattern I've said that I'm working on at work so hopefully being inspired by that won't take too long :). The ServiceLocator does seem to be quite Spring'ish after a while, but that should be fine. Heck, if I eventually want to power it off of Castle or Spring.NET I could do so if I choose to.

Anyways, off to bed for the night. As usual, I'll keep you updated on the latest happenings in the development of Tanks :). 'Til thenz, my friendz.

[Crosspost from Managed World]

Posted on Wednesday, May 17, 2006 6:05 AM Game Development | Back to top


Comments on this post: Tanks - Update 7

No comments posted yet.
Your comment:
 (will show your gravatar)


Copyright © Jason Olson | Powered by: GeeksWithBlogs.net