Home > Audio, Core/System, Graphics, Icanos, Input, Introductory, Main > Structuring an Engine

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!

About these ads
  1. No comments yet.
  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Follow

Get every new post delivered to your Inbox.

Join 76 other followers

%d bloggers like this: