The previous post in this series looked at why you should listen to everybody. But at the same time, you definitely shouldn’t do everything people tell you to. The problem is that everybody wants something a little different. When you listen to all the feedback, as I recommend in the first part, you need to be able to recognize whether the feedback is telling you something about the game, or the player. Making that distinction is one of the biggest skills a designer can learn for dealing with feedback
Many times, a player’s preferences are in direct opposition to the designer’s goal for the game. In New Bedford, many players have asked for more conflict-based interaction between ships. The overall tone for New Bedford is one of friendly competition, not conflict, so including it would make New Bedford into a dramatically different game. At the same time, there are a few mechanics in the game for achieving more interaction between ships, that the players may not have taken advantage of. (And the Ship’s Log inspansion will include more ways to interact).
The challenge is that nearly every aspect of a game–the amount of randomness, the theme, the level of interaction, the degree to which tactics and strategy guide choices–will conflict with a player’s preferences. A designer has to be very careful not to mistake the player’s desires, what he or she wants the game to be, for real design advice, of what the game needs to be. So how do you know from feedback whether this is a player issue or a game issue? In this Inquisitive Meeple interview, Gil Hova talks about Dos and Don’ts of feedback. From that interview:
DO: Hear to everything your playtesters say.
DON’T: Listen to everything your playtesters say.
Hear them out, but don’t react to anything just because someone says something. Generally, if someone says something radical, I file it away mentally, but don’t act immediately. If a second person mentions it, I pull out that mental file, add to it, and either correct it or stay put. If a third person says something, I’ll generally fix it.
This is great high level advice. Perhaps another way of putting it is to listen to everything, but only use some of it. One major point that Gil makes is that one person’s feedback might not mean much on its own, but multiple people’s feedback carries a lot of weight. This idea shows up again in the first part of this article on the League of Gamemakers, where they refer to a lot of little red flags. But I like to look at in terms of Red Threads.
The idea is that if you see a single red thread, that doesn’t mean much, but once you see enough of them, they start to form a red flag. A red thread can be anything that a playtester tells you needs to be changed. Obviously, if somebody says “It takes too long to play”, that is a red thread that you need to make the game play more quickly. If nobody else makes a point of running into excessively long game times, you can discount that single red thread. But if other people come to you saying “It seemed to drag on near the end,” “It was really prone to overanalysis,” and “I spent a lot of time waiting for my turn,” suddenly you have a trend. All of those individual comments implicate different parts of the game, but taken as a whole, it is a clear signal that some part of the design slows your game down.
Red threads aren’t limited to strictly negative feedback, either. “This game is great, I wish there was even more,” is a good comment when taken by itself. But if you add more red threads of “I wish it had more variety,” while mixing in negative red threads of “I’m worried about replayability,” you again have a red flag that maybe there isn’t enough content in the game to give it longevity. [Noting that replayability strictly a question of the amount of content, but it could be the issue driving the concern.]
This also works in reverse. If you are questioning something as the designer, that might only be a red thread that you notice because you’re so close to the game. You can look for feedback on that specific concern, or specifically ask about it, to see if everyone else sees it as a red flag. This happened early in the development of New Bedford. I was starting to wonder if lumber needed to be removed as a resource. Two playtests in a row were interrupted by players questioning why it was in the game at all.
Some feedback is shaped by a player’s desires, and some is a sign that the design needs to change. Separate the design from the desire The takeaway is that interpreting feedback as red threads is a great way to judge what is relevant or not. You can ignore one or two red threads when they start to show up, but if you keep seeing them weave together, that’s a red flag. Feedback gives you all of these threads, but it’s your job to figure out how they fit together. THis is summed up well by this quote from Eric Lang (via Cardboard Edison)
The worst you can do with feedback is itemize a list of comments and address them point by point in your design. Seek trends and patterns.
The final part of this series is figuring out how to get that feedback.
Oakleaf Games 