Processing Feedback

Making art is a strange business, and making games doubly so, because they combine so many different elements and vary so radically in form. Sharing your work with others before you release it can be very useful – but it can also be disheartening and disorienting. Processing feedback, especially when it’s for something very personal, something that came out of your imagination, can quickly turn into an emotional mess.

When I had my first feature-complete (but not fully polished) version of Traitor ready for play, I shared it with a group of other indie designers. The feedback I got was clear and not in any way personal or mean, but pretty consistently negative. Having worked on the game for ages, I was shattered. It was extremely depressing, and I didn’t know how to react. I had reasons for my choices, and Verena had played the game and really loved it, so up until that point I’d been very optimistic. Now I suddenly felt like it had all been a waste of time, and I was tempted to throw it all away. Thankfully I didn’t, because as it turns out the game has turned into a success – with a bit of tweaking. So here’s some stuff that I learned from that process.

Who are you showing your game to?

The people I showed my game to are, without exception, very talented and very kind people. I know that the feedback they gave wasn’t meant to offend me or depress me, so I knew that their responses were genuine. I was depressed that they didn’t like the game, but I never once thought they were being spiteful. And if they were all disenchanted with it, they probably had a point. And so they did – partially. You see, these people are all game designers, and they’re game designers with particular interests. They like innovation, and pushing limits; they like (and in many cases make) crazy and unique bullet hell shooters with amazing graphics and totally new approaches to the genre. When they look at a game, they often think “what does this do differently from other games?”

This is not a criticism. As I said, these people are all very talented. But Traitor doesn’t come from that school of game design. Its fight/upgrade/fight structure is something that I find very addictive and fun, but that most of the people I showed it to just don’t get. To them, the simple and straightforward gameplay of Traitor was unoriginal, and therefore uninteresting. Again, let me be clear, this is not a criticism. I don’t get bullet hell games, or racing games for that matter. It’s purely a matter of taste. But understanding that this just wasn’t their type of game was the first step to being able to process their feedback.

What could they be right about? What could you be wrong about?

It was important for me to first (re)establish my confidence in the game’s design – to know that the core of the thing wasn’t broken. Without that certainty it would’ve been impossible to improve the game, because there would’ve been nothing to improve it towards. But it was also important to look at the game objectively and see what could be improved. When people don’t get something you’re doing, it’s very easy to become overly defensive and just dismiss everything they’re saying. I oscillate between a total lack of confidence and a degree of self-confidence that often comes across as arrogant. Neither way of thinking is terribly useful, and I have to remind myself both that not everything I make is crap and that there’s potentially a lot to improve.

Perhaps part of my problem is that more than anything else, I’m a writer – and as a writer, I’m very precise. I usually don’t need to edit a lot (in fiction, that is) because I write so slowly and precisely. My stories are so strongly determined by the clear ideas behind them, by my insistence on knowing the story’s voice before I set out, that they cannot be altered a whole lot. They are what they are, and you either like them or you don’t.

This simply doesn’t apply to games. Games have many more elements and are thus much more malleable. A newly finished game is a lot more like most writers’ newly finished first draft. It needs work.

What could really be improved?

A great deal of what was necessary to improve Traitor was simply to make existing things better. The feedback was that the game was too slow and boring. I had to partially reject this, because I had no intention of turning the game into the kind of chaotic game they would’ve preferred, that simply wasn’t the point. But I also had to partially accept what they were saying; just because this wasn’t bullet hell didn’t mean it had to be so damn sluggish. Yes, we disagreed on the principles, but many of the points they were making were absolutely correct: the game was nowhere near polished enough. I didn’t want Traitor to be anything like, say, Jamestown, but that didn’t mean having so few enemy attacks and enemy movement patterns was a good idea. In fact, it was a terrible idea, and adding more of those would make the game better at what it wanted to be – in keeping with its own principles.

Why are you still doing that?

When you’ve been working on something for a long time, it’s easy to develop certain habits. You make everything in the game work in one particular way: because it’s easy, because you just discovered you could do it and think it’s awesome, or simply because you don’t think about it. After a while you’re so used to the game being this way that you never even consider how much more interesting it could be if you shook things up a little.

Another danger is that you accidentally carry forward problems from the game’s earliest stages without realizing how silly they are. For example: the first version of Phenomenon 32 I released had completely silly controls. Why? Those were simply the standard controls for some built-in behaviours in Construct, and I’d been using them for so long (originally just for testing) that it never even occured to me that the game might do a lot better with a different control scheme. Or take The Book of Living Magic, which originally had a blocky, box-like GUI that didn’t fit the game at all, simply because such a GUI had been fantastic in Desert Bridge (where it made actual sense). When other designers told me the GUI was crap I was mildly offended – which would’ve been the correct response, but only if they were talking about Desert Bridge.

Are you designing out of fear?

I don’t know about other game designers, but I spend a significant chunk of time on each project being terrified I can’t pull it off. Especially when, as with Traitor, I’m not only working in an unfamiliar form, but also with an unfamiliar tool. So I will, naturally, avoid certain things which seem too difficult, intending to add them later, when I have a better grasp of the project. Only then I often never do so, or actually convince myself that it’s too hard and I shouldn’t try. Which is bullshit, but an easy mindset to slip into. By the time I had completed my “first draft” of Traitor, I was quite ready to add all sorts of helpful details.

