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.
