(Part 1: “Hold on lads, I’ve had an idea”)
Why ask?
I come from a systems writing background. I’m the guy who typically writes the code that makes big web applications work. Rich comes from a different background. He’s more game based.
Recently our business has taken our skills and combined them into the area of serious games. This means that my current skill set is important for supporting the games, but I’m a great believer that in order to be able to help provide solutions for something, that you need to understand what that something is.
With this in mind, I decided that I needed a reasonable knowledge of how a game is put together. So, as my side project I thought I would have a go at writing a basic game engine.
OK, but why a game engine?
There are loads of choices of game engine for the budding game creator, so why on Earth would I bother to write a game engine? Well, I’m the sort of person learns faster if I put things into practice. I find that once I’ve actually solved a problem myself, that the concepts really stick. So the main answer to this question is to learn, and reinforce my learning with a working example.
Plus, it’s kinda fun for me in a slightly sadistic way!
That must be a lot of effort?
Yes, to write everything would be a lot of effort, but I have two things on my side here.
The first is that as this is a learning exercise for me, I have no expectations or illusions that this process will produce a commercial grade game engine, in fact if we ever use it for an actual purpose other than me learning then I would be extremely happy. This means that I’m really not that bothered about it being particularly pretty code, or even that it’s that robust so that will save a lot of effort.
The second, absolutely massive thing on my side is that there’s already all the tools you need to put together this application out there in the form of open source libraries. I don’t intend to be writing all my own rendering code for example, there are choices already out there that are far better than I’d ever do, so I’ll be learning the concepts of rendering from the use of the library that I choose.
How would you even approach this?
My general philosophy for writing a game engine will be as follows:
“Get it good enough, then move on”
I don’t need to be agonising over tiny details to learn what I need here, so I’ll get something going, then move on. In fact, I’ve found this is a pretty good approach to software generally. Chances are you’ll miss something and have to change how you’ve done something anyway so why go to the effort of making the code completely beautiful and watertight if you’re likely to throw it away anyway? I’m going to be getting it going, keeping it modular so that I could replace bits of functionality easily and only beautify my code when I’m reasonably sure I’ve taken the correct approach (OK, for this engine I might never beautify it!)
I hate philosophy, get on with it already…
OK! OK! So my thinking is that games are made up of several subsystems, such as:
Rendering subsystem
Logic subsystem
Audio subsystem
Input subsystem
So this is the approach I’ll be taking — I’ll be hacking together several subsystems that will be reasonably self contained, with a big loop at the beginning that prods each subsystem to do something every iteration. My plan is that for the major subsystems, I’ll find a decent library to do all the heavy lifting for me.
Next time…
I’ll be spending some quality time with everyone's favourite search engine to try to find some libraries to use, and I’ll let you know my conclusions…
Comments