Game Development Reference
In-Depth Information
Chapter 3
by David “Rez” Graham
That Saved Me
On December 5, 2005, I walked onto the fifth floor of an old office building in down-
town San Francisco. There was a door near the elevator with a simple piece of paper
taped to it that said
The entire office held less than a dozen peo-
ple, almost all of them programmers. This was my first day as a professional video
game programmer. I had been making my own games for about nine years at that
point so I figured I had a major leg up. I was completely wrong. Being able to render
3D models on the screen, play sound effects, read input devices, and implement
gameplay features are all extremely important parts of making video games, but
there
'
s another more subtle beast lurking in the shadows that is just as important:
architecture.
Architecture refers to the structure of your game code and how all of the little pieces
fit together. An engine with good architecture can be reused over and over to make
games that are somewhat similar to the games that came before it. There are certain
problems that every game faces, such as loading assets from the hard drive and ren-
dering objects onto the screen efficiently. These problems are often tailored to the
specific type of game you
'
re making. For example, culling out objects from render-
ing in a scene efficiently often requires different techniques, depending on how your
level geometry is laid out. Worlds that are mostly indoors tend to use different tech-
niques from worlds that are mostly outdoors. Most of the time, different engines
tailor their architecture toward a specific type of game. If you grew up in the 80s
and 90s, you might remember the old Sierra adventure games when they started
using the point-and-click interface. There have been dozens of games that have
“
Super-Ego Games.
”
53
