I’ve seen plenty of posts over the years about “how to playtest your game”, but relatively few on “how to be a good playtester”, so I thought I’d post some thoughts about this subject. I am probably the last person who should write this, because I violate almost all of the items below on a regular basis. But having been a part of Spielbany for a number of years now, and having benefited from having many great playtesters try my own games, I think this list of suggestions may be helpful.
- While the game is running, write down, rather than vocalize, your comments and suggestions. This has two benefits. It keeps the game on track, preventing it from getting bogged down by a lengthy discussion about this rule or that system. And, it gives the designer something tangible to take away from the session, in case his mind or note-taking is inadequate to fully keep up with the discussion.
- Be constructive. Very few games are completely hopeless. Be sure to tell the designer whatever good points the game had, because even if the game is awful and needs to be scrapped, there may be good mechanisms or good ideas that the designer could port over to another game.
- Be honest. On the other hand, don’t sugar-coat negative feedback. Be honest about the things that aren’t working, and say them, as politely but as directly as possible.
- Be specific. Too many testers simply say “that was interesting. What are we playing next?” Try to give concrete examples of aspects of the game that worked well or aspects that you found problematic. Saying “I didn’t like the auction mechanic” is vague; saying “I didn’t like how the once-around structure of the auction forced me to guess what later players were likely to bid” is specific and helpful.
- Emphasize your experience as a player. Avoid talking about your aesthetic appreciation for the clever blend of mechanisms, or the really original theme he came up with (or at least, talk about these things only briefly). Comment instead on your visceral reaction to the game. The reality is that for a game to grab a publisher and the game-buying public, it has to make a strong impression. Avoid using vague and bland words like “fun” or “interesting”. Don’t exaggerate (“that was completely exhilarating!”), but talk about how the downtime between turns caused your attention to drift from the game, or how losing that battle in the 4th turn due to a bad die roll was frustrating, or how the decision to buy or sell that stock share was agonizing. Don’t tell the designer the game was “good”, or that you had “fun” — was the game merely “pleasant”, or was it “a nail-biter”, or was it “hilarious”, or something else? Try to communicate the level of enthusiasm (or lack thereof) the game produced in you, and be specific (see point 4) about the elements of the game that contributed to that experience. Anything that got in the way of a high level of enjoyment may be superfluous or counter-productive, so the designer should look to remove these elements, in favor of the ones that produced a favorable reaction.
- Describe areas of confusion. In-progress games can be rough, and as the game changes, the designer’s facility with teaching it may be less than with a published game with a fixed ruleset. But these considerations aside, what about the game made it difficult to learn, and what rules did you find confusing? At what point did your confusion about those aspects subside (or are you still confused about them even after playing?)? What about the physical presentation in the game made it easy or hard to play?
- Call attention to other similar games. Designers haven’t played everything, but they need to know about other games with similar themes or similar mechanisms, to ensure that they aren’t recreating something that already exists, and to be aware of other games that may compete for players’ attention, and dollars. Mention elements that the games share and point out differences. Resist the temptation to say which game is “better” — saying “your game is way better!” sounds patronizing, even if true, and saying “the published game is better” is unnecessarily discouraging; of course the designer already knows his game still needs more work, so there’s no benefit to him to hearing that he’s not there yet.
- Focus on problems, not on solutions. This sounds counter-intuitive, but it’s true: you are not responsible for fixing the game for the designer. Tell the designer what isn’t working in the game, and leave it to him to find a solution for it. (Certainly, if he asks for suggestions about how to fix the problem, you can offer any that you have thought of).
- Make suggestions sparingly. Too often, a playtester provides lots of suggestions for ways that the game could be different, without necessarily making it obviously better. I am terribly guilty of this. There is benefit to this sort of brainstorming — it may nudge the designer to think in different ways than he had previously. But it can also lead to a lot of parallel moves in design and development, and as a designer, games take long enough to develop, and playtester time is sufficiently precious, that you don’t want to meander too much; you want design progress to be unidirectional. Make your “list of other things you could think about or try” the very last, and least important, thing you say to the designer, or perhaps simply write them down (see point 1) as a bullet pointed list and hand them to the designer, for him to contemplate.
- Understand the designer’s goal for the game, and take this into account with your comments. A designer who is working on a light press-your-luck game may not really benefit from your suggestions for ways to make the game deeper and more strategic. Ask the designer to lay out his vision for what the game is supposed to be in its final state, and aim your suggestions and feedback along the lines of helping him to achieve that vision, rather than making the game more like your own personal preferences. Although it’s difficult, a good playtester can hang up his own preferences at the door, and accept and critique the game exclusively on the game’s own terms.
No related posts.