Getting Feedback

Game development is a deeply human craft - and humans almost always end up being the defining factor as to whether a development process works out well or becomes a disaster. That's not to say that each success can be attributed to humans, or that every failure is the fault of people - many elements play into whether a development process (& the resulting game!) are good or not. What I do mean is that development is a very human process about humans working with technology made by humans to make some sort of media expression for other humans to interact with and appreciate. Behind the budgets, technology, and spreadsheets - game development is all about humans.

Game development is also deeply unpredictable: even the most experienced game developer will tell you that nothing can be certain without proper testing. This is obviously deeply true for code - but it is also true for art, for design, for narrative, for literally any aspect of developing games. Without actively getting perspective on what is and isn't working, game development often spiral into an absolute disaster. There's the rare story of the game where a singular authorial focus did work out, but survivorship bias suggests that for any game where it does work out, there must be many thousands that fail.

Combine these two truths and you end up with an important realisation: feedback is critical to making good games, and it is deeply human.

Getting and giving good feedback are two of the most critical and most difficult skills to learn in games, and it is a process you will continue to get better at forever. We'll cover giving good feedback in a future Levelling The Playing Field, but today - let's talk about getting feedback, and specifically getting feedback from an audience member on a game. Throughout my career I've been taught or learned five simple lessons about feedback that have helped me immensely, and I wanted to take the opportunity to share.

Questions only

Feedback is an invitation for others to speak their mind. It is not a courtcase in which you defend your choices or actions - a common problem a lot of (young) developers face is defensiveness. The first lesson is simple: only reply to feedback if you have a question to ask. If it is not a question, it can wait until after the feedback session has concluded - you do not want to seem defensive or unwilling to consider feedback while someone is in the process of sharing their thoughts. Encourage people to discuss their experiences by actively listening, asking questions, and allowing them to finish their train of thought. Subtly encourage moving on by nudging the person giving feedback with an open question.

Listen to problems, not solutions

The next lesson I was taught was that when it comes to audience feedback - listen to problems, not solutions. Game development is an incredibly complex job, and the amount of insight into a project required even for a professional to give useful solutions-based feedback is enormous. People tend to try and solve problems when giving feedback, but you'll find that they are rarely -if ever- right about the solution. Despite their solutions generally being useless, they will 100% be correct in that they had a problem. Even if you disagree that the problem was a problem in the first place, you're still going to want to look at why the user perceived it as a problem.

More importantly, you want to develop the skill to trace back a solution to a problem. If someone says that "the giant plant boss needs to have less health", that's a solution-type of feedback - and it is useless: it might be that the player didn't have enough ammo, or that the damage fall-off for a weapon is poorly communicated, or that the boss has poorly communicated weak spots. What you now do know is that is useful is that something gave this player the impression that the fight against the giant plant boss is too hard, or too long. That is a problem, and a problem is something you can solve for.

Good Negativity

The third lesson is that sometimes getting negative feedback is actually good news. This might sound contradictory, but it follows from the most brilliant sentence I ever heard spoken about balancing live games: a game is properly balanced when every option gets the same amount of hate. After all, feedback is simply someone telling you that their favorite option is woefully underpowered, and the thing that is strong against their favorite option is overpowered.

Similarly, sometimes you intentionally want to create friction, or create a situation that isn't optimal for the player. People pointing out that they did not like that can be good news, as long as they keep playing. In Bungie's Destiny - my most-played game of all time by a large margin - I spent several months trying to get a specific item. I would get a single attempt a week, and it required me bringing together five friends every week to solve a jumping puzzle, survive a battle, and perfectly solve an agility challenge to get to roll the dice twice. There were two more dice rolls, but the difficulty of achieving those was such that we never tried for that.

I visited Bungie and regaled someone working there with the story of my frustration - after months of playing, I had not gotten the item I wanted. I had watched several friends get it while trying to help me, but I was still getting together five friends to help me out every single weekend. The Bungie employee looked at me questioningly and simply asked "Will you get it?", and I almost insultedly shot back "I'm not going to stop until I have it". They grinned, and I realized right there that the game was working exactly as they intended: I was still playing, I still cared, and I would have a story to tell when I eventually got it. Several weeks later, the item dropped - and here I am, still telling that story.

Choose

