The first time I got feedback on an interactive fiction game, it hurt terribly.
Back in college, I insisted on submitting science fiction to creative writing professors who officially disliked genre fiction, so I already knew people wouldn’t always like my work. I already understood that X% of the feedback I’d get would be “wrong” (for an indeterminate value of X), so I was prepared to sort diamonds from dreck.
Off the top of my head, I remember five things from that first round of feedback:
- People hated my game.
- People hated my writing style.
- “I’m playing as a furry? EWWWW, insta-quit”
- Emily Short liked my worldbuilding.
- Inform 7 did stuff I didn’t expect it to do, and that made my game break even though it wasn’t my fault.
I was devastated. I’d poured my heart into this game (or game chapter, to be more accurate, since Phoenix’s Landing: Destiny was an IntroComp entry.) I had a team of beta-testers and everything, and they hadn’t hated my game. I immediately abandoned the game and then wrote a post on Usenet about how harsh and unfair the criticism was.
Analyze the source
6 years later, I process the feedback a little differently:
People hated my game.I railroaded the player.People hated my writing style.My noninteractive sequences were too long.- “I’m playing as a furry? EWWWW, insta-quit” This guy did hate my game, but I really don’t care.
- Emily Short liked my worldbuilding.
- Inform 7 did stuff I didn’t expect it to do, and that made my game break
even though it wasn’t my fault.
These days, I see feedback as a conversation about player expectation, player enjoyment, and game execution. Each piece of feedback contains critical information about this player’s expectations for a game and what this player enjoys in a game, framed in the context of the game I have provided.
By analyzing this information, I can sort out which pieces of their feedback are useful and which pieces are not useful.
In diagram form:
Feedback is the tool that I use to figure out a) where these players’ circles are and b) what those circles encompass.
Some feedback is simply wrong – in the sense that it’s not useful to me. It’s not wrong in the context of the player, who has presumably given an accurate description of their experience. But consider this diagram:
In this diagram, the player hates my game – even though I’ve entirely met their expectations! In order to make a game that this person enjoys, I have to make significant changes to my game plan.
Is the effort worthwhile? To answer that question, I need to figure out how well my player represents my target audience. If the player doesn’t represent my target audience, and I don’t believe the player’s opinions will be shared by that audience, then it probably isn’t worth making changes.
For example, the diagram above could represent a player who loves 2D platformers, but gets nauseous when playing games with significant camera movement. No matter how good my first-person shooter is, that player will never, ever like my game – and that’s okay. Their feedback is valid from their perspective, but it’s not useful to me.
This diagram is a better representation of a normal player reaction. There are things about my game that the player enjoyed, and there are things they didn’t enjoy. They expected some things about my game, and they got surprised by others, and some of the surprises were good and some were bad.
But the analysis is exactly the same as the case above. Does this player represent my target audience, or have opinions that are shared by my target audience? If so, then their feedback is useful, and I should decide what I’m going to do as a result. If not, then their feedback is not useful, and I should set it aside.
Handle inconsistent data carefully
I’m not going to claim that sorting feedback is an easy process. It isn’t, and it gets even harder when people from the “target audience” disagree.
For example, when I was beta testing Beet the Devil, a couple of my testers let me know that the humor wasn’t working, and they bowed out entirely because they weren’t enjoying the game. That was pretty scary to me, because Beet relies on its humor and falls completely flat without it.
If I’d gotten just that response, then I would have doubled down to figure out what I’d done wrong with the humor and how to resolve it. But some of my other playtesters told me they loved the humor, and one said it was their favorite comedy game to date. I had to gamble – would the positive responses prevail, or the negative ones?
Since I didn’t know how to fix the humor for the people who didn’t like it, and the game wouldn’t exist if I pulled it out, the answer was relatively simple – in this case. But it isn’t always that simple.
Get feedback in advance
This is also why it’s helpful to get feedback on a game before the full release. Hearing unexpected criticism from a small, hand-picked group is much easier than hearing it from a hundred people at once. If I know in advance that my target audience will have a negative opinion of something in my game, then I can:
- make changes to that part of the game, or
- decide not to release the game, or
- brace to hear that feedback from many more people.
Any of these options is better than getting blindsided. And if I don’t get feedback, or I don’t get feedback from people who adequately represent my target audience, then I will get blindsided.
Just because it’s valid doesn’t mean it doesn’t hurt
It feels terrible when someone criticizes a game of mine. After all, I didn’t create it to be a bad game. I created it to be a good game! I invested hours and days and weeks of effort that I could have spent somewhere else. I created it to be a great game.
Receiving valid criticism will produce all kinds of unpleasant negative emotions. Frustration, anger, fear, sadness – they’re all reasonable reactions, but none of them are fun, and it gets even harder when there’s no way to push back against the criticism.
Nothing is wrong with having an emotional reaction under these circumstances. Give yourself time to process. Don’t talk to the reviewers about it – but do complain to your best friend, or distract yourself with TV or a book. And reward yourself for your forbearance with a cup of cocoa or something stronger.
You can fix things (or not) later on, once the emotions have blunted.
Just because it’s not valid doesn’t mean it doesn’t hurt
Secretly, I still seethe about that reviewer who ragequit over my “furry” game.
For context, the game in question contained a ridiculous amount of worldbuilding, blending high fantasy with science fantasy. Most of the intelligent species in the game were uplifted animals, and the player character had a 4/5ths likelihood of winding up as one of those species, with a 2/5ths chance of being furred (either as a descendant of jackals or a descendant of bats).
This feedback was so divorced from my target audience that it was meaningless. I know that, but it still stings.
I think the reason it still stings is because I loved the uplift concept. To have someone see the phrase “your fur is” and instantly type “quit” – I didn’t read it as a criticism of my game, but as a criticism of my excitement over the uplift concept. It felt like I’d been dismissed out of hand.
Sometimes, all you can do is take a deep breath, say “screw that”, and move on.
Dwell on your praise
Seriously. It will mitigate the hurt from everything else, and give you the strength to keep trying.
Did you hear Emily Short liked my worldbuilding?
Learn from everything
In this blog, I often use examples of times I screwed up. This is relatively easy to do, because in 14 years of game dev, I have made an astonishing number of mistakes. Lousy implementation, bad scope, bad time management, bad puzzle design, inconsistent writing, incoherent plot – really, at one point or another, I’ve failed just about everything.
Despite this, I am a highly skilled game dev.
Because of this, I am a highly skilled game dev.
Don’t let negative feedback dissuade you. Every piece of feedback tells you more about your audience’s enjoyment and expectations as they relate to your game. Every time you process that feedback, you learn something new about your audience, and your future games get closer to this:
which is a spectacular game, or this, which is even better.
Hang in there. And good luck.
Here’s something I wonder about — why think in terms of target audiences? That’s such a commercial way of going about things, i.e., first figuring out whom you want to market something to and then build a game that fits what that audience likes. Not really the best route to get to that final picture! So while I basically agree with what you’re saying in this post, I’d like to approach that part a little differently. You don’t need to figure out your target audience, you need to figure out your vision. And /then/ you can wonder who might be receptive to that vision, and get down to the practical matter of how and where to release the game.
I agree with you entirely about the importance of artistic vision! I wanted to focus on how to handle feedback after you have already executed that vision. You’re not the only person to raise that concern, though, so I can see that wasn’t clear! Perhaps I should do a follow-up Monday.
Also – although I’m using the “target audience” terminology, that doesn’t necessarily imply a commercial mindset. For example, for most parser IF, my target audience is “people who play parser games and are likely to try this game,” possibly with some consideration of whether I’m trying to target an experienced parser audience (Ollie Ollie Oxen Free) or an inexperienced one (Beet the Devil). This audience has established expectations about parser behavior and what defines “good” implementation, and I need to take those expectations into account if I’m going to produce a game that is enjoyable into their eyes (which, generally speaking, is my goal when writing IF!)