Game Development Reference
In-Depth Information
Games are much more than source code. A typical game includes raw and optimized
art and sound data, map levels, event scripts, test tools, and more. Don
'
t forget the
—
project documentation
both the docs that ship with your project, such as the user
guide, and the internal documents, such as the technical design document (TDD),
general design document (GDD), and test plans.
There are two essential problems that all these files create. First, the sheer number
of game files for art, sound, music, and other assets need to have some rational
organization
there can be hundreds of thousands of these files. Games like Age of
Empires Online and Battlefield 3 easily have many hundreds of thousands of asset
files in production. Some online games like Star Wars: The Old Republic may have
breached one million asset files. With this many files, it can be really easy to lose
track of one, or a few hundred. The second problem is the difficulty of ensuring
that sensitive debug builds and other internal files are kept separate from the stuff
that will be shipped to consumers. The last thing you need is to release your debug
build, with all its symbols, to the public at large. The best setup lets you segregate
your release files from everything else so you can burn a single directory tree to a
DVD without worrying about culling a weird list of files. Over the last few years,
I
—
ve settled on a project organization that solves these two problems.
The process of building a project should be as automatic as possible. You should be
able to automatically build your game every night so that you can check your latest
work. A game that can
'
'
t build every day is in big trouble. If you want an easy way to
get a project cancelled, just make it impossible to fulfill a build request at a moment
'
s
notice.
The directory structure, project settings, and development scripts you use should
make building, publishing, and rebuilding any previously published build a snap. If
your source code repository supports branching, like SVN or Perforce do, you
'
ll be
ahead of the game because you can support multiple lines of development simulta-
neously. For those of you who haven
t used source code repositories, they are
server-based archives files that can be checked out to developers like a person might
check out a book from a library. When the developer is finished with that file, he
checks the file back into the server, and it makes the most recent version available
to everyone. Unlike a library, source code repositories are good at allowing the same
file to be modified by multiple developers and allowing all their changes to merge
together when they are done. Branches are
'
of groups of these files, typically
meant for developers to sequester them as a group for a specific purpose, such as
walling them off
“
copies
”
from rapid changes or doing research without affecting other
