MicroKernel and Tasks

The tricky thing about design questions is that they never make sense in a vacuum; without context and without some pre-decided goals for your design, there's really no good way to choose between alternatives.

A common mistake when approaching architecture is to design the architecture first and then try to cram all of the needed functionality into it. This is, in general, a bad approach. Kernel-style engines are very elegant solutions - to certain types of design problems. It is important to make sure that your particular design problems overlap with the set of problems for which kernel engines are effective.

The first thing you need to do when working on designing an architecture is make a comprehensive list of the problems you need to solve. Here's some quick, common ones - you should be able to flesh this out considerably with a little bit of thought:

• Render graphics


• Play sound effects and music


• Control game elements based on game logic


• Respond to player input

The details of this will depend fairly heavily on your game's design and what you want the game to involve.

Once you've completed this task analysis phase, it's very tempting to jump back into architecture and try to design a full system. Again, this leads to bad results in most cases, unless you're really good at design, in which case I doubt you'd be asking design questions here [wink]

Once your task analysis is complete, you need to do a dependency analysis on each task. Determine which tasks can be done independently, which ones need information from other areas, and so on. For example, game logic typically acts as an information source for every single area of the game: graphics, audio, and so on. Game logic often accepts information from player input, data files, and so on.

Write up a complete list of the dependencies between each area. Then, figure out the order in which you need to do tasks in order for the needed information to become available to each subsystem as it is required. You should be able to find at least one order which permits this nicely; if not, recheck your dependencies carefully. Although it is possible to generate very complex interdependencies, it is quite rare, and if you come up against such a problem, you're facing a genuinely hard design challenge. But chances are you'll do fine and find a good set of options for how to organize things.


It is important to understand, at a fundamental level, how data of all types will flow through your system. That and that alone is the single largest contributing factor to making design decisions - and, unfortunately, it's not something that is mentioned very often.

Hopefully, you'll find that once you understand your information flow, a natural architecture suggests itself quickly. If not, feel free to post your information flow findings here, and I'm sure someone will be able to help you come up with some options for implementing it.

Good luck [smile]