I've been out of commission the last couple days with food poisoning, but after having read all the articles you posted, I like the idea of entity systems very much. Since I was going to use a database anyway, I probably would have been using an entity system without much of a system. I think this is a valuable design model and I'm surprised I've never seen it before.

Good stuff!

I'm checking out all the stuff you linked. It looks like good stuff so far. I'm a big dungeon siege fan, so reading those articles was fun. I'll post again when I have a more coherent opinion.

As I said at SFC, I'd like for you, me, and TY to be able to cluster around a central design so that we, and maybe others can contribute services which can make it into finished games.

Actually, the more I think about it the more I like combining our designs. Each service can determine how it wants to straddle the line between the two choices. If it ignores the queue completely then it becomes the same as what you have now, but if it queues everything then it becomes the same as mine.

The kernel can invoke each service in two steps, the first in the normal way, and the second by emptying the queue. If the queue is disabled, then each service operates at maximum performance, while if the queue is always emptied completely then each service operates at maximum quality. A setting in the middle would require emptying the queue for a given amount of time before flushing it.

The service in question can determine how it wants to split performance/quality by how much it uses the queue, and users can determine how they want to split performance/quality by how much of the queue is emptied.

I like the idea of registering services. I like both our ideas for managing services. I think each has its merits, and I'd like to find a way to combine them so that there is something a sliding scale, where a coarse segmentation turns it into your method and a fine segmentation turns into mine. The only problem is the difference in handling the priorities, which is what gives each method its strength.

Your method is much more efficient if the number of services is small or their priority doesn't change often, while mine is good at handling lots of services that are always in flux but is less efficient in general. My initial thought is to turn my essential queue into a services manager like you have, since the essentials will always need to be done and it's unlikely their priority will change much, but then having a priority queue for non-essentials that each service can use to manage their non-essential tasks.

Is there anyway to prioritize the services, or do they have to be registered to the kernel in the order they will be executed?

As the mythical man month says, you build one to throw away. The first one will never be right. However, having said that, if you don't have a plan then you can sort of wander around aimlessly. I think that too much unit testing is a bad thing, but some unit testing is good because it gives you a benchmark to aim for that was setup before you really started coding. I think agile is a bit extreme for me, but having something that works is a huge morale booster and I often iterate when I code.

At the end of the day, programming is about problem solving. Of course, you need the right tools to do the job, such as knowledge of algorithms, data structures, computation, etc., but you also need the ability to think critically and think outside the box.

Cool game Ty, especially considering how long you had to work on it.