these testers will work with you over the course of the project, they will have a better
understanding of the game and why it has developed as it has. And as I mentioned
before, if you are unable to call in favors with friends who have this much experience,
you may want to consider hiring a design consultant to come in periodically over the
course of the project and critique your work.
As you are implementing the GUI and the controls, it will make sense to bring in
some first-impression testers to experiment with these new controls. Set up a simple
test level, area, or situation where players can attempt to use the controls and GUI, and
see how well these testers fare. This makes sense since the most important aspect of
interface and control design is that these systems are as intuitive as possible, and the
best way to determine that is by having some first-time players try them out. It should
not take very long to determine if your I/O systems are intuitive, since if players do not
figure them out immediately, you will know your game needs work.
As the game becomes more complete, when a majority of the features are complete
and a large section of the game is playable, it makes sense to bring in the traditional
testers to go over the work. This period is typically called “alpha,” though this defini-
tion varies from company to company. When they first start testing, the traditional
testers will find a seemingly endless number of bugs in the code, as they try all manner
of actions that the development team had never anticipated, but you should encourage
them to look beyond the bugs and give you feedback about the gameplay itself if they
can. Of course, getting feedback at this early stage is much better than in “beta” when,
if the project is on a tight schedule, the focus will be less on refining the game and more
on getting it out the door. At some point, you stop being able to make fundamental
changes to the gameplay for fear it will break the game in some major way. As a result,
you will need to make large-scale alterations while there is still plenty of time to track
down all the bugs they may cause. Even with simple game balancing, without time to
fully test the repercussions of a change, you stop being able to change anything for fear
it will throw something else off. This is why starting gameplay testing early enough
that you can still fix the problems is so essential.
On projects with tight deadlines and “must ship by Christmas” edicts, manage-
ment sometimes likes to think that they can speed up development by bringing in
testers early, sometimes long before the game has even reached alpha. This way, they
erroneously think, once the game finally gets to beta it will already have had most of its
bugs removed and can be shipped immediately. Of course, what they fail to understand
is that, before a game is “feature complete,” it is likely to change fundamentally from a
code point of view. As that code changes in major ways, old bugs are eliminated com-
pletely while new ones are introduced. If the testers point out bugs in old code and the
programmers have to spend time fixing them, this is essentially wasted time since
those bugs would have been eliminated completely later when chunks of the code were
rewritten, and you are still left with the new bugs that the restructuring of the code will
bring about. That said, it may make sense to bring on a small group of very experienced
testers earlier who can do targeted testing of specific systems the development team
thinks are ready for testing.
To some extent, the same holds true for gameplay. When large parts of the game
are missing, having testers report problems like “Levels 10, 12, and 17 have no ene-
mies to fight and are therefore not much fun to play” is far from useful. Forcing
490 Chapter 25: Playtesting