Game Development Reference
In-Depth Information
Ask a programmer how long it will take to find the random memory trasher bug, and
he will shrug and say something like,
“
I don
'
t have any idea! A few hours maybe?
”
You may find that same programmer, 48 hours later, bashing his head against the
same bug, no closer to fixing it than when he started.
These setbacks happen all the time, and there
'
s not much that can be done except to
get as much caffeine into the programmer
s bloodstream as he can stand, get the
other programmers to take up the slack in the bug debt, and maybe lend a few
more neurons to the problem. Don
'
'
t forget about the advice earlier in the topic:
Any two programmers looking at the same problem are at least three times as
smart as a lone programmer.
When the bug is eventually found, there is often a decision that has to be made about
the nature of the solution. A simple hack may suffice, but a
“
”
solution exists that
will touch a lot of code and perhaps induce more risk. At the very late stages of a
project, I suggest hacking. Wonton, unabashed hacking.
Some of you may be reeling at this sacrilege, but I
real
m sure just as many of you are
cheering. The fact is that a well thought-out hack can be the best choice, especially
if you can guarantee the safety and correctness of the change.
'
“
Hack
”
is probably a
bad word to use to fully describe what I
m talking about, because it has somewhat
negative connotations. Let me try to be specific in my definition:
Hack - n
. A piece of code written to solve a specific corner case of a specific problem,
as opposed to code written to solve a problem in the general case.
Let me put this in a different light. Everyone should be familiar with searching algo-
rithms, where the choice of a particular search can achieve a
'
or a
“
best solution
”
criteria. At the beginning of a project, coding almost always follows
the
“
first solution
”
path, because there is sufficient time to code a more complicated,
albeit more general algorithm. At the end of the project, it is frequently the case that
the best solution will lead a programmer down a complete reorganization of an entire
subsystem, if not the entire code base.
Instead, games have a
“
best solution
”
tgeneratethe
game data. Since the game inputs are fairly predictable, or even static, the problem
domain is reduced to a manageable level. A programmer can be relatively sure that a
specific bit of code can be written to solve a specific problem, on a specific map level,
with specific character attributes. It seems ugly, and to be honest, it is ugly. As a friend
of mine at Microsoft taught me, shipping your game is its most important feature.
The hack doesn
“
get-out-of-jail-free
”
card, because the players don
'
t have to live in the code base forever, although it frequently does. If
your game is even mildly successful, and you get the chance to do a sequel, you
'
