All of us have been asked to provide honest, unbiased feedback at one point in our lives. Have you noticed how mixed the reactions to providing this type of feedback usually is? On one hand, you have the individual asking for the feedback feeling disappointed, ‘down in the dumps,’ and feeling hurt when you provide honest, critical feedback they do not want to hear. Most of the time, these people ignore what you said or simply ‘give up’ on their project.
On another hand, you have the individuals that actually get angry and try to defend their work when you highlight what you believe is wrong with their work in its current state. You quickly find that these people didn’t want honest feedback after all, but wanted a ‘pat on the back’ in the form of honest feedback. On yet another hand, you have people that actually value your feedback, use what you provided for them, and improve upon their work thanks to the honest feedback you provided for them, no matter how negatively constructive (constructive being the keyword) the criticism may have been.
You have undoubtedly encountered people like this in your own life, and over the years, many of us have opted to tell a ‘white lie’ whenever someone asks us for honest feedback. We mean well when we do this: we value someone’s friendship, we don’t want to ruin a relationship, we don’t want to hurt someone’s feelings, etc. Our hearts are in the right place, yet honest feedback needs to be that: honest, no matter how painful it may be.
This is certainly true in indie game development. When someone asks you for your honest opinion on their indie game, you want to first be nice, smile, and tell them that it’s coming along. Of course, you should never do this, so why continue? Be truthful and honest in your feedback no matter how painful it may be. Anything less is not only giving the indie developer a false sense of accomplishment, but it is also failing to tell them exactly what is wrong with their game, and in a sense, their failure falls on you.
Be brutally honest: show that you care
By providing false feedback, does this make you a bad person? Yes and no (talk about brutally honest feedback). Let’s start with the ‘no’ portion first.
When you provide false positive feedback, you are doing it for what you believe to be the right reasons: you don’t want to hurt their feelings, you value your relationship with them, you want to keep their morale high etc. Thus, you are not a bad person because you want to keep their spirits high and do not want to hurt them in any way, yet without fully realizing it, you are hurting them.
What if nobody bothered to tell Da Vinci that his painting of The Mona Lisa looked terrible (maybe somebody actually told him this, maybe they didn’t but that’s beside the point)? We wouldn’t have been able to view one of the most well-renowned paintings in human history. Let’s fast forward to modern times: what if no one had bothered to tell Gabe Newell and his team that the first iteration of Half-Life was mediocre? Sure, they knew it, but think about it for a moment: what if they believed the first iteration of Half-Life was awesome, and they had shipped it as is? There would be no Valve, Steam, upcoming SteamOS and Steam Machine, and of course, we wouldn’t have been able to experience the great games they have released over the years.
The simple truth is this: if you care about someone’s success, you need to care enough about to tell them when their game needs improvements. When a one of your fellow indie game developers asks for your honest feedback on a new game they are working on, if it’s terrible, tell them, then explain what is terrible and provide your opinion on how they can fix the problem (or at least a source they can visit that will explain to them how to fix the problem). Ideally, they will thank you for your brutal honesty and will make strides to improve the game based on what you told them, but this isn’t always the case. Which brings us back to why we life in the first place.
‘I’m afraid they’re too thin-skinned’
I’ll provide you with some advice that I’ve given people who have come to me looking for feedback on their creative work: thick skin isn’t optional in any creative field. As a writer, one of the best ways that I grew a thick skin regarding criticism against my writing was in college. For a few semesters, I had to write poems (and I’m terrible at poetry) and short stories, print out enough copies for everyone in the classroom, allow them to read the work to themselves (sometimes quietly in class), and from there, they would all explain what they liked and didn’t like about it. And believe me, they weren’t afraid to get brutally honest very quickly.
What did this teach me? It taught me the value of not only separating ‘constructive criticism’ from ‘flat-out criticism’ (e.g. this sucks and here’s why versus this sucks /rant), but it allowed me to value the opinion of others, to take to heart exactly the advice they were providing to me, and to use it to improve my work. And you know something? When I improved my works based on the constructive feedback on others and allowed them to read through a second time, it felt great knowing they enjoyed the read much more than before.
Is it still a blow to me whenever somebody reads something that I wrote and tells me it isn’t good? Absolutely – that sting will never go away, nor should it. Yet I welcome it, and if someone takes the time to tell me my work isn’t good and explains to me why it isn’t good, I value that and appreciate it. Those that want to become indie developers need to have the same mindset, and if you provide the honest, constructive feedback a peer is asking for and they get angry, upset, etc.? You’re not at fault. If they cannot properly use constructive criticism, they need to learn a lesson on taking and using criticism for their benefit or find a new job. Again, thick skin isn’t optional.
Providing honest feedback in the best way
Is there a way to provide honest, truthful feedback that your peer will be able to use without being overcome by their feelings being hurt? Sure there is, and the best way to do it is to follow the outline below.
- Explain what you liked and disliked about the game.
- Provide them with the ‘good news’ first. What did you like about the game? What worked well for you as a player?
- Provide the ‘bad news.’ What did you dislike about the game? What bothered you about it?
- Go in-depth with the details regarding what you didn’t like about the game.
- Is the level design bad? Detail exactly what is wrong with the level design and why it’s bad.
- Does the game control terribly? Again, tell them why.
- Describe to them what can be done to improve the negative parts of the game.
- Tell them the steps they should take to improve the negative aspects of the game.
- If you are not an authority on a certain subject, provide them with someone that is or tell them you will find someone/some source that can help them to improve that part of the game.
- Provide them with ‘hope.’
- Don’t leave the discussion on a negative note.
- Let them know you are available for further discussions regarding the game if they want to discuss it further with you.
- Above all, let them know that just because their game isn’t as great as they thought it was, it isn’t the end of the world! Most likely they can salvage the game and turn it into something great.
- And if it isn’t salvageable (in your mind anyway)? Tell them, and urge them to take this experience and use it to create a new game.
Being brutally honest among your indie dev peers isn’t easy, but it’s the right thing to do. If you have any doubts on being brutally honest, ask yourself, “if I was in their position, would I want to know if my game was on its way to being a ‘bust?’” You will know the answer to that question instantly, so do your peer a favor and be brutally honest. Whether you realize it or not (and whether or not they realize it at the time), one day, they will be thankful for your honest feedback.