Structuring an Engine
So, I have previously mentioned that we’ll be making a game engine, and I have put some resource management code up as well.
Now I don’t want to get into too much detail with the engine until we’ve seen a little more of SFML, but perhaps it would be nice if I gave you a vague idea of what I’m planning.
Well the first version of my engine will contain the following components:
- system
- graphics
- audio
- input
System Module
This is the simplest to explain. There is nothing fancy here, just a few auxiliary classes to help us out later, for example by managing resources or archive files. In fact, I have the following features planned:
- resource manager (some code already up)
- archive manager
- process managers
- event log
- some basic core features (we will add these as we need them)
Graphics Module (2D)
Predictably, this module will handle loading images and drawing them to the screen.
The way I hope to implement this is by means of a graphics object type. That is, a class which defines an arbitrary graphical object, with various images and animations, as well as a position and the ability to be drawn.
This core will also have a general engine type, which will handle any necessary setup and shutdown operations. Importantly, this engine will have a list of all graphical objects. Each frame it will check if each one needs to be drawn, and if it does, then the engine will see to it that the correct frame of the correct animation of the object is drawn to the screen at the right location.
Audio Module
This one is analogous to the graphics module. It handles loading and unloading of music and audio files, as well as playing them
Just as the graphics module does, the audio module will have a list of aural objects. It will ensure that their sound effects are played at the correct moment. Music will be handled separately from these objects, handled directly by the engine.
Input Module
Again, this module will have an “object based” structure. There will be input objects, and the engine will ensure that all the appropriate objects are informed when an input event occurs, e.g. if an object is clicked on or a key pressed.
Main Engine
There will then be a main engine component to draw all the others together. This engine will have one of each of the other engines as member variables of the main engine class.
We also here define game objects. These are objects with a position and facing, etc. and also pointers to an object of each of the other types (graphical, aural, input). These pointers can be set to null, however, to refrain from using a particular object type (e.g. a stone on the ground must have graphics, but does not need to make sounds or react to input).
Conclusion
Well that’s all for now. I know this post is a little cursory, but hopefully it will give you an insight into the structure I have planned for my engine. I just wanted you to see this now, as we won’t be actually coding this for a while: we have some preliminary tasks first!
