Game Development Reference
In-Depth Information
Rewriting Your Graphics Engine Without Killing Your Game
When I was at Super-Ego Games, we landed a deal with Sony to make Rat
Race on the then-unreleased PlayStation 3. None of us had ever made a
console game, and the engine was very PC-centric. We devised a scheme
we called the Render Skin. This was a layer of abstraction where all
graphics and sound functionality would live. The entire thing was made up
of a series of interface classes that wrapped some piece of functionality.
The appropriate implementation classes were instantiated at runtime based
on compiler flags. Once we got this system working, we were able to
replace our old DirectX rendering system with a new rendering system that
worked on the PS3 without keeping the designers or gameplay programmers
blocked. None of the code that called into the Render Skin knew or cared
which engine it was using, so the graphics programmers could port
everything over without stepping on anyone
'
s toes.
Another great benefit of using interface classes is they reduce compile time depen-
dencies. The interfaces can be defined in a single
#include
file, or a very small
number of them, and because they hide all the disgusting guts of implementation
classes, there
'
s very little for the compiler to do but register the class and move on.
Games tend to build complex objects, such as controls or sprites, and store them in
lists or other collections. A common way to do this is to have the constructor of one
object, say a certain implementation of a screen class,
all the sprites and
controls. In many cases, many types of screens are used in a game, all having differ-
ent objects inheriting from the same parents.
In the topic Design Patterns: Elements of Reusable Object-Oriented Software by Erich
Gamma et al., one of the object creation patterns is called a factory. An abstract fac-
tory can define the interface for creating objects. Different implementations of the
abstract factory carry out the concrete tasks of constructing objects with multiple
parts. Think of it this way
“
new up
”
a constructor creates a single object. A factory creates
and assembles these objects into a working mechanism.
Imagine an abstract factory that builds screens. The fictional game engine in this
example could define screens as components that have screen elements, a back-
ground, and a logic class that accepts control messages. Here
—
'
s an example:
class SaveGameScreenFactory : public IScreenFactory
{
public:
SaveGameScreenFactory();
