Building Your Game - Game Coding Complete - page 103

copy the Game directory whenever they want. The test group grabs Game and Test,
and they have everything they need.
If you store the build targets in the Source directory, like Visual Studio wants you to,
you

ll have to write complicated batch files to extract the build target, clean tempo-
rary files, and match game data with executables. Those batch files are a pain to
maintain and are a frequent source of bad builds. If you pound Visual Studio for a
little while to get a better directory structure started, you won

'

' t have to worry about a

nasty batch file during the life of your product.

Where to Put Your Game Engine and Tools
In case it wasn ' t clear, your game engine should get its own directory, with the same
directory structure in parallel with your game. On one project I worked on, our game
engine had a pretty uncreative code name: Engine. It was stored in an Engine direc-
tory with Source, Docs, Temp, and Lib instead of Game, since the output of the build
was a library. There was some debate about separating the #include files into an
Inc directory at the top level. That s a winner of an idea because it allows the game

engine to be published with only the #include files and the library. The source code
would remain safely in our hands. The source code that is a companion to this topic
is divided into GameCode4, which can be considered the engine, and Teapot Wars,
the game that uses this engine. GameCode4 compiles into a library, which is linked to
game-specific files to create the final executable, so the final result of a complete
rebuild is stored in Game. You could have the engine compile itself into a DLL, in
which case a post-build step would copy the DLL into the Game directory. To play
the game, you should be able to copy only the contents of the Game directory to a
player

'

s computer, and the game should run as expected.
Tools can be a little fuzzier and depend somewhat on whether the tool in question is
one that is a custom tool for the project or something that everyone on every project
uses. As you might expect, a tool for one project would go into the source tree for the
project, and one that everyone uses would go into the same directory hierarchy as
your shared game engine. If neither seems to fit, such as a one-off tool to convert
some wacky file format to another, and it would never need to change or undergo
any further development, perhaps you should install it into a special directory tree
for those oddballs. Basically, the rule of thumb is that any directory tree should be
under the same kind of development: rapid, slow, or completely static.
If your game needs any open source or third-party libraries to build, I suggest putting
them in a 3rdParty directory inside your Source directory. This makes it easy to keep
all the right versions of each library with your code base, and it is convenient for

'