Game Development Reference
In-Depth Information
On the surface this sounds like a cynical approach, but the very fact that testing is built
into the project means that something can't be trusted. You'll read more about this in
Chapter 3, “Why Testing Is Important,�? and in Chapter 5. The very existence of testers
on a game project is a result of trust issues, such as the following:
The publisher doesn't trust that your game will release on time and with the
promised features, so they write contracts that pay your team incrementally
based on demonstrations and milestones.
■
The press and public don't trust that your game will be as good and fun and
exciting as you promise, so they demand to see screen shots and demos, write
critiques, and discuss your work in progress on bulletin boards.
■
Project managers don't trust that the game code can be developed without
defects, so testing is planned, funded, and staffed. This can include testers from
a third-party QA house and/or the team's own internal test department.
■
The publisher can't trust the development house testers to find every defect, so
they may employ their own testers or issue a beta release for the public to try it
out and report the defects they find.
■
Don't take it personally. It's a matter of business, technology, and competition. Lots of
money is on the line and investors don't want to lose it on your project. The tech-
nologies required to produce the game may not even have been available at the time
development started, giving your team the opportunity to create the kind of game no
one has ever done before. By trying to break the game, and failing, you establish con-
fidence that it will work. Games that don't come out right fall victim to rants and
complaints posted on the Internet. Don't let this happen to you!
Balancing Act
Evaluate the basis of your testing plans and decisions. Hearsay, opinions, and emo-
tions are elements that can distract you from what you should really be doing. Using
test methods and documenting both your work and results will contribute to an
objective game testing environment.
Measuring and analyzing test results—even from past games—gives you data about
your game's strengths and weaknesses. The parts that you trust the least—the weak
ones—will need the most attention in terms of testing, retesting, and analysis. This
relationship is illustrated in Figure 1.4.
