give you. This is why picking a random person off the street to test your game can
sometimes be ineffective, since you have no past experience with him and hence do not
know whether you can trust his opinion or not. When you do have experience with a
particular tester, you will be able to know if that person has any shortcomings. For
example, some testers can be best described as “whiners” who complain about every-
thing, even things that do not need fixing. Other testers may be shy, only saying,
“Maybe you should look at the power of the Elephant Rider unit,” when what they truly
mean is, “Obviously, the Elephant Rider completely throws off the game.” Try your
best to understand the personalities of the testers you will be working with; it is key to
effectively using the feedback they give you. And in the end, regardless of the testers’
tendencies, if a number of them bring up a similar issue, then something probably is
wrong, even if they are diagnosing the problem incorrectly. Similarly, if you have
enough random people off the street tell you something is amiss with your game, it is
probably worth investigating.
Who Should Test.............................
There are various types of playtesters a project may have, and it is a good idea to have
some from each group working on your project. No one type of tester can provide all of
the feedback you need for your project. Indeed, it makes sense for there to be a good
number of testers, since having a broad range of opinions can be essential to getting
beyond individual bias and understanding if your game plays well or not. While argu-
ments can be made for keeping the size of your team small, especially in terms of
designers and programmers, with playtesters more truly are merrier.
The first type of playtester is a member of the development team. These are cer-
tainly not the only testers you should have, and some would not technically consider
these people playtesters. However, throughout the project, it is important to have your
team members playing your game. This serves multiple purposes. First, it keeps them
enthused about the project. Assuming development is going well, they see to what end
their art, sound, code, or level construction is being used. Second, as they see their
work in action, they are better able to understand how it might be improved. And third,
they can provide you feedback about how the game is working and what you might do to
improve it. Toward the end of the project, in particular, as all of the art, most of the code,
and the levels are completed, the members of the development team will be able to pro-
vide essential feedback about sections of the game that might need some last-minute
improvements. Of course, members of the development team are very close to the pro-
ject, and as a result may be far from objective in their comments about it. Furthermore,
since they have been playing the game for so long, they will have trouble seeing it with
a fresh set of eyes and their opinions will be skewed accordingly. Also, since they have
contributed to the project, they may tend to like or dislike their own work for personal
reasons. Similarly, they may like or dislike the ideas of other members of the team not
because of the merits of the ideas themselves but rather because of their opinions of
that person. Despite these drawbacks, getting playtesting feedback from the members
of your team is essential.
The second type of playtester to have is the traditional playtester. This is someone
who starts playtesting your game around the stage it enters “alpha” and is actually fully
playable, and continues until the project ships. Often these playtesters spend half of
Chapter 25: Playtesting 485