Game Development Reference
more complete model of all the different experiences the game can create,
instead of thinking of it as a single-threaded story. You'll know all the
different branch points and possibilities that can occur in every situation,
and how they interrelate. You'll be able to predict all the different effects a
design change will have because you'll understand the game as a system,
not a story.
There's no one number of playtests that are needed for this. Different
games generate different breadths of experience, so some games will
need more playtesting before a designer can understand them. In a very
simple, constrained game, this might happen after two or three playtests.
In shooter combat development, it tends to happen with between six and
12 playtests. In unrestricted, systems-driven games, the required number
of playtests could be very large.
A good rule of thumb is to stop playtesting when you start seeing
testers repeating the same experiences often. Once that happens, you can
be reasonably sure that you understand enough of what the game has to
offer to make good design decisions about it.
We can learn most of what we need just by watching a playtest. The tester
will show us where a game is too hard by failing. He will show us where
it is too easy by winning instantly. He will show us where it is unclear by
missing instructions or opportunities.
But sometimes watching isn't enough. Sometimes we need to un-
derstand what happened in the playtesters' mind. This means we need
to ask them.
The problem is that verbal reports are unreliable. Memories are
edited or invented wholesale. The report of the experience is mixed in
with suggestions on the design. The tester's feelings about the designer or
the studio cloud their judgment. The tester doesn't intend to do this; it's
human nature. So to learn anything by talking to playtesters, we have to
form our questions very carefully.
My favorite post-test question is, “Tell me the story of what just hap-
pened in the game.” This question is a memory probe. It discovers what
aspects of the game were perceived, retained, and considered important
enough to mention. Things that aren't mentioned in the story may be dead
weight in the design. Often, I've found that the story that players remem-
ber is very different from the story I intended or the story that occurred.
Search Nedrilad ::