Game Development Reference
Third , read over the steps in your path until you are satisfied with them. You guess that
if you repeat them, the defect will occur again.
Fourth , reboot your computer, restart the game, and retrace your steps. Did you get
the crash to occur again?
Fifth , if you did, great! Write it up. If you didn't, change one (and only one) step in
your path. Try the path again, and so on, until you successfully re-create the defect.
Unfortunately, games can be so complex that this process can take a very long time if
you don't get help. Don't hesitate to discuss the problem with your test lead or fellow
testers. The more information you can share, the more brainstorming you can do, the
more “suspects�? you can eliminate, and the sooner you'll nail the bug.
Play testing is entirely different from the types of testing discussed so far in this topic.
The previous chapters have concerned themselves with the primary question of game
testing: Does the game work?
Play testing concerns itself with a different but arguably more important question:
Does the game work well?
The difference between these two questions is obvious. The word “well�? implies an
awful lot in four little letters. The answer to the first question is binary; the answer is
either yes or no. The answer to the second question is far from binary because of its
subjective nature. It can lead to a lot of other questions:
Is the game too easy?
Is the game to hard?
Is the game easy to learn?
Are the controls intuitive?
Is the interface clear and easy to navigate?
And the most important question of all:
Is the game fun?
Unlike the other types of testing covered so far, play testing concerns itself with mat-
ters of judgment, not fact. As such, it is some of the most difficult testing you can do.