Player feedback is vital when it comes to designing a successful game. It can help you improve the gameplay experience and find bugs, and see your game from different, more objective, perspectives. And it can save you wasting time and money fixing things that don’t need fixing. But getting that feedback can feel like a huge task in an already overwhelming development process. Don’t panic though – we’re here to tell you how to collect, manage, and evaluate feedback both before and after you release your game.
You don’t need to finish a game to sell it. Offering people an unfinished, bugs-and-all version of your game can give you vital feedback and build hype before you’ve spent time and money perfecting things. And you can make money while still finishing your game, rather than needing it up front.
Minecraft is a great example of successful early access. Creator (and fellow Swede) Markus "Notch" Persson initially released free versions of the game, but later made a paid version which only let players fight, dig, and build. It was an instant success. And just a year after putting it on sale, it made more than €600,000.
Think about letting friends, family, colleagues, and other developers have a go on your game, then tell you what they thought. Try to find a good mix of professional and non-professional players. And make sure they know you want their honest opinions (and that they won’t hurt your feelings!).
It sounds obvious, but make sure you know (and have played) other games on the market that are similar to yours. Check the feedback they got to see if any of it also applies to your game.
Post clips and trailers on YouTube and similar sites, and see what people say about them.
You can use LootLocker to get suggestions and bug reports from people in-game. This is really useful as it means they can tell you what they think without actually leaving your game. It’ll also reduce the risk of them leaving bad reviews in more public forums like YouTube or Facebook. So you’ll want to make this as easy as possible for them – a one-click rating system, for example with happy/sad emojis or thumbs up/down, is a great place to start. You can also give them the option to add more info in a text description.
You can even identify individual players through authentication, and assign them a unique ID you can use to follow up with them later.
Invite people to come and play your game at a specific time and place. Then interview them to get their feedback. It’s up to you exactly how you do this – e.g. with surveys, videos while they’re playing, one-to-one conversations, focus groups, etc.
Whatever you choose, make sure you ask open questions they can’t just answer “yes” or “no” to. So that’s things like “What was your favorite part of the game?”, “Was there something you wanted to do but couldn’t?” and “What was the most frustrating part of the experience?”. Try not to ask leading questions about things you do (or don’t like) – you want their opinions to be as honest as possible.
If you’d like more info about this, check out Schell Games’ guide to the dos and don’ts of playtesting.
No matter how much you have, you’ll want to keep your feedback organized. That could be in something as simple as a spreadsheet, or with issue-tracking software (there’s loads out there).
You’ll also want to track feedback over time to see if changes you make are improving it, or having the opposite effect. And you should combine metrics with anecdotal evidence to check if what players are saying matches the numbers. For example, if you’re getting negative word of mouth but people are playing for hours and hours, then something isn’t adding up.
You’ve got your opinions, good and bad. So what do you do next? Here are some questions to ask yourself to help decide what to take seriously, and what to ignore.
This is about identifying your ideal player profile and prioritizing their feedback. Who’s going to be playing your game once it hits the metaphorical shelves?
This doesn’t necessarily mean you should ignore feedback from anyone who isn’t in your target demographic. For example, if you find players who aren’t familiar with your genre are all getting stuck in the same place, then you might need to change something.
You should also take into account the experience of the player giving feedback. If it’s someone with lots of experience of your game or others like it, their feedback is likely to be different to someone who’s never played anything like it before. Both are valuable.
If players don’t like something, they’ll probably tell you how they think you should fix it. By all means take notice of what their issue or problem is. But remember that the fix they suggest might not be the best way to approach something. By looking at the feedback from a different angle, you might find other solutions.
Let’s have a look at an example. Say your game includes a shotgun that does more damage the closer the player is to the enemy. Player feedback is that it doesn’t work well enough against enemy type B, and they suggest buffing it. Rather than just doing that, take a step back and see if there’s anything else you can do to fix the problem. In this case there are actually (at least) three different solutions, none of which involve improving the weapon itself.
This all comes down to the fact that while players do know how they feel about something, they probably don’t know why they feel that way.
Not convinced? Have a look at this video featuring Wolfenstein: Enemy Territory. Two guns in this game had the exact same stats – damage, rate of fire, reload speed and clip size. But players were giving the developers feedback saying that one was more powerful and that they should improve the other. And in fact, they were scoring more kills with one type of gun than the other, which was unbalancing the multiplayer game. When the developers looked into it they realised the only difference was that one had more bass in the audio – it just sounded more powerful. And that was giving players confidence to go for more kills. So the developers simply changed the sound of the underperforming weapon to fix this, not the weapon itself as the feedback had asked.
If feedback’s going to be really hard (or expensive) to test or implement, it might not be worth doing. Weigh up the pros and cons of doing it before you jump in.
Obviously you want as many people as possible to play your game. But you’ve probably got a vision for it as well. And you might not want to compromise on it, even if some feedback says you should. Work out where you’re going to draw the line.
Unless you’ve only asked for feedback from three people (which isn’t going to be very useful), you just won’t be able to respond to everyone. Often it’s only worth replying to someone if you want to ask them a question about what they’ve said. There’s no point in getting embroiled in an argument because you disagree with someone’s opinion of your game.
If you do decide to respond, keep a bank of standard responses somewhere so you can reuse them.
Remember that feedback is an invitation to others to speak their minds. But that doesn’t mean you have to agree with it, or defend any choices you’ve made. You’re going to get opinions you don’t like (you’re never going to be able to please everyone), and you don’t have to act on everything. The key thing is to develop a thick skin, don’t take anything personally, and try to always think of feedback as an opportunity to make things better.