The Shining Source

I've put up a first draft of my game engine notes here: A Kernel Based Game Engine. It's missing a lot, but it's a start. It describes the type of engine used by Shining Online.

This approach adds some complexity, but I've found it makes adding new features much easier.

As mentioned elsewhere, I like this article! Perhaps we should put it on the Source as well?

I want to clean a few bits up, but once it's ready I'm happy to put it in the articles section here. I might go into a little more detail about the various services, particularly the way screens are handled. Any suggestions welcome, as always

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

They can be prioritized.

The way I have things set up is for each service to have a renderPriority and updatePriority. The kernel also has a list of updatable services and one for renderable services. This allows services like the debug console to update first and render last.

Whenever a service changes its priority it fires which causes the kernel to re-sort both lists, so they don't need to be sorted every cycle.

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.

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.

It's a pretty clean way of doing things, and gives enough flexibility without too much initial work. I'm still fleshing out some of the details, but so far I'm pleased with how it works.

I highly recommend reading over the Service Locator pattern. It's not the approach I've used, but I did try to incorporate some of the elements when building the kernel/service model.

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.

I did some work on things yesterday, and so far I've got 4 different types of service:

• Services that update every cycle -- This includes the event service, the debug listener service (listens to file changes and reloads resources) and the entity system
• Services that render every cycle -- Non-interactive overlays
• Services that update and render every cycle -- Mostly the game screen service
• Services that do nothing -- This is stuff like resources, application configuration, the rules database (such as resurrection rates, health bar colours and interface layouts) and content database (stats etc)

The services that don't update or render probably don't need to be services, but it makes it easier as they can be retrieved elsewhere using a common api. Because they're not in either the render or update lists there's no performance penalty either, so for now I'm happy with how they work.

I'm also integrating a component-based entity system for handling game objects (NPC's, interactive objects etc). It's still rather rough around the edges, but once it's working properly and it can spawn objects I'll write about it. I've done a lot of work on this in the past, so I'm trying to pull the various systems I've built together into something nice.