On the Nature of Feedback

Some couple of weeks ago, I posted this to a forum for… well, let’s just say it’s a game forum I’m legally obligated not to talk too much about except to say that I’m beta testing. But that part is largely irrelevant except as background. The post was very well-received, to the point that I think it’s worth cleaning up and reiterating here.

One of the most interesting things about formally studying game design is some of the things that one comes to realize or learn as part of the process of learning-by-doing. This is one of those instances—SCAD is very invested in and fond of the idea of learning by doing, and also of the iterative design process. One of the side-effects of going through this process is developing a greater experience with and understanding of feedback, user and otherwise.

I wasn’t what I’d call a total neophyte to iterative design or feedback cycles by the time I got into the graduate program. My undergraduate degree, while in more of a graphic design-oriented sort of animation program, was big on process, and we actually had a formal class just on delivering and receiving constructive criticism. Still, one develops greater understanding as one gets more and wider experience on any topic, and I’ve come to understand some things about feedback that I’d not really considered in so many words before.

The foundation of this post came from a developer’s post on that forum, to the effect that while yes, knowing what players don’t like about a game (negative feedback) is important, knowing what they like about a game (positive feedback) is equally important. This was something I already knew to be true, but I’d never really considered the reasons. The reaction of the other posters, largely claiming it was entirely untrue for various (flawed) reasons, changed this as I sat down to consider what was flawed about that thinking. I won’t be talking about that side of this further—with the background in place, let’s just move on to the conclusions and reasoning.

The Point of All This

…is to expand on why I feel comfortable taking this statement as fact: Negative and Positive feedback are equally important to a design process. This is probably entirely obvious to any designer or creative individual that has ever created and then sought out feedback. Given the state of the average forum, whether in-person or over the internet, the same cannot be said of people giving the feedback. So in some ways this is really probably much more geared towards those people.

Admittedly, I also write these things because it helps me cement my own thoughts on the matter.

In any case, the way I see it, there are two reasons that both forms of feedback are important:

  1. Knowing what is going well and poorly gives the best information for assigning resources towards improvement.
  2. Knowing what is working well suggests effective changes to what is not working well.
    #1 is not a particularly tricky concept, but does take some examples to support. Let’s take three extreme examples. Let’s first say that Game A receives nothing but positive feedback, even though there are some problems with the game. This then causes an assumption that there is nothing wrong with the game, even if in reality there is, and those problems are never fixed. On the other hand, if Game B sees nothing but negative feedback, one could easily end up with an assumption that elements that are working well need fixing, because everything else does. Time is wasted fixing things that were never broken, and possibly breaks them in the process. Game C, with a mix of the two, has the best situation. It can address the elements that are not working, and knows which elements are working so no time is wasted in an attempt to “fix” them.
    #2 is rather straightforward as well. If players consistently dislike Mission B, then it is obvious it needs to be changed to be more enjoyable. They may be able to identify what they don’t like about it, but that doesn’t necessarily suggest what they will like as an alternative. However, if they are also known to like Mission A, then the designer has a good idea of some potential directions to move toward in fixing B. The alternative is potentially a great deal of continued trial and error.

The upshot of this is that we can see this really boils down to a single reason, and we can expand the previous statement to be more definitive. It’s quite obvious to most designers, I think, but as I said earlier, this post is really more about players understanding designers when they fork out their feedback.

Positive and negative feedback are equally important because together they reduce wasted development time.

Practical Considerations

taking all this into account, there’s still more to it. So we’ve decided that both kinds of feedback are important, but how the feedback is delivered is also very important. Simple statements of “I like X” and “I hate Y” are nearly as useless as no feedback at all (Nearly. It’s still better than nothing, but frequently infuriating). Reasons are key. Meaningful feedback is always best, but how do we give meaningful feedback?

As stated, ideally, we start with reasons. The more detailed the better—if they are accurate—but reasons of any sort are better than none. “I dislike Y” is bad. “I find Y frustrating” is better. It at least suggests a reason for the dislike. “I find the third encounter frustrating because there are three waves and I never have sufficient ammunition for them when I get there no matter how careful I am” is better still.

Proposed solutions, if they are well-constructed, are even better. these are tricky, though, since in a lot of cases people making them are not really qualified to be making them. However, a savvy player should be able to offer a reasonable solution, and making one as part of the feedback can be a great help. Pointing out some other similar part of the game that succeeds where the current one fails can put the finishing touches on a greatly-useful piece of feedback.

I find the third encounter frustrating because there are three waves and I never have sufficient ammunition for them when I get there no matter how careful I am. Mission One had an encounter just like this that was a lot of fun, because it was challenging to pass but there was enough firepower to pull it off. Perhaps an ammo pickup before the encounter would fix the problem.

This is what I’d personally consider the ideal sort of feedback. naturally, it’s not always going to be possible, and not every tester—especially not every unpaid tester—is going to be willing to put out this kind of detail. But it is sort of an ideal situation to strive for. It’s important to note we’re talking about gameplay feedback here. Bugs and technical problems have a much different set of needs that have been well-documented by people way more qualified than I.

Final Thoughts

This is more in the nature of outlining issues I’ve seen over and over with design feedback on game forums. It’s important to remember that the point is to help make a better game, not to rag on someone’s design ability or blow one’s own horn. If you just want to prove you can do better, go get a job doing it. If you just want to be a pest, don’t. If you want to help make a good game great or a bad game playable… make the best out of your opportunity to do so by giving the designers something they can work with.

–Alright, game on.

This entry was posted in Everything I Know I Learned From..., Game Design, Players. Bookmark the permalink.

Leave a Reply

Your email address will not be published. Required fields are marked *