Are you forgetting the little things?

When I showed Traitor to the other developers, I think I was looking for feedback about the core gameplay (which wasn’t really their thing anyway) but not looking for feedback about the details (which I thought I could always improve later). But the details are essential to the actual player experience! In fact, they are as essential as anything else. For example: changing the speed at which the background scrolls doesn’t affect gameplay in any way, but it can have a huge impact on the player experience. That’s one reason the school of design that focuses exclusively on abstract ideas of gameplay is rather misguided: the presentation is as much part of the experience as the mechanics are. Take your life as an example: having sex with a beautiful partner and having sex with an animatronic doll made of jelly and petroleum, if looked at in purely abstract “gameplay” terms, is exactly the same. And yet any human would agree there is a world of difference.

Take it apart, depersonalize it, test it.

Perhaps it’s best to look at feedback as a list of entirely neutral propositions that need testing. Not “Bob says that…” or “Wilhelmina suggests that…” but simply “alter movement speed” and “change attack patterns” and “add clowns”. Then try to determine whether these ideas will make the game better at being the game you want it to be, independently of who suggested them or why or what else they suggested. Stand your ground when you have to (you will have to), but accept logical suggestions when they pass your tests.

It’ll never be easy, and you’ll never please everyone, but if you ask yourself the right questions, you’ve got a pretty good chance of making something you’ll be proud of.

Previous Post
Leave a comment

6 Comments

  1. James Patton

     /  April 3, 2012

    This is very helpful! Processing feedback is such an important part of making games since the smallest tweaks can completely alter the “feel” of the game, but it’s also one of the most difficult to deal with. This is a great guide!

  2. I think it sorta goes both ways too and recognising that it’s perfectly ok to pass on giving feedback because you can’t offer anything of use is an important skill.

    I saw the feedback request and had a go of the game and whilst there’s probably cosmetic things I’d pick out, I felt that anything I offered with regards to gameplay would be to invite tailoring the game away from what you intended and I see no healthy end to that.

    But oh, it was tempting!

  3. I think this post is immensely helpful for anyone who tries to do anything creative. I’ve been working a lot on music lately, so it’s nice to just read the thoughts of someone who goes through the same sort of conflictions. I have a lot of trouble with feedback. If I get a really positive reaction then I feel like the listener is being kind and giving me too much credit. When I get criticism, I either wanna dismiss it or scrap everything I’ve done. People always talk about trying to get feedback, but it’s pretty hard to decide what to do once you get it. And it somehow seems impossible to make progress without it. Great post.

  4. Yeah, Jonas, I go through a mini-version of this cycle every week. My feedback is in traffic, in clicks. I can get so excited about a new article until the very moment I post: at which point, all the fear and dread that I’d forgotten for a week rushes back into my head and I wonder if I’ve imagining that I’ve written something interesting. I’m paralysed by the WordPress stats, waiting for that judgement to come in.

    Sometimes it all works – like the last couple of weeks – and other times there are posts which languish and attract little attention. And the worst times when you think you’ve made a horrible mistake like The Xmaspiration: you’ve lined up weeks of articles… and no one is reading.

    It’s hard not to take that stuff personally because it’s personal sweat and tears, a little piece of you put out on show. People are judging the thing you’ve made, but that thing is you and you see it as a judgement of you.

    But you have to keep doing the things that are risky and keep doing the things that are you… because that’s why people were coming anyway.

    I can understand entirely the problem you had with the feedback on this. Traitor isn’t a “game changer” but it is a solid, well-executed and pretty little thing. You did what you wanted to do. And that’s grand.

  5. I could spend another 500 words here talking about critiquing other people’s writing – which is a valuable thing for both parties involved – but everything said is merely recommendation and not a binding legal requirement.

  6. Evan Balster

     /  April 5, 2012

    A scattering of things I’ve learned about criticism:

    I think it’s become protocol among independent developers (or at least the ones I hang around with) to keep praise to a minimum and focus on being critical. The rationale there being that criticism is more helpful than praise. It’s a habit that has, at times, caused me to hurt the feelings of non-game-developer friends when responding to their work.

    Telling people ways they can improve can sound a lot like telling them their work is terrible. Telling them how good their work is tends to avoid the details of what could be improved. The “compliment sandwich” is one common solution to the issue; I rarely use it as it tends to feel forced and ingenuine.

    I get defensive myself, at times, when people poke holes in ideas and works I’m attached to. I try to catch myself when I do. To keep thick skin and an open mind. I also remind myself now and then what I love about my projects.

    Andy Schatz said something in an IGS talk last year (?) — when people play his game he asks three questions: “What did you like?” “What didn’t you like?” “What confused you?” He takes notes on these, especially the last, and ignores suggestions.

    I like to think of suggestions as symptoms rather than cures for something wrong with a game, whether they comes from designers or non-designers, especially when the project is far from complete. Ten people may suggest the same thing, but there may be a better solution that’s truer to the goals that drive the project. Trust your own judgment.