Game Design: Theory and Practice (2nd Edition) (Wordware Game Developers Library)

When is the right time to start playtesting your game? As I have discussed earlier in this chapter, playtesting can be a key part of your game s development cycle from as soon as you get your game playable until it is finally released. That said, there are specific times when particular types of testing are best applied, and other times when certain types of testing may be ineffective or even pointless. Knowing when to use each type of tester is key to not wasting their time.

Of course, your development team should be playing the game as much as possible through all the phases of its development. As I have mentioned, this is essential to keep them interested in the project and to enable them to do the best work possible. Assuming the game is not falling apart, a developer who knows exactly how he is contributing to the project and how that project is turning out will be better informed and motivated to do his best work possible.

Early playtesting is best done by people experienced in game development, whom you know very well, and whose opinions you hold in high regard. Early playtesting requires that the tester overlook many problems: the game crashes frequently, all of the art is place-holder, sections of the game are obviously incomplete, there is only one level to play, and so forth. Many people, when given such a game, will be unable to look beyond these extreme shortcomings. For instance, traditional testers, even if you tell them to ignore the large sections of the game that are missing, will most likely start pointing out the completely obvious bugs that need fixing. However, a fairly experienced QA lead will understand the development process better and can start providing valuable feedback fairly early in the project. Additionally, a friend who is also a game designer will be able to look at the work and see beyond its current shortcomings, seeing instead if the game shows promise. These designers have seen their own projects in the state yours is currently in, and understand why not everything works yet. These experienced professionals will be able to recognize and explain fundamental problems your game design contains better than anyone else.

It makes good sense to establish a small group of people whose opinions you trust and whom you can show your game to at various stages of development. These may be fellow game designers, as discussed above, or friends who understand the game development process and will be able to provide you with useful feedback. Over the course of the project, you may want to keep showing your game to this trusted group , so they can see how the game is progressing and give you their opinions on whether they like where the game is going and if they think that direction is the best one possible. Since 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 definition 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, management 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 completely 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 enemies to fight and are therefore not much fun to play is far from useful. Forcing designers to go through these meaningless bugs will waste far more time than it may save. It makes the most sense to bring in the traditional testers only when the game is in a state that is truly appropriate for testing. In the end, bringing them in too early will only delay the game s progress.