Game Jam Success 6: Giving and Receiving Feedback

Would you prefer to listen to the post? Here’s a recording. You can also click the ellipsis to download the .mp3 file and listen from any device.

The final step in the game jamming process is to gather feedback for your game, and – more importantly – to provide feedback for your fellow jammers.

As we said way back in the beginning, game jams are all about rapid iteration and improvement. Everyone has done the rapid iteration part. The only way to improve is to hear how other people feel about the final result, and to receive critical feedback from those who have gone through the same experience.

Sure, it’s annoying when you post a dozen deep, heartfelt reviews and only get one bite with an “its good bro.” But giving feedback is good practice even if the other fail to reciprocate. Analyzing games will help you grow as a developer.

Every time you play a game with a critical mind, you become a better game designer, composer, artist, or programmer by seeing what works and what doesn’t. Examining a game saves you the trouble of having to develop it yourself. Next time you face a similar situation in development, you’ll have a ready-made prototype to reference.

Providing Excellent Feedback

Let’s first look at this from the eye of the reviewer, the critical player aiming to give useful insight into their experience.

(1) Provide a initial sense of how the game made you feel.

Avoid being too analytical on your first impression. This is the only chance you get to show the dev how a player similar to you will react when playing the game the first time.

Include a bit of context in the review. Sure, you either liked the game or didn’t, but why? What kinds of games do you usually like? Can you explain how the game made you keep – or stop – playing?

(2) Break down the parts of the game – and focus on the ones you know best.

After the first impression, get analytical. Break down the design to find parts that worked or didn’t work for you. Talk about audio, graphics, technical implementation, narrative, polish, juice, feel, and any other parts of the game. Focus on what you know best.

Are you an artist? Offer some advice on how to make the art really shine, or say which parts stood out as excellent.

Are you a programmer? Point out bugs and potential solutions.

Are you an audio person? Suggest ideas for missing sounds, or how the soundtrack could be improved.

(3) Compare and contrast to similar experiences.

Mention games you have played that provide a similar experience. Even if the developer doesn’t know the game, they can research to learn more about their project by making a comparison. On the other hand, they may agree with the similarity, having considered those games while coming up with the idea. This can be a real boost for any developer, knowing their inspirations were clear.

Whenever you suggest a change or refinement, try to reference a specific game. Again, the dev may be familiar with the game, making the analogy easy to understand, or not, in which case they can look up gameplay, if not play the game themselves. This can help to clarify your ideas.

(4) Be honest and critical, but also respectful.

Treat the developer like they’re on your own development team. You both want the game to succeed, so be as critical as possible while striking a balance with positive notes. Every developer wants their game to be the best it can be* and it’s important to recognize that effort.

A huge part of respect is phrasing your feedback as what it is – your opinion. Very few things in game development have hard and fast rules, once you get past the technical basics, like not crashing. You don’t need to say “in my opinion” with every sentence, but do try to phrase the feedback in that context. Adding a bit of elaboration can help a lot with this.

For instance, you might say “Spikes should kill in one hit.” Provide more information and context. For instance, “Most platformers I’ve played kill the player in one hit when they touch spikes, so I was confused when I landed on the spikes and didn’t die instantly.” This is much more helpful because (a) it tells the developer more about your line of thinking and (b) gives the developer a comparison.

*Except trolls. Don’t review troll games. That’s feeding the trolls.

Receiving Feedback Like a Pro

Now that we’ve seen one side of the equation, let’s look at the other.

Receiving feedback may seem easy. All you do is listen, right? Yes, but you must also work at making optimal use of the feedback you do receive – and listening can be more difficult than it seems.

(1) Shut up.

Sorry if that comes off as rude, but these are the words you should repeat in your head while listening to (or reading) feedback. Take a deep breath, listen or read carefully, and take notes. Don’t respond to a written review until you’ve had some time to process all of it, and don’t say anything while watching someone play your game (whether in-person or on stream).

The worst thing you can do in a live situation is influence the reviewer. You want to know what it’s like for a new person to play the game on their own. You won’t be standing behind every player offering them advice and pointers, so see how the reviewer does without a single word from you. The feedback will be significantly more valuable.

This is the most difficult part of receiving feedback on a game, especially in a live situation. You will see the player struggle, do the “wrong” thing, miss things you thought were obvious, and possibly ruin your carefully crafted experience. Take what you can from these observations to learn how to steer the player better in your next iteration.

If the player asks you a direct question, it’s okay to respond. Try to be as brief as possible to avoid veering into the problem areas mentioned above.

(2) Start with a “thank you.”

The time to respond is after the live play has finished or you’ve read the written review multiple times.

The reviewer spent valuable time playing your game and went the extra mile to tell you about the experience. Cherish every bit of criticism that helps improve the game. Thank them profusely, and they’ll be back to help you again in the future.

(3) Avoid making excuses – instead, agree or disagree with the feedback.

All game jams are run under a time limit. That’s where the “jam” part comes in. People who play and review game jams are aware of this, and know that corners must be cut in order to ship a prototype by the deadline. Life also happens to all of us.

A review might say, “You should do X,” and you must resist the temptation to respond with, “Well, we didn’t have time.” Instead, agree with the suggestion if you have it on your road map, or thank them for the idea if it’s a new one and you agree. Let the reviewer know your thoughts are going in the same direction, and they’ll be even more excited for the next release.

The reviewer may suggest a change you already considered and threw away, because you tested it and it didn’t work, or it clashes with your vision for the game. Reconsider that change even if you feel totally averse to it, especially if multiple people make the same suggestion. The outside perspective might provide new insight on the idea.

(4) If you have future plans, let them know.

The reviewer has already shown interest in your work, so it’s likely they’re going to want to see how it develops, regardless of how critical their review may have been. Tell them about your future plans for the project.

Conclusion

Writing a postmortem is a great way to look back on a game jam and your game development process. This is simply an article examining what went right, what went wrong, and what you’ve generally taken away from the project.

Take notes now so you don’t forget the details of the week or weekend, but give yourself breathing time before reflecting. When you’re ready, write bullet points for the three sections: what went right, what went wrong, and what you’ve learned. Expand on these bullet points as possible.

Share this postmortem as a devlog and on social media. This is a great way to help other developers who have an eye on your work, to keep track of your own personal growth as a developer, and to drive traffic to your game for even more feedback.

What’s the most useful feedback you ever received? How did it improve your game or future games? Let us know in the comments!

These articles have barely scratched the surface of game jams. We will dive deeper into these topics in the future. For now, check out our game developer interviews on YouTube for more tips and keep on participating in our game jams and weekly challenges. Nothing improves a skill like putting it to use!

Leave a Comment

Your email address will not be published. Required fields are marked *