The Guerrilla Guide to Game Code

Introduction
There are a lot of articles about games. Most of these are about particular aspects of a game like rendering or physics. All engines, however, have a binding structure that ties all aspects of the game together. Usually there is a base class (Object, Actor or Entity are common names) that all objects in the game derive from, but very little is written on the subject. Only very recently a couple of talks on game|tech have briefly touched on the subject [Bloom], [Butcher], [Stelly]. Still, choosing a structure to build your game on is very important. The end user might not “see” the difference between a good and a bad structure, but this choice will affect many aspects of the development process. A good structure will reduce risk and increase the efficiency of the team.

When we started Shellshock Nam ‘67 (SSN67) at Guerrilla Games we were looking for a structure that would be flexible enough to handle all of our ideas, yet strict enough to force us into a structured way of working. The development of our first game Killzone was already well underway so we had a good opportunity to look at their structure and improve on it. After a couple of weeks the base structure for our game had been designed and over the course of the next 2 years a lot changed but our basic structure remained more or less the same.

The core design decisions we made at the start of SSN67 are:

• The system needs to be (mostly) data driven
• It should use the well known Model-View-Controller pattern
• The game simulation should run at a fixed update frequency to ensure consistent behavior on all platforms (PS2, XBOX and PC)

In the remainder of this article these points will be worked out to show how they were implemented in SSN67.

Entities
In SSN67 the base class for all game objects is called Entity. We make a clear distinction between objects that have game state and those that don’t. For example, the static world geometry and its collision model are not Entities, neither is a moving cloud in the sky. The player can’t change the state of these objects so they are not an Entity. An oil barrel, for example, is an Entity because when it explodes it can harm the player and therefore influences the game state.

Using a definition like this makes it very easy to separate objects that are important to the game from objects that are not. Our streaming system, for example, can stream textures and other rendering data in and out without affecting the game state. Another system that benefits is the save game system. The state of an Entity is saved and on reload all current Entities are destroyed and replaced by Entities from the save game. Because all static geometry is unaffected saving and loading is very quick and the resulting save game is small. To go back to our example of a moving cloud: In SSN67 clouds are not Entities and therefore not saved. If you look carefully you can see this.

Most of the Entities in SSN67 need a position and orientation in the world so our Entity by default contains a 4×4 matrix. For those Entities that do not need a position we just accept the overhead.

Right-click here to download PDF version