Core and subsystems overview

I think it's time I started talking about the specifics of the current Derange design, so I think I'll start from the core.

The Derange core -or kernel if you prefer-, is divided into the Core class and a few derivations of the SubSystem class, each dealing with specific areas of functionality. They need to be accessed by the rest of the engine all the time, as they do the "lower level" stuff, making things shorter to develop and easier to maintain afterward.

Some of them also encapsulate the functionality of some of the third-party components I use. That way, if I ever decide to switch to a different component to do the same task, I keep the original subsystem interface, and just adapt the inner workings.

The core can be configured by modifying the configuration file, which is an XML file with things like desired screen resolution, rendering options, resource locations, etc. When instanced, it instructs each subsystem to initialize itself and in turn, shutdown. More importantly, it starts the game loop.

Here are some subsystems and a brief description of what they're supposed to do:

• Input: Provides access to any available input devices. Right now it's basically an OIS wrapper.
• Resources: Allows to access and keep track of game resources like meshes, material scripts, textures, shaders, XML files, locations, actors, etc. It should do so in an efficient way -for example caching or sharing resources across requests-, so that if it's asked for a specific resource multiple times, it only gets loaded once.
  
• Video: Provides means to change how things are rendered, and it also creates the Ogre3D render window. Keeps the game loop running until exit is requested.
  
• Scripting: Allows to execute Lua scripts, which tell the engine what to do.
  
• Scene: Allows to create, access, destroy and keep track of all the game objects that interact in a single scene. It also notifies them when they should be updated.

click to enlarge

As you can see in this class diagram, all subsystem classes inherit from the Subsystem class, which implements the Singleton design pattern. This is because it only makes sense to have one instance of each subsystem. Additionally, the Subsystem class has access to the engine configuration, as specified in the XML file.

All classes in Derange derive either directly or indirectly from the CoreObject class. This way if I need to introduce any changes that should be applied to every single class, like for example keeping a count of instances and amount of memory used, I can do it from a single place.

So, when an instance of the Core class is created, it creates an instance of each subsystem class. Then it starts the game loop. And when it's done, it destroys the instances it created. Each subsystem is responsible for both initializing itself and cleaning after its own mess upon shutdown.

As Derange keeps growing, I'll most definitely add at least a couple more subsystems (for example one to handle all audio), but at this stage those should be enough.

I might disclose details on how each subsystem works soon, but I think I'll take a few days to tidy them up a little. As I was writing this post, I noticed some really dumb design mistakes that I previously overlooked.