Game Development Reference
In-Depth Information
chapter 8
Programmers don't fully test their own games. They don't have time to, and even if
they did, it's not a good idea. Back at the dawn of the videogame era, the programmer
of a game was often also its artist, designer, and tester. Even though games were very
small—the size of email—the programmer spent most of his time designing and pro-
gramming. Little of his time was spent testing. The programmer of
Astrosmash
,a
space shooter for the Intellivision system, made an assumption when he designed the
game that no player would ever score 10 million points. As a result, he didn't write a
check for score overflowing. He read over his own code and—based on his own
assumptions—it seemed to work fine. It was a fun game—its graphics were breath-
taking (at the time) and the game went on to become one of the best-selling games on
the Intellivision platform.
Weeks after the game was released, however, a handful of customers began to call with
complaints. When they scored more than 9,999,999 points, the score displayed negative
numbers, letters, and other non-numeric symbols. This was after the catalog described
the game as having “unlimited scoring potential.�? The problem was exacerbated by the
fact that the Intellivision console had a feature that allowed players to play the game
in slow motion, making it much easier to rack up high scores. John Sohl, the pro-
grammer, learned a hard lesson:
The user will always surprise you
.
Almost all game testing is
black box
testing; testing done from outside the application.
No knowledge of, or access to, the source code is granted to the tester. Game testers
typically don't find defects by reading the game code. Rather, game testers try to find
151
