In a previous post, I introduced a series of articles about how to use playtesting feedback from players. This article takes a look at the first important point, what feedback you can use. I’ll save you time by giving the answer now: all of it.
Every single piece of feedback tells you something about your game. But the feedback doesn’t always tell you what to do. If everyone came straight out and told you what to do, game design would be easy. Instead, the designer needs to carefully inspect each piece of feedback to figure out what message it holds. Taking feedback is like trying to break a code.
Feedback is all about getting more information about your game. The first step in breaking the code is figuring out what kind of information players are giving you. Are players telling you the root cause, or a surface symptom? The player might not even know. Part 3 in a series by Kevin G. Nunn includes a comment from Gil Hova of Formal Ferret games, illustrating that a player presented a problem (there isn’t enough to do with money), but the real problem was different (there’s too much money), which lead to different potential solutions.
On a basic level, are they giving you an emotional response, or a logical response? Players aren’t always able to separate the two. Telling the designer that they don’t like something that happened in a game could be a complaint that it happened at all, indicating a flaw in the game. It could also be a complaint that it happened to them, which spoiled their experience. It could be the player’s preference for or against a specific mechanic. And it could be that they simply didn’t understand something in the game due to just learning it, or the designer forgetting to explain something, or simply a problem with the prototype that needs to be corrected for printing.
And, of course these can all stem from a positive reaction, as well. Great art can hide a problem, learning from the designer might improve the experience. Players can be fans of the game style and predisposed to ignore faults. They might get lucky and have a fantastic unique experience. Or if none of these things are an issue, it might possibly just mean it’s a good game.
Players, like designers, don’t always recognize everything that influences their reaction. The designer’s job is to take what players are telling you and trying to understand everything that went into the experience. So one important part of understanding feedback is figuring out what parts of it were influenced by the situation, and what parts are constant across games. But this is a subject I’ll study more in the next part of this series.
I’ve watched and participated in a large number of playtests for New Bedford over the last three years. Sometimes I get feedback that makes a lot of sense. I’ve gotten feedback that seems obvious in retrospect, but I was blind to at the time. I’ve gotten feedback that reinforced my opinions and feedback that changed them. And sometimes I get feedback that makes me wonder if we played the same game.
But even that last type of feedback has useful information in it. Even feedback that seems to contradict itself can contain a kernel of truth, because it might mean that player expectations were not met. That perception can really hurt in a market where players only play new games once or twice. Even when the game is mathematically or mechanically balanced, player perception of that balance matters to the experience. And sometimes the feedback tells you more about the playtester than the game. The underlying message might be “I’m not the target audience.” In a recent case, feedback about an overpowered strategy was really a sign that players can approach the same game in different ways, which is actually very good feedback despite being almost opposite of what the player said.
The real point is that a designer shouldn’t decide what feedback to listen to. Some players will tell you a lot, and some will say very little, but it is all worth listening, because the players are always trying to tell you something about their experience. Whether it was good or bad, and whether it connected or not. Very rarely will feedback simply tell you what you want to know about the game, so the designer needs to dig through all of the information and find the useful message at the heart of the feedback.
Another excellent article on 3DTotalGames makes two great points. Almost 100% of the people who will ever play the game are NOT the designer. So without feedback, your sample size isn’t at all representative. But trying to use all of the feedback is like trying to draw a smooth line through a bunch of points. If you use everything, you over-constrain the game into something that only loosely resembles your goal, so the designer has to be selective. I’ll leave with this great quote from designer Mike Fitzgerald:
Be careful listening to what play testers say. The most valuable information I get from play testing is from watching the play testers. What part of the game are they having the most fun with? What part are they frustrated with etc. They will show you this in how they play the game.
The next article in this series is about how to be selective in finding the player’s message.