Jump to content
  • Advertisement
Sign in to follow this  
  • entries
  • comments
  • views

'Engine' mk.II

Sign in to follow this  


I finally decided to make use of the holidays and I've sat down to redesign my 'engine'. I hate the word because it's so vague and meaningless, but at the same time it's the easiest way to describe what I'm talking about. It's just a set of classes that are common throughout my demos/games.

Firstly I was quite taken with the idea of smart pointers, after reading Superpig's Enginuity articles. I decided to implement them, and use them for the main elements in the engine (dropping the 's for ease of typing). My implmentation for the moment is much like Superpig's. It took me a little working out to get it right though, as that was the first proper use of templates I had done.

After that I've pretty much struck out on my own, for better or worse. I figure that's the best way to go. The main idea around the structure is that there is a central Kernel (although not necessarily the only Kernel), and the kernel serves as a sort of "router" for the rest of the structure. The application and the various components - GLRender for OpenGL Rendering, SDLInput for SDL Input etc - register themselves with the kernel, as well as requesting a certain set of messages. So the application would probably request initialisation, destruction, update, rendering and input messages, but the SDLInput component might only request initialisation, destruction and rendering. Each component can then send messages to the kernel, and the kernel will disperse the message to each of its children that requested that message. This way none of the children need to know what other children are in use, but can let the kernel deal with that at runtime.

The pros and cons that I can see are:


  • The components do not need to be aware of each other, the kernel sorts out getting messages to the right destinations.

  • I could set up a system to add remote children - children across a network. ie. I'd then add a kernel as a child of another kernel and likely the opposite too. This sets up a peer-to-peer kind of system, so that update messages can run through several kernels. I could then have one kernel as a "server", and several others as "clients", children of the "server". The clients can send messages to the kernels (updates depending on user movement/whatever) and vice-versa. So there's no extra design setup for networking.

  • The engine is modular, in a way. I can take out the rendering component, and nothing changes. This way I can also use this framework for text-based or other type programs.


  • I need to package things up in message format, rather than using function calls. It becomes a little bit more hassle than simply calling a member function.

  • I don't know how much of a performance hit I'm going to get from doing things like this. I'm trying to optimise the kernel as much as possible, but it might end up being slower than I think.

  • It might end up that children that only want some messages end up getting messages they don't need. I don't know how common that will end up being, and how much that will slow things down by.

In the end I think I'm just going to have to go for it and see what happens.

I'm also trying out doxygen in this project, because my previous projects have all been way undercommented. I've got a slightly old set of docs up here which you can look at if you're interested.

Anyway, engine design is much the pain in the neck.
Sign in to follow this  

1 Comment

Recommended Comments

Anyway, engine design is much the pain in the neck.

In Former Soviet Union, neck is pain in the engine! Err..

My humourless comments aside, I find that 'compromising' on engine design works the best for me. As you've seen for yourself, writing a fully fledged well-designed engine is both a lot of work and and a lot pain, although you do eventually get the payoff of having a very flexible system when it's all done. What I'm doing (and usually do do) is write an engine that has less flexibility than the supermonster you're concocting, but since less design needs to go into it beforehand, and less worry about flawless modularability (not a word!), it's more fun to write than something like yours. However, it also isn't as flexible in the long run. Either way it's a pretty balanced win/lose scenario. I code for the fun of coding, so I evade the painful torture of a perfectly honed engine that requires endless painstaking planning. So far it's been working! ^_^

Good luck!

Share this comment

Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!