After a Game Engine, You Can Program Anything

July 17, 2015

Previously I’ve chronicled the path I took to indie game development. When I did so, I mentioned that I developed my own game framework and engine for the Sleuthhounds games. Recently I joined a local group of indie game developers and it’s been interesting to see the different approaches people take to building games. One question in particular was interesting to me, why did I decide to make my own game engine?

The question was asked out of curiosity and not in any sort of condescending way. And it was a very legitimate question. These days there are many flexible free game engines out there such as Unity, Unreal, and Gamemaker to name a few. The games I develop are point-n-click adventure games and there are even a number of game engines specifically targeted to them such as Adventure Game Studio (AGS) and Wintermute.

However, even with these different options out there, I decided to create my own game framework and engine. Believe or it or not I had a couple of reasons in mind when I started.

First and foremost, developing a game engine seemed like a really interesting programming challenge. With all the different aspects that go into a game – graphics, audio, control handling, etc. – it seemed like a unique problem solving task to get all those aspects working together.

The second reason was that it was obviously a great learning opportunity. Each of those aforementioned different aspects had a whole associated body of knowledge to learn and work out. Take, for example, the key component of graphics. There’s quite a lot that goes into making game quality graphics appear on screen:

  • Most Windows machines (because my game engine is Windows based) support different screen resolutions. You have to know how to look up (“enumerate”) all those resolutions and choose one appropriate for your game or allow the player to choose one from a list.
  • If you want your game to fill the monitor then you have to figure out how to run fullscreen. And you have to figure out how you want to handle things like the player tasking to another application or hitting the Windows key which triggers the Windows Start menu to display automatically (many games “kill” this key when running).
  • Once you’ve picked a resolution you then need to prep the graphics card to draw (“render”) your graphics. If you’re using 3D tech like OpenGL or DirectX this involves a good chunk of work to specify all manner of technical parameters on how graphics should render.
  • Of course, being able to render is useless unless you actually have something to render (unless your game generates all of its graphics on the fly programmatically, which is a big challenge in and of itself). So you maybe need to load 2D images or textures from graphics files or 3D models from their files. So now you have to understand those file formats and have a way to efficiently and quickly load them when needed.
  • If you allow players to change game resolutions on the fly, the way many video cards work requires that you reload any graphics objects you’ve created. So somewhere in your game you have to maintain a list of what those objects are and know how to recreate them on demand.
  • Oh, and there’s the special case of displaying text along with your graphics. And how do you get those text images in the first place. Are they exactly that, predrawn images like any other graphic file you might have? Or do you generate them from one of the fonts installed on the player’s computer?
  • And of course, if your game is behaving properly, it should clean up after itself when it ends. This means properly shutting down the graphics system you’re using.

And all of this stuff is just for handling the graphics. In the grand scheme of a game engine, the graphic system is just one component among dozens. And the staggering thing is that in any other type of software, any one of those components could be the basis for a full-fledged application in itself. Everything you learn about graphics could be used to develop a painting program or a modelling program. Everything you learn about audio could be used to develop an audio player. Everything you learn about data management could be applicable to a database application. Computer game engines bring all these different pieces together so that you have to know a fair bit about everyting. I can safely say that the game framework and engine I developed for Sleuthhounds is the single most complex piece of software I’ve ever worked on.

There are a lot of benefits to developing your own game engine:

  • You can tailor the engine specifically to the type of game you’re making. Generic game engines have to have a lot of flexibility and options in them so that virtually any game can be created. This added flexibility usually means that there are a lot of options in the game engine that are unneeded for your particular game. At first glance that doesn’t seem like problem, but when you’re trying to find that one function call that you need among the sea of everything that’s available it can become a little tricky.
  • If there’s a specific feature that you need then you can go ahead and add it exactly where you want it. Depending on the pre-built engine this may be tricky to do if it’s possible at all.
  • If there’s an engine bug you can track it down and fix it yourself. Some of the generic game engines don’t give you the source, so if you find a bug you may have to work around it rather than fix it. Even if the game engine you’re using does provide the source, if you fix the source itself and then a new version of the source is released, you may have to remember to fix that bug again if you get the new version.
  • You can get the most out of your own engine. If you built the engine yourself you know what its capabilities are. You know all the little esoteric eccentricities it has and how to exploit them to maximum effect. Basically, by creating your own engine you become an expert on that engine.

One of the greatest benefits of developing your own engine (so great that I didn’t include it in the list above) is the confidence it gives you for tackling any programming challenge. As I mentioned earlier, the game engine I developed for Sleuthhounds is the most complex application I’ve ever done. I had to learn a lot in areas that I had little or no experience in previously. Doing so has given me the confidence to know that, from a technical standpoint, there really isn’t any remaining programming challenge out there that I should be afraid of.

I may have to do some reading and some experimentation, but I know that I can handle anything that comes my way. And that confidence is just one more tool in the toolkit for developing great software.