By Linux Foundation

Playtesting your game is thrilling. You’ve finally gotten your baby game in front of other players, you’re seeing what works and doesn’t work.

And then the session comes to a close. You say, “Okay, do you have any feedback?” and stare at your playtesters, waiting for them to fall over each other to give you a wealth of suggestions.

More often than not, instead, they just look at each other, look back at you, and say, “Not really.” They may point out one thing that went wrong so clearly people in the next room could see it, but that’s all the feedback you get.

And you end up feeling frustrated. How can you get useful feedback?

To understand that, you have to understand why people don’t easily give in-depth feedback in playtesting sessions. I think there are two main reasons: social pressure and asking the right questions.

Your playtesters are human, and they see that you’ve built a game you believe in. They don’t want you to believe your game is bad. They fear that you’ll take negative feedback personally. They also don’t want to be seen as the one person with criticisms if everyone else enjoyed the game. So, nobody goes first.

Also, “Do you have feedback?” is a vague question. It’s like a parent asking “How was school today?” or a boss asking “How’s the project going?” It’s easier to just answer “Fine.”

So. You can solve this with a couple of specific questions.

First, ask this: “What should definitely remain in the game?”

This starts the feedback with a question that’s both positive and probably unexpected, and subtly introduces some danger. The players realize that this game might change drastically, and it’s up to them to save some parts of the game.

It also shows you what parts of the game work, and what parts of the game the players enjoyed. Of course, these parts may not be perfect, but at least you know not to chuck them out immediately.

Then, ask this: “What would you like to see changed?”

Now that players realize that the game might change, you want to focus them on the problems.

Feel free to give the players some time to think about this. If the table’s initially silent, let that silence stretch for a while. Give people time to think. Don’t rush.

Then, ask this: “Did anything confuse you, even briefly?”

This is incredibly important. Some rules and aspects of games aren’t necessarily bad, they were just badly understood in the playtest. Many times, a rule makes sense to you but is unclear to other people, either because they have less experience than you, or more experience than you (“Oh, that term always means this to people who play these other sorts of games”). You need to know those pain points so you can rewrite the appropriate rules to be more clear.

Now, how should you be acting in the midst of all this feedback? Four things:

Write down everything the players suggest. You won’t be able to get it down word-for-word, naturally, but get the gist of it on paper. Even if you think it’s dumb. Even if you never plan to implement it.

Why? That tells the player that you care about her or his feedback, which further tells the other players that you’ll care about their feedback, too.

Also, you may look at that feedback later and realize that it’s not so crazy after all.

Ask “Why?” if a playtester doesn’t explain his or her suggestion. Meaning, if a player says “You should drop the encumbrance system,” full stop, ask them why.

You need to understand the reasoning behind their feedback, because their specific piece of advice might not be perfect, but the reason for the advice will tell you what’s going wrong.

Don’t disagree with a playtester. Your job here is not to tell the playtesters if they’re right or wrong; it’s to gather feedback. So just smile, nod, and accept whatever feedback you get.

Again, remember, you don’t have to implement any of the feedback you receive. So it’s much better to take all of it graciously and positively, so that you’ll get all the feedback you can possibly get.

Don’t explain your design decisions unless specifically asked to. This is a very common mistake, and very easy for us designers. A player will suggest that you change a rule, and you’ll launch into an explanation of why you included that rule.

You might think you’re engaging the player with that rule, to better understand the best way to change it. But more often than not, it comes across like you’re defending the game. It will make other players less likely to share feedback, because they don’t want to get into a debate.

Again, your job is to collect feedback. Collect it.

What should you do with all that feedback? I’ll write about that in the next post.

By greensefa

This is part of a multi-post series about the practicalities of designing a game. Today I’m going to look at the practical actions you need to take while actually running a playtest.

First, choose a classic scenario. Avoid the temptation to test an unusual setting for your system, like a James Bond action scenario using wushu rules. This will skew your playtesters’ feedback, and you won’t be able to separate problems with the game from problems with the game’s applicability to the scenario. Stay basic.

Second, run the game as if you were the DM, not the designer. As the designer, it’s easy to answer a question about a rule by explaining the reason why you designed that rule. This information will skew your playtest. It gives your playtesters more information than your audience will have. Other potential problems with the game won’t surface, because your playtesters will understand your reasoning behind them. Don’t give them more information than a DM who read your rules would know. That can be hard to do, but it’s important that you do your best.

Third, bring lots of paper and take copious notes. Many small moments occur during a playtest that you want to capture and will slip from your mind once the session’s over. You will notice a pause when a particular rule is introduced, or a conversation about a rule interaction that you will want to capture immediately.

Also: I know, you probably want to use your laptop or tablet to take notes. But people react differently to a person writing on a piece of paper compared to a person typing on a screen. The latter feels impersonal to people, and they’ll feel more like they’re in a doctor’s office than a playtest. It will shut them down emotionally a little bit, which you do not want in your playtest.

Fourth, run the game. Meaning, other than taking notes, run the game like a normal session. Ensure the players are having fun. A playtest involves play, and playtesters who’ve had a good time with your game will give you more feedback than players in a session where you paid less attention to the game itself.

How should you ask for feedback and incorporate it into your game? We’ll cover that next.