Game Development Reference
In-Depth Information
'
'
From a programmer
t have to clean up your
mess, so to speak. A lazy programmer can create systems that are so entangled they
can
s point of view, it is easier, but you don
'
t be torn down in an orderly manner, and that can be a bad thing. If something
can
t be torn down during runtime, you have no choice but to allow it to exist
whether it is being actively used or not, and console resources are so tight you still
want every byte. Also, if you ever want to be able to load a new level into memory,
something has to exist in your codebase to remove all the resources in that level and
return the system to a pristine state.
I propose a dual solution
—
the release build should reboot, exit the game all at once,
and take as little time as possible. This is for the player
'
s convenience. The debug
build should attempt a clean exit, and any problems with a clean exit should be
addressed before they become a cancer in the rest of your system
'
—
especially memory
leaks.
Games have a lot of moving parts and use every bit of hardware in the system. Get-
ting all the green lights turned on in the right order can be a real pain, as you saw in
initialization. It
'
s really easy to have dependent systems, so much so that you have
“
chicken and egg
”
problems
—
where more than one system has to be first in the ini-
tialization chain. I don
t have to
hack something horribly to make initialization work correctly. Start with a good
organization, and hopefully your problems in this area will be minimal at best.
Shutting down cleanly is critical under any multitasking operating system like Win-
dows, not only to make sure system resources like video memory are released, but it
also helps the engineering team to know that the underlying technologies can be torn
down in an orderly manner. It doesn
'
t think I
'
ve ever worked on a game where we didn
'
'
t guarantee good technology, but it is a good
sign of clean code.
