San Jose, CA will be hosting the first ever joint Unpub and Protospiel event May 9th-11th. It has been several years since a Protospiel was held on the west coast. Designers are encouraged to bring prototype board games to be play tested. Get feedback from other designers and a wide variety of…
Matt Leacock (@mleacock) on raw prototypes, stolen ideas, blind testing and more:
How to be a good playtester for others:
SEE ALSO: The 5 W’s and 1 H of Good Playtesters
By Doug Levandowski
One of the best parts of being a designer is getting the chance to play your fellow designers’ games while they’re still in the early stages. Every time I’m asked to playtest, I consider it an honor, and I think other playtesters should too. But it’s an honor that comes with some responsibilities. Namely, I have to remind myself that it’s someone else’s game I’m playing, not my own.
When it’s your game, you can tweak it as you go, but when you’re testing someone else’s, you have to be more responsible than that. So, in order to be a good playtester, I’ve tried to think about what I would want from someone playtesting one of my games. And what I’m looking for in a playtester is to focus on six questions: Who, What, When, Where, Why, and How. In addition to being kind but completely honest, I’ve found that making sure I know the answer to these questions before playtesting - or, when the roles are reversed, that I’ve given playtesters the answers to all of them - generally leads to good playtesting.
Who: “Who is the game?”
A few articles ago, I talked about how designers need to think of their games as children. One of the points I made was that sometimes the game knows who it is better than the creator. In this case, though, I’m focusing on the game as having an identity that is, in all likelihood, fixed by the time most playtesters are involved.
Chances are, if you don’t know my embarrassing high school nickname and you’re playtesting something I designed, I’m at least 80% happy with where it is. That means that the core of the game is done. For the most part, it’s already “who” it’s going to be. If it’s a tile placement game, it’s going to stay a tile placement game. If it’s a push-your-luck game, it’s not going to magically transfigure into a Euro beneath the soft fluorescents of the convention room. Know who the game is in order to guide your feedback.
On the other hand, if you’ve spent a week living at my mom’s house when your parents were out of town in high school, my cat peed on your socks one time while you were still wearing them, we’ve been friends for 15-plus years, and we’re sitting in a coffee shop, I might bust out a game that I dreamed up the night before and is currently on four hand-drawn index cards. That bad boy is so early in its development that pretty much everything is up for grabs, including core mechanics and the game’s very identity. I have no idea “who” this game is yet, so I’m asking you to help me figure it out—and it’s fine if it goes from a card-rotation microgame to an idea for a three-hour board game about stopping a world-wide terrorist plot.
What: “What are the rules?”
The statement that concerns me when I’m explaining rules? “I don’t really like to read rules. I pick them up on the fly.” It didn’t used to, but after a few experiences with players like this, here’s what I now (perhaps wrongly) assume when I hear this: This player doesn’t think the rules are that important because they’re so sharp that things will make sense intuitively. And while part of good game design is making the rules generally intuitive, I’ve yet to find a game other than Twister where you don’t need a set of rules the first time.
Second, that phrase tells me that on that player’s second or third turn, they’re going to get frustrated because they didn’t know they could do something—and, if past experience is any indication, they’re going to complain about that exact rule in the feedback session.
Third, you assume that you’re the smartest person in the room—and anything that doesn’t immediately make sense to you is stupid. Part of being a good playtester is coat-checking your ego before you sit down to play.
I don’t want to sound too curmudgeonly here, so I’m going to cut myself off. Bottom line: Make sure you know what the rules are.
There is literally no exception to this rule that I can think of. Rules are almost always more central to a game than theme. If you don’t know them, you don’t know the game.
What: “What feedback do you want?”
This might be the most basic question in the list, but there are two important dimensions to it: what they ask for and what feedback they need to hear regardless.
What they ask for is easy. Often, designers will have specific questions they want answered—and designers who are good at getting playtest data will always have something they want answered (even if they don’t tell you outright). So, if they say, “While you’re playing, let me know how effective you think this card is,” that means that they want to know about that card. Of course.
The exception is the other dimension of the question. If there’s something that’s ruining your experience with the game, let the designer know that even if they didn’t ask for feedback on that—because maybe you’re misunderstanding something or maybe they never thought of it.
But the bottom line is that you have to be honest with your feedback. People have feelings, so always say things as nicely as possible—but if a designer is seeking out playtesters, it’s because they want to make the game better. (At least most of the time. I’ve been in playtests where designers clearly want to know that their design is awesome. Pro tip: You can tell these designers by the fact that they don’t have a notebook out when you’re giving them feedback, and they rarely ask clarifying questions.)
So, assume that they’re sincere in their desire for honest feedback, put it nicely, and let them know exactly what you think of the game.
Where: “Where in the design process is this game?”
Knowing where the game is in terms of completion is going to help you know how much to push a particular issue or how heavily to comment on something.
For example, one of the persistent issues in my game Gothic Doctor is the “Panacea problem”: the luck of drawing a wild card on a random draw. While I like games with a bit of luck to level the playing field between experienced and inexperienced players, luck shouldn’t make it so that the game is, more or less, determined by the luck of the draw. And in the final rounds of playtesting for the game before the relaunch on Kickstarter, we’re going to be doing some very focused playtesting that will ask players to give feedback specifically on how many Panaceas each player used. As a designer, that’s what I’m mainly looking for in feedback—not something as fundamental as the draw mechanic in the game. The game has come far enough along to know that the draw mechanic is going to remain.
Really, this question is about the difference between alpha and beta testing, which in turn determines how much is going to change about the game.
The exception here is really the same one as for the previous question. If you really hate something, you need to let the designer know that, even if they’re far along into the design process and it’s central to the game. In part, this can let the designer know to take the rest of your feedback with a grain of salt. This isn’t to say that your opinion’s invalid, but you just might not be the audience for this particular game. I personally don’t love games that have a very heavy take-that component to them, so if I’m playing a game—even a published one—and the designer wants feedback, they’re going to get that from me. And that might let them know that my feedback shouldn’t be counted quite the same as someone who loves those kinds of mechanics.
When: “When would you like the feedback?”
This one’s simple. Some designers want you to play through the entire game before giving feedback. Some want it on the fly. If they don’t tell you, ask—or assume that they want it at the end. Whenever playtesting, I carry a notebook for exactly this reason (and because I know my memory well enough to know that I’ll forget things in about five seconds).
I assume they want feedback at the end because that’s when I do. Mid-play, I like to let the flow of the game happen and not break it up by asking questions or giving feedback (unless, of course, that’s what the designer wants). Also, it gives me a better chance to get as much play time in before I start asking questions.
This is the only one that I don’t think has an exception. Feedback should be given when the designer asks for it—even if that means jotting something down. The pacing in the game might be very important. The closest thing to an exception is asking for clarification of the rules. That you should do whenever you need it.
Why: “Why is this rule this particular way?”
The timing of that question is important. You should, if you can, ask it the moment you have that question. If a rule seems counter-intuitive to you, it’s there for one of two reasons: (1) There’s a very good thematic-based or mechanic-based reason for it, or (2) The designer never thought of it. Either way, one of you is about to figure something out. Generally speaking, though, most of the time, rules are in place for a reason (whether it’s a good one or not). Ask, and then follow that rule. Even if you disagree, you’ve given the designer something to think about—and you can always circle back to it after the game.
This gets back to the issue of checking your ego. Assume—unless the designer has told you otherwise—that the rules are there for a reason. And assume that they’ve been tested before. This doesn’t mean that you can’t comment on them, but it does mean that you shouldn’t swap them out for something you’d prefer the moment you get frustrated with one of them or think you have something better. The frustration might be the very reason that it’s part of the game. Imagine if playtesters of Hanabi said, “Yeah, I thought the thing about not looking at your cards was stupid, so we didn’t do that. This game sucks.” Of course it sucks. You just played Not Hanabi.
If the designer isn’t around to ask this question, then, by all means, don’t. Otherwise, there’s really no good reason not to. Along the same lines, if the designer isn’t there to explain, feel free to try out a variation—but don’t blame them if it doesn’t work. Do, though, tell them that the variation didn’t work. You might save them some time later on.
So, one of the things that I try to tell playtesters is how far along in the design process a game is. As a playtester, listen for phrases like, “We’re happy with where it is, but…” or “We’re beta testing this…” They mean that the game’s core is finished. However, things like, “I like this aspect of the game, but I’m just not happy with it as a whole,” mean that everything other than that aspect should be the focus and is completely up for grabs.
How: “How can I break this game?”
I’ve seen lists of ways that some playtesters will intentionally try to break a game. As a designer, that borders on insulting—though I know it comes from a really good place. I understand that it comes from a desire to answer, “What would happen if…” But it’s bordering on insult because, in a sense, what you’re saying to designers when you try to “break the game” on your first play is, “You don’t know what you designed here so much that, on my first play, I think I might be able to break it.”
Now, I know this is a bit contentious, and there is a place for game breaking in playtesting. But the assumption that you should start there is a bad one. In Gothic Doctor, for example, I don’t need someone to tell me, “Hey, FYI, if you only draw action cards, you lose because you don’t get the treatment cards you need to cure patients!” Anyone who has played the game before—or actually thought about the rules—would know that just wouldn’t work. (Note: No one has ever done this to me, but I’ve seen players do things like this when testing other games. I’m just using mine as an example to protect identities here.)
That doesn’t mean that you should never try to break a game, though. When you understand the rules well enough to form a hypothesis about what might be a problem in the game—which is of course not the first time you play—then try to exploit a glitch in the rules and see what happens.
You have to know something well to know what’s wrong with it—unless it’s something really obvious. And if you’re playtesting something for the first time and there’s an obvious problem, ask. You might have missed a rule, the designer might have forgotten to explain it, or there might actually be a really fundamental problem with the game.
So, anything I forgot? Anything you disagree with? Please let me know! Making great games depends on great playtesters!
Doug Levandowski is on Twitter as @levzilla and @meltdowngames. He is the co-founder of Meltdown Games (MeltdownGames.com), which will be relaunching Gothic Doctor on Kickstarter early this summer. He’s currently working with Jeff King of All Us Geeks on a monthly podcast about the process of relaunching a Kickstarter, starting with the day the funding is unsuccessful and ending with hitting the relaunch button—and beyond. That can be found at AllUsGeeks.com
Our monthly roundup of links and quotes for board game designers is here! This month features some important information for first-time designers, a useful tool for making grid paper, a valuable list of things that should be in a licensing contract and more:
Know what to expect before going into a playtesting event:
The Game Design Round Table discusses playtesting and the challenges of getting good feedback:
The stages of game development:
Takeaways from Protospiel Houston, useful for any playtesting event: