Role of the Game Engine

I’m currently working a new game engine, after working, or not working as the case was on Astrum Futura. I think one of the flaws of Astrum Futura game engine, was that it was a game foremost. A game engine should center around common items that belong in any game. The trick is to build it in a way that allows extensibility of the core along with the game features.

For example, I should be able to start out with an administration panel that manages the common areas, but the game will also have various administration panels that need to be to be added. It can’t be in another area either. Both the game adminstration and the game engine administration have to enmesh transparently from the user and the developer.

Likewise, the game engine should have features added to it and have those features easily added to the games that depend on it. Therefore, the game engine is developed separately from the games. If they are developed in unison, then care needs to be taken to make sure that the game features don’t too tightly intertwine with the game engine.

Choose a Framework

There is almost no reason to start from the ground up, when coding a game engine. There are enough good to great frameworks out there that it isn’t necessarily. Using a framework cuts time out of writing parts that you will need to support later and cuts features that you won’t have time to work on.

Take care with what the license is of the framework, if you plan to use it for commercial products or distribute. The license is again important, if you plan to distribute the game for free or for profit. Some frameworks have dual licenses, which give you the ability to code in them for free, if it isn’t a commercial product, but require a fee if you are going to charge. Reading the fine print, may well save some headache later.

Deployment of the Game Engine and Game

Version control (ex: Subversion) should be used for development of the game engine and game. This will allow the deployment of the game with the game engine to be easier. Updating the game with the game engine will also be quicker.

To give an example, I have a WordPress theme, which is under version control and I update the WordPress site using Subversion. I don’t have write access to the WordPress repository, so it is impossible to add my theme to WordPress to update both at the same time. The point is that I really don’t have to.

What I do, is create a directory or directories where I want them outside of the WordPress version control and checkout my code into those directories. Therefore, when I run the deployment script, it will update WordPress and my site specific files from both, separate, repositories.

You can use this technique for your game engine, if you set the directory structure correctly. You can checkout the game engine repository on your site and create the directories on the host machine and then checkout the files from the game repository into those directories.

For most simple games, this should work fine. For others, it might make more sense to add the game engine to your game repository to give yourself more fine control over the directory structure and what features actually go into the game.

The game engine also won’t have any game related features, so you won’t be able to download the game engine and “play” it. You should still be able to use it to test the front end and back end. The goal at least is to have the game code, be just that game code and focus the game engine code on managing the components and non-game specific features.

Features of the Game Engine

These features belong in all games and therefore should be part of the game engine to prevent having to rewrite the same code over and over again. Separating out the features of the game from the engine might be slightly difficult, but if you can use it 98% of other games, then it belongs in the game engine. You may also develop a game library, where components that you think can be reused again (but don’t belong in the game engine) can exist in a location to be reused, if needed.

  1. Administration Panel

    You will want to manage most features, tasks, and settings in the administration panel. It can slow down the execution depending on how you save the settings, but it is well worth it to have it instead of finding the location in the code where the setting is. It is much easier to pull up a browser and surf to the location, than it is to FTP or update the repository, which depending on the location, you might be forced to checkout the repository and install the version control or FTP software.

    There are other portions of the game management that you can’t or don’t want to give other administrators access to. You don’t want to give more people access to the database or files than you have to for security reasons. If one of those people goes away, then you’ll need to change all of the passwords.

    For example, is it much easier for an administrator to go to the user management panel and remove a user, than it is to go to the user table, remove that user after finding the ID, and then going through all of the other tables and removing the rows that belonged to that user. It is also less prone to error to use administration panels. At least, if there is a bug, you can fix it in one location. Human error is a lot more difficult to correct.

  2. Authentication and Authorization

    This also includes the administration to manage the users and roles respectively. This is an important component of every game and doing it once and doing it well will go a long way. The best part is that if you fix or extend the component, then upgrading every game to the game engine will also automatically have the better implementation.

    The fun part about Authentication, is supporting OAuth and OpenID. These features are often more involved and it is better to only do them once, in case there is a defect or you add it later.

  3. Content Management Features

    You can handle the specific game content however you want or need. Most games have game information before any authentication, and you can achieve this by physically creating the pages. It will be faster, where code development is concern to create the pages physically. It depends on your needs. If you using the Model-View-Controller paradigm, then this method might be somewhat difficult depending on the framework and how you developed the game engine.

    There are a lot of games that have announcements on the homepage, as well as pages. It might then make sense that, if you are already creating a system to handle the news, that you extend that to include pages. If you are uncomfortable creating your own table structure, then you can even use the WordPress one. You might have to create your own API, depending on your license and the game engine environment. It would be a little much having to create the WordPress environment along with the game engine environment and game’s environment.

    There are other components that could fall under the category of CMS, Questions and Answers, and forums can too. I don’t think game developers should write their own forums, there are many existing web applications which do it and do it well. The purpose of the game engine is to allow focusing on the game as much as possible. For forums, there are phpBB, bbPress, and commercial forums. As for the FAQ or Questions and Answers component, it appears to be bad form from the lack of such a feature on “professionally” made PBBG. If you want to do it, then no one can tell you otherwise.

    The game engine should focus its features as much as possible on centering the User Experience around the game and side projects and features, at least if done poorly, take away from that experience. If you are going to have them, then develop them separately from the game engine.

  4. Keeping It Simple

    The nice part of the game engine is that you can do whatever you want with it, no matter the recommendations of others. You can go crazy and try to include every feature you can think of. If you release it, others will use it just for the extra perks. That is to say, that if you want to take the time to create it, then do so, however, the focus is on the game and keeping the game engine simple will do just that.

    I don’t subscribe to the “Web 2.0″ philosophy, but it makes sense, that adding the kitchen sink can be, well, distracting. If you require all of the other features, then there is something wrong. That said, helping the user, might also include a manual on how to use the game engine and the game as well. Having a user manual is a great device to enhance the user experience.


The primary goal is allowing games to be built off of the base of the game engine, so it has to allow for the game to function on top of it. Preferably one that does so easily. There shouldn’t be any right or wrong way to go about achieving this, as long as it works.

The way I’m going to try to implement this is by having directories for the game controllers, views (by way of themes), and libraries. The goal I have for my game engine, is that you check out the game engine and then checkout the game code in directories in several documented places. This should allow me to update the game engine at the sites that use it easily, while allowing for the game code to also be updated easily and exist outside of the game engine repository.

Part 1 of the Game Engine Building Series: I’m going to document the development of my game engine over the next few months pertaining to observations and notes from the development.

Wish there was more?

I'm considering writing an ebook - click here.


Tuesday, January 13th, 2009 design
  • Sounds cool, I'm currently working on an engine for my game, its pretty fun, although very frustrating :P

blog comments powered by Disqus


Building Browsergames is a blog about browsergames(also known as PBBG's). It's geared towards the beginner to intermediate developer who has an interest in building their own browsergame.


Got Something to Say?

Send an e-mail to, or get in touch through Twitter at