Abstraction in Game Programming – A Guide

In my limited experience in the development world I have run into a huge problem for programmers that many do not always seem to realize. This problem comes with the idea of abstracting code. Or, in other words, making code more flexible and usable in multiple situations. So here I am going to write a guide for myself and for anyone else who is interested on how far you should abstract your code in different situations.

DISCLAIMER! Let it be known that I am in no way an expert or a seasoned veteran of the industry and this guide could be completely wrong so take it as you will, but as it is this comes from my personal experience on the topic and I find it valuable. To each their own and I hope that you do take something away from this post either way.

Anyways! To help understand what I am trying to convey here is a key to some of the terms I will be using.

Levels of abstraction key

- No abstraction – Code that must be replaced so it can be maintained without an abundance of issues.
- Low level abstraction – Creating base-line abstraction for objects that needs to be done for the game to succeed.
- High level abstraction – Most objects are generic and/or extremely flexible.

So, let’s start with creating a game!

When you are developing a game you should be using low level abstraction. Why? Because the high level abstraction should have been done while developing the game engine. When developing the game itself you should stick to creating just what is needed for the game to succeed. Not only does this save time but it also keeps you from the pitfall of creating a game engine on top of a game engine. Milliseconds of performance time should not be something you should worry about. Make the code usable and maintainable. And if you have a connection to the internet, make it secure.

A game engine (and this should encompass your physics engine, AI engine, sound, graphics, etc.) should be high level abstraction. There isn’t much of a point of creating a game engine that will be used for a single game. If you are an independent developer and you wish to create a single game you should either use a pre-existing game engine or build on top of a framework (such as DirectX or OpenGL) using low level abstraction that will do only what you need to be done and that’s it. Pretty simple idea, right? I have seen many developers fall into the black hole of attempting to create a whole game engine for a single game with a User Interface and all only to never see the game actually produced.

Creating a prototype. This should be done within a 2-4 week period and it is completely acceptable to hack your way through this for a few simple reasons. This isn’t the final product. You need to have as much functionality done as possible in a small amount of time so the people you are pitching your game to have a better understanding of what your game should eventually look like. Once you secure money (which should directly relate to having more development time) this code should be, for the most part, scrapped. Prototypes should have little to no abstraction to save time. Prototypes are completely for the visuals and to try and convey an idea.

As mentioned before, an AI engine should be high level abstraction because odds are you will be using the same AI again in another project.

Creating a tool that does a very specific job should be low level abstraction.

If you are having a problem determining how abstract your code should be simply ask yourself these questions:

How much time do I have to make this?

Will this code be re-used/is it necessary to make this code re-usable?

Am I creating software for a developer or for a player?

Once you have done that it should be easy enough to decide how abstract you need to make your code.

Thank you for reading and good luck on your next project. :)

This entry was posted in Blog and tagged , , , , . Bookmark the permalink.