Game Development Reference
In-Depth Information
'
used that same game engine. The engineers didn
t have to worry about how things
were rendered or how to display a text box, they just used the tools in the engine to
make it work.
I
ve been an engineer in the video games industry for nearly seven years as of the
writing of this topic. I
'
ve worked on a number of different games, from tiny iPhone
apps with only a few people to huge triple-A games with nearly 200 people, each
using a number of different game engines. Some of those games used a commercially
available engine as the core, while others were developed from scratch. All of these
different game engines had their strengths and weaknesses. Over the years, I
'
ve
found a number of universal patterns, both good and bad, that have cropped up in
nearly every game I
'
ve worked on. Before we dig into the meat of rendering, sound
effects, AI, and other juicy game development topics, I
'
'
d like to provide a foundation
of core architectural principles. These are the things to keep in mind when you are
developing large systems. Trust me, they
ll save your butt in the end.
One thing worth noting is that are as many ways of doing things as there are pro-
grammers. The techniques and philosophies presented in this chapter are the
result of my own experiences. You will probably find things in this chapter (and
book, for that matter) that you disagree with. That
'
re a
programmer. You and I can debate endlessly on the Internet about the best ways
of doing things. Just remember, neither of us is wrong
—
just different and
opinionated.
Let
'
s great! It just means you
'
s start by looking at design practices that you should consider when writing a
game, and then we
'
ll move on and look at specific programming techniques such as
working with pointers, memory management, how to avoid memory leaks, and other
goodies. In the last part of this chapter, I
'
'
ll provide you with a few coding tools taken
from my own personal toolbox.
If you walk into a room full of programmers and ask them about how they name
their variables or where to place braces, you
ll find the conversation soon turning
into an all-out holy war. Programmers are very opinionated about coding style. It
makes sense
'
—
we spend the vast majority of our time staring at code. In the end,
there is little difference between all the various styles you see. I have a particular
style I use for my own projects that works very well for me. You might hate how I
name my variables or how I use camel-casing for function and class names, and
that
s just fine. You should do whatever works for you; however, there are a few pit-
falls I
'
'
ve come across that I
'
d like to share with you.
