Ultimate Game Design : Building game worlds

166
ONCE
your game environment has come together into a cohesive
whole with all basic actions, activities, and controlled behaviors
built in via script, trigger, code, or any combination of these, you are ready to
start getting some feedback from players. Developers have differing work styles and
opinions about exactly when an entire game, level, mission, map, arena, or scenario is
ready for delivery to the quality assurance (QA) or game-testing department.
As a general rule, the game content that you hand over to QA should be stable and
functional enough to be considered playable (fundamentally navigable, functional,
and operational—but not nearly perfectly so). Remember, there is an extended period
of time during the early development of your game project when the game you’re
building is nowhere near playable. A “game” doesn’t even exist yet. You have only
primary art and technology objectives starting to mesh together. If your team handed
off a game to QA at this point, it would clearly be way too early to obtain any meaningful
feedback (nothing game-wise is happening yet). Before submission to any QA department,
you need to wait until the game content is “playable enough” to be clearly representative
of your game ideas as they unfold in execution.
In this chapter, we’re going to look at the operation and influence of QA on game
building. We’ll look at the important role that QA plays in helping improve and refine
game builds (game version iterations), and we’ll stop to consider just how valuable
play-test feedback can be in helping to create a game that is a satisfying and rewarding
experience for players.
Q UALITY ASSURANCE
The purpose of a QA or test department within a developer or publisher is to improve
the quality of gameplay for a game title by testing it for bugs or errors and giving play
feedback and content suggestions to developers. These folks, known as game testers,
or simply testers, play games for endless hours, attempting to track down or shake
out all the bugs or errors that have a negative impact on the play experience. They are
your last line of defense before your game hits the public. If your development team
thinks QA personnel are overly critical of their game (at least the testers are getting
paid something to play it), just wait until the less-than-merciful public gets a shot at