When developing a new game, the first thing you should consider is your high level game architecture. You’re probably going to use some 3rd party libraries, maybe you already have some in-house libraries that you’re going to use, or develop them for future use. How these things fit together seems obvious, but when you consider following architecture, it will save you a lot of time and frustration later on.

The high level architecture that I’ve developed over the years has 3 layers:

|                        |
|      Core Game         |
|                        |
| In-house Game Library  |
|                        |
|  3rd party libraries   |
|    - Sound             |
|    - Graphics          |
|    - GUI               |
|    - ...               |

The Core Game only contains code specific to the game. Try to move as much generic code to your in-house game library, this way you can reuse it when you’re working on other games.

The in-house game library contains on one hand the generic code that can be shared between multiple games, and on the other hand acts as a facade on top of 3rd party libraries. This means that the core game never calls the 3rd party libraries directly, but always passes through your in-house game library.


Since your core game is only using your own inhouse game library, you have total control over the API that it calls. Switching 3rd party libraries or custom made has no impact on the game code. You can also extend the external libraries with some functionality that you can write on top of them. When interface changes are made in newer 3rd party libraries, you don’t have to find/replace in your game code, adapting the in-house game library is enough. Porting multiple games also becomes easier, because once your in-house game library is ported, no major adaptions are needed in the core games.

Koen Witters

Categories: Programming


Mark · August 11, 2009 at 23:12

Doesn’t 3th sound awfully weird to you? Say it. Three-th. Weird. It’s 3rd :p And major*.

Found one of your other aticles interesting… this one doesn’t quite apply to me yet, haven’t got that far. Will be reading a bit more from you.

Max · November 27, 2009 at 16:58

This is exactly what I was thinking of doing while working on my next game. It’s nice to see that somebody else has this kind of mind set as well.

Koen Witters · January 6, 2010 at 09:34

Thanks for pointing out those spelling errors, they are fixed now :).

Niriel · June 14, 2011 at 05:55

I’m lucky to have chosen python for writing my game. I could afford a ‘slow’ language because I’m not aiming at creating the next Crysis MMO, but something looking a bit like the old-school zelda games, 2d seen from above. Python comes with so many useful libraries that the only third party library I have is pygame. That makes things easy. Not only I abstract pygame away, but I do it in an model-view-controller fashion. My game would work as well with another rendering engine, or two at the same time, or even no engine at all. I’m thinking of having a curses renderer for the lolz and get a nethack look :p.

I’m still struggling with the networking though (my game is multiplayer, say half a dozen friends). I really really really don’t want to use Twisted because I find it fat, ugly and invasive (it wants to steal my main loop). Some third party libraries like twisted are very hard to abstract. Same goes for GTK by the way. Imagine both together… So I have to write my own networking code when I’m not good at it, and my own widget/gui/buttons code because pygame doesn’t have one and I like none of what’s been done so far. Decisions…

Exporting RPG Maker games to iPhone, Android or other platforms – Koonsolo Games · March 21, 2014 at 13:35

[…] ‘real’ port will need to happen. Since my code base is structured in a way described in this blog post on how to structure your game code, only the generic game library will need to be ported. This is not an effort that is currently in […]

Leave a Reply

Your email address will not be published. Required fields are marked *