Better to die on your knees than live on your feet
Better to die on your knees than live on your feet
A little while back, I wrote up a post giving tips on how to create and publish your own game. One of the tips I gave was to get good feedback, with some advice on what sort of things you should look for. In retrospect, keeping it to three or so paragraphs wasn’t really enough - receiving good feedback that really makes a difference to your product can be a fairly detailed process, and I reckon it could do with a bit more information than I’ve previously given. This is based on my experience and what’s worked for me - hopefully it can work for you too!
Giving feedback can be kind of hard for someone - they might have mixed feelings about how they feel about something, or might have issues working out how to put their thoughts into words. This goes doubly for when they’re asked how they felt about something that didn’t leave much of an impression on them, or which they barely remember. Sure, that’s feedback in and of itself, but it’s not very helpful.
If you know what sort of areas you’re really looking for feedback on - the ones where you’re unsure how well it works, or whether it’s producing the emotion you’re aiming for - then let your playtesters know about it ahead of time. Giving them a copy of your game with a note of, “I’m unsure how balanced the third level is - could you please let me know how you feel?” will have them thinking more critically when they play it, and thus they’ll have more information for you to dissect when they get back to you with their thoughts. Provided you don’t go overboard with it (“Please give me your thoughts on the first level, and the second, and the third, and…” is probably just going to overwhelm players), this will help playtesters know what to focus on and where they should possibly spend more time.
This might sound like it goes completely against the general idea of feedback, but bear with me. When you’re initially coming up with a game idea, there are probably a handful of dot points that are the really appealing parts of it, the main selling points. Maybe it’s a cool gimmick, maybe it’s a great plot twist, whatever. These are the main things that you probably want to focus feedback on, and where you should really be paying attention to your playtesters.
So if, say, you’re developing a fighting game with a colourful roster of characters, a player says to you, “I wasn’t impressed with the story,” that’s probably fine. While a good story could help enhance your game and appeal to more players, odds are that the majority of your potential player base isn’t too fussed about it. Similarly, if you’re developing a point-and-click adventure and someone says that they wanted more action sequences, that could mean that the story’s a bit slow and needs to shake things up a bit - or it could mean that that playtester isn’t used to the slower pace of point-and-clicks and that they’re not your target audience. It depends upon the specific feedback, of course, but there’s going to be times when you’ll hear something that just isn’t that relevant to you. After all, if you try and appeal to everybody, you’ll appeal to nobody.
Alright, so you’ve gotten some good feedback from players about areas of the game that really needed it, and you’ve worked out what doesn’t apply to your game. There’s just one issue, and it’s a big one: the fixes required to address the feedback would be massive, and they’re definitely necessary.
Maybe it’s a significant change to the game’s story. Maybe one of the game’s mechanics just isn’t working as well as you thought that it would. Maybe it’s a bug that you thought was difficult to trigger, which the player’s managed to find. Whatever it is, changing it is going to suck. Although the temptation to ignore the feedback is high, given the work it would require, or how it might change something that you’re happy with, my advice is to go ahead and do it, as painful as it might be.
There are several reasons for this. Firstly, if one person has issues with this major element, there’s a good chance that others might too. Secondly, you’ll improve the overall work. Yeah, that sounds obvious, but what I mean is that changing that one element will probably mean changing other things that involve it - other game mechanics, other parts of the story, other characters, whatever. You’re not just strengthening one part of the game when you make a big change - you’re strengthening multiple. Thirdly, having to address the feedback will be a bit of a limitation that you have to deal with, and limitations will help you be more flexible and creative. You’ll hopefully find a much nicer solution, one that wouldn’t have occurred to you without the feedback and the need to change things.
I realise how obvious this sounds, and I imagine most people reading this will be rolling their eyes. “Of course I know not to take it personally; I wouldn’t be asking for feedback if I couldn’t take criticism!” Yeah, when you’re taking a step back and thinking about playtesting in the abstract, it’s easy to think about how you’ll do things and to genuinely plan on doing things that way. Humans are emotional creatures though, and the way our emotions make us feel isn’t always the way we want to be.
So, to put it simply: don’t take it personally. If somebody doesn’t like an aspect of your game, that doesn’t mean that they’ve got something against you, and it sure as heck doesn’t mean that you’re a failure. All that it means is that they’ve formed an opinion about your game, and that if you want, you can try and do your best to address it and change that opinion. That’s part of the whole feedback process, and it’s okay for someone to disagree with you on something in your game.
Feedback is arguably one of the most important tools in the development process of any project, but it can be a bit of a double-edged sword. What do I mean by that? Well, let’s say that someone gives you feedback on your game and you make changes required to address the feedback. All sorted, right? Well, how do you know that the changes have successfully improved the game in a way the person was looking for? Are they even better, or do they now detract from the overall experiences? There’s only one way to find out, and that’s to get feedback from that person on how the changes go. If they’re not a fan, you might have more changes to make from there…you can probably see where this is going.
I said it earlier and I’ll say it again: if you try to please everybody, you’ll end up pleasing nobody. As important as feedback is, at some point you’re going to have to accept what you have - maybe that means scrapping changes originally made in response to feedback, maybe it means acknowledging that one component of your game doesn’t match your vision, and possibly never will. There’s no such thing as a perfect game, or one without flaws, and while you’ll hopefully be able to navigate things so that your game has as few issues as possible, you’ll also need to accept that they’ll be some things that can’t be fixed that easily.
As with many things involving the arts, feedback is not so much a precise tool as it is a bit of a gut feeling and some instincts. It is the sort of thing that you tend to learn more through experience than anything, but hopefully these tips will have helped you learn about the process and how to get the most out of it.
Speaking of feedback - how did I do? Was this information helpful, useless, or somewhere in-between? Was there any advice that I missed? Let me know and if I need to, I’ll do a follow-up article! Until then, stay safe and stay excellent.
Back to news
