A Little Motivation

Games are much more than source code. A typical game includes processed art and sound data, map levels, event scripts, test tools, and more. The raw art and sound files are usually stored on a network or a secondary storage area because they are huge. 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 functional specs 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 thousands of these files. Word has it that games like Age of Empires have hundreds of thousands of asset files in production. 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 burned onto the optical media. The best setup lets you burn a single directory tree to a test CD/DVD without worrying about deleting anything.

Over the last few years I've settled on a project organization that solves these two problems. But wait, there's more. 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. Even dumb producers know this so if you want an easy way to get a project snuffed, 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 a published build a snap. If you're lucky you'll have a nice source code repository like Perforce or CVS, and you can use branches to separate milestone builds from code under heavy development. It's a pain to stop coding just because everyone's paycheck is dependent on a milestone build!

Everyone does things differently but the project organization, build scripts and build process you'll learn in this chapter are hard to beat. I figure that if they're good enough for Microsoft, and they got our projects out the door on time, I'll keep them.