The fourth lesson I learned was that acting on all feedback does not make your game better. Feedback is not a checklist of things to fix - it is a list of problems to ponder: in the end, the responsibility of whether to act on feedback is yours. When I started, I think I subconsciously believed that feedback was something you always wanted to act on - but one experience at Vlambeer made me reconsider this.

In late 2014, Vlambeer was hard at work on our roguelike Nuclear Throne - a game that had been thriving in Early Access for almost a year at that point. The game was being developed in close communication with the Early Access community - we did a game update and two development livestreams every single week. We actively responded to feedback, forum posts, and player videos - and the community was ever-growing and incredibly supportive.

In Nuclear Throne, players battle their way through seven procedurally generated worlds to reach the eponymous Nuclear Throne. If the player dies, they lose all their progress and have to start over in the first world, the Desert - only making progress through having learned about new ways to die and avoid dying. Completing a "run" and finishing the game takes 20 to 30 minutes - getting good enough to actually make that run took many players 20 to 30 hours of deaths and retrying.

We started consistently getting a very logical piece of feedback from around the community: the Desert was just incredibly boring. It was very easy, and it was the area players saw most often. Our community would die in a tense battle, and then be back to shooting basic bandits for a minute straight. So, we made the Desert a bit harder - which didn't fix the issue, so we made it harder again.

A few weeks later, we noticed a peculiar issue: we had almost entirely stopped getting new forum members - despite still seeing ever-growing sales figures. It took us a while to diagnose the problem, but eventually we honed in on the issue: new players weren't getting far enough in the game anymore to start to care about the game enough to join the community. The newly difficult Desert was killing players before they got good enough to care. We had gotten stuck with a community that was too good at Nuclear Throne.

Our solution was two-fold: Vlambeer co-founder Jan Willem came up with optional challenges that would lead to shortcuts, which allowed advanced players to skip ahead (if I'm not mistaken, inspired by a similar system in the wonderful Bit Pilot). That solved the issue there, but it still left us with the slanted feedback from an too-expert feedback pool, which I solved by... giving away tens of thousands of copies of Nuclear Throne. We gave everyone who had ever bought the game a copy of Nuclear Throne to gift to a friend. It brought a lot of attention from the press, a wave of new and inexperienced players, and community gratefulness.

Guide

Finally: feedback is something you request. In a day and age where developers get yelled at on social media over the smallest things people want fixed, it might seem preposterous to suggest you need to ask for feedback - but consider that there are different types of players. If you only look for feedback from the people yelling at you, you're getting feedback from one specific group of players. If you ask, other players might feel empowered to speak their mind. When it comes to the power of asking, I simply remind people that the most effective thing you can do to get anything from wishlists on Steam to subscribers on YouTube, is to simply ask.

It also means that you can guide the feedback process into more constructive forms. Most people are not practiced in giving feedback, and a lot of good people will simply yell solutions at you because that's what they see most in games. Creating a positive environment for giving feedback, with clear examples of good feedback being responded to in detail and with a genuine note as to why it is good feedback, can be an incredibly powerful tool towards generating a more positive community - and getting higher quality feedback.

In the end, getting feedback is a process that you will have opportunity to refine for as long as you're in games. There's so much more to discuss, from how feedback can feel so personal and hurtful (you can take breaks from feedback!) to how to best collect feedback (depends on what kind of feedback you're looking for!) - but I think for now, this will be enough.

Actionables

1. If you've never released anything that could get feedback, consider putting a game or project on itch.io or a similar service. Learning how to receive feedback requires being professionally vulnerable, and it might take a bit of growing a thicker skin even when the feedback is constructive and kind. Making games can be deeply personal, and learning that something isn't working properly can actually sting. Practice getting feedback with smaller games, jam projects, or Game A Week.
2. Read this phenomal article that I tend to recommend to indies struggling with feedback. While the article is focused on playtesting specifically, it gives great strategies and approaches to how to poke at feedback to get more useful information. The perspective is incredibly helpful.
3. Take some time and consider your projects' strategy for getting feedback. Are you getting feedback early enough in development? Are you getting feedback often enough? What methods of collecting feedback do you have? Are you doing playtests? Going to events? Reading the forums? Checking Twitter? Is your feedback group diverse - not just as people, but also in their relationship to your game? Do you have objective data to compare the feedback against? How are you encouraging feedback? How are you shaping the way your community deals with feedback?