development team and the preliminary testers that may have been brought in. Now that
there is a broader range of people playing the game, the designer will likely observe a
broader range of playing styles than he had anticipated. The testing period is when the
designer can make the game accepting of these playing styles, allowing players to truly
play the game their own way on their own terms.
Of course, the designer cannot be present for all of the playtesting the game will
undergo, not if the game is going to be thoroughly tested and released in a reasonable
time frame. Often you will need to rely on what the testers report to you about their
playing experiences. Though not as useful as watching the testers play firsthand, this
information can nonetheless be quite helpful. When you do get this feedback, it is cru-
cial to truly listen to what the testers tell you. This may seem obvious, but it is
surprising how many designers prefer to ignore the feedback they get on their game.
Often most of a game’s testing, particularly that done by traditional testers, takes place
late in the development process, after a good deal of work has gone into the project. At
this point the designer is probably fairly confident that the game is working as he wants
it to work. Therefore, it can be difficult for the designer to hear testers contradict this,
perhaps pointing out fundamental problems in the game that the designer has over-
looked for months of development.
The designer’s first defense is often to claim that the testers do not know what
they are talking about. Excuses can range from the tester being a fool to the tester not
being the target audience for the game to the tester just complaining for the sake of it.
Granted, often testers do make suggestions for changes to the gameplay that are best
avoided, and if only one tester out of ten suggests that a certain piece of gameplay
needs to be changed it may be because of that tester’s personal preference. But when
the designer hears the same complaint from a number of different testers, he needs to
realize that there probably is something wrong with the game that needs to be
addressed. The testers may not even be complaining about the right aspect of the game
or suggesting an appropriate fix, but the fact that something is ruining their experience
warrants investigation. The designer must avoid dismissing the complaints of testers
and honestly look at each complaint to see if it has any merit. It is amazing the number
of designers who will resist any and all suggestions the testers make. Often, these
same designers come to regret their obstinacy later when the game is finally released,
only to have players and members of the press complain about the same issues the test-
ers had complained about earlier. Of course, once the game is released, it is too late to
do anything radical about the problems.
Guided and Unguided Testing........................
One can divide the kind of testing being done on the project into two distinct classes:
guided and unguided. Guided testing customarily happens earlier in the project, when
the game is not yet completely functional. In that period, the designer knows what por-
tions of the game are clearly incomplete, but wants to get some feedback on a section of
the game he thinks is working fairly well. Then the designer may direct the testers to
try a particular level or section of gameplay. Directed testing may also occur later in the
project, when the entire game is functioning but a particular section has just been
changed or reworked. At this point the designer may need feedback on just that section,
492 Chapter 25: Playtesting