Game Development Reference
In-Depth Information
{
if (variable < VARIABLE_MINIMUM)
{
throw (
“
Parameter is invalid
”
);
}
// More code follows...
}
The first function resets the errant variable and calls the
GCC_ERROR()
macro to
alert a programmer that something has gone wrong. The execution continues, since
the variable now has a legal value. The second function throws an exception, clearly
not allowing the execution to continue.
The debate most programmers have goes something like this: If you ever reach code
where an assert condition in debug mode evaluates to false, then something has gone
horribly wrong. Since you can
'
t predict the nature of the failure, you must assume a
worst-case scenario and exit the program as elegantly as possible. After all, the failure
could be bad enough to corrupt data, save game files, or worse.
The other side of the argument takes a kinder, gentler approach. Failures can and will
happen, even in the shipping product. If the program can fix a bogus parameter or
ignore corrupt data and continue running, it is in the best interests of the player to
do so. After all, he might get a chance to save his game and reload it later without a
problem. Since we
re working on computer games, we have the freedom to fudge
things a little; there are no human lives at stake, and there is no property at risk
due to a program failure. Both arguments are valid. I tend to favor the second argu-
ment because computer games are frequently pushed into testing before they are
ready and released way before testing is completed. Bugs will remain in the software,
and if the game can recover from them it should.
'
Some Bugs Are Acceptable, Aren
'
t They?
Never forget that your game
'
s purpose is entertainment. You aren
'
t keeping
an airplane from getting lost, and you aren
s heartbeat.
Remember that games can get away with lots of things that other software
can
'
t reporting someone
'
t. If you are relatively sure that you can make a choice to allow the
game to continue instead of crash, I suggest you do it.
'
Of course, this is true unless you work on a massive multiplayer title,
and you are working on anything server side. Bugs here affect everyone on
the server, and they can result in actual lost value for players and, in turn,
the company. In that case, you get to code and test every bit as carefully
as the programmer down the street working on banking software.
