Building Your Game - Game Coding Complete - page 99

programmers. Branches can even be merged together, such as when mass changes in
one branch need to be brought to another — this might be done after installing a new
physics system or renderer. There

' s a whole section about this later in this chapter

called ”

Everyone does things differently, but the project organization, build scripts, and build
process you

“ Source Code Repositories and Version Control.

re good
enough for Microsoft, and they got our projects out the door on time, I

' ll learn in this chapter are hard to beat. I figure that if they '

' ll keep

them.

Creating a Project
This might sound a little hokey, but every project I work on has its own code word. I
picked this up from Microsoft, and I love it. You should let your project team choose
the code word, but try to make sure that the name chosen is somewhat cryptic. It s

actually really convenient if you end up at the bar with a bunch of software develo-
pers from other companies. You can talk all day about finishing a build for

'

“ Slick-

rock ” or that “ Rainman ” needs another programmer. Cloak and dagger aside,

there s a real utilitarian reason to use short code words for projects.

You can use this code word for your top-level project directory and the Visual Studio
solution file (SLN file) that builds your game and tools. It is an easy step from there
to create a standard build script that can find your key project files, build the game,
and even test it. If you work in a studio with multiple projects, a master build server
can easily build every project in development every night and take very little mainte-
nance to add or remove projects.
Beyond that, a code word for a project has one other use. If you end up making mul-
tiple versions of the same product, you can use different code words to refer to them
instead of version numbers. You are ready to start your project, so choose a code
word and create your top-level directory. May whatever gods you believe in have
mercy on your soul:

'

mkdir <codeword>

Build Configurations
Every project should have two build targets at a minimum: debug and release. The
release build will enable optimizations critical for a product the customer will actually
use. Many projects also have a profile build, which usually disables enough optimiza-
tions to allow for debugging but disables code inside #ifdef DEBUG constructs to
allow it to actually run in real time. It ' s a good idea to have all three targets because