Game Development Reference
In-Depth Information
The Assets directory is going to store all your art, animation, and sound assets in
their raw, naked form. This directory is likely going to get huge, so make sure the
source control system is configured to filter it out for people who don
'
t care about
it. I say
these assets
are those not used by the game directly, but those that are used by artists, designers,
or sound engineers while they are working on them. Think of it as the same kind of
directory that programmers use for their code. When the assets get imported or
packed into game files that are used by the game directly, they
“
raw
”
and
“
naked
”
not just because I enjoy putting it in print
—
'
ll be inside the Game
directory where all the distributable stuff lives. One more thing
—
the Assets directory
will be a huge, complicated hierarchy that will most likely be created to appease the
whims of artists or sound engineers, so don
t expect to have much control over it.
The source code lives in the Source directory. It should be organized by the program-
mers in whatever manner they see fit. The project
'
s solution file or makefile should also
reside in the Source directory and be named according to the code word for the project.
The rest of the source code should be organized into other directories below Source.
When a project is being built, each build target will place temporary files into the
Temp directory.
Each build project, building configuration, and platform can be segregated into their
own directories underneath Temp. For example, the OBJ and other temporary files
for the Debug configuration of the GameCode4 project compiled with Visual Studio
2010 for Win32 can be stored in Temp\GameCode4_2010Win32Debug. Doing it this
way makes it very easy to create a directory structure that supports multiple compiled
targets, multiple compilers, multiple platforms, and multiple build configurations. If
you think you might not need this, think about building a project for both Android
and iOS
'
because being able to store the results of a build on a server might be very
convenient, and if you don
—
'
t give each build flavor a safe place to live, they might
overwrite each other.
Visual Studio Defaults Aren
'
t Always So Great
Visual Studio does a really bad thing by assuming that software engineers want
their build targets to clutter up the Sourcedirectory. I find this annoying, since I
don
t want a single byte of the Source directory to change when I build my
project. Why, you ask? First, I like to be able to copy the entire Source
directory for publishing or backup without worrying about large temporary
files. Second, I can compare two different Source directories from version to
version to see only the deltas in the source code, instead of wading through
hundreds of useless .OBJ, .SBR, and other files. Third, I know I can always
delete files in the Temp directory to force a new build of the entire project, a
particular platform, or a particular build configuration of all platforms. I also
know that I never have to back up or publish the Temp directory.
'
