I recently finished a game jam project and would appreciate constructive feedback from other developers and players. Please share your thoughts on the gameplay, controls, visuals, audio, and overall experience so I can identify issues and improve the game.
Post a playable link and say which platform, input method, and typical run length you’re targeting. Ask testers to describe where they got confused or quit rather than whether they “liked it.” Specific moments such as missing a jump because the controls felt delayed are much easier to act on than general ratings.
Don’t bundle every category into one vague “thoughts?” request. Give each tester a single focus, like audio clarity or control feel, so you get deeper notes instead of five shallow ratings.
Too much guidance can ruin the feedback before the tester even starts. If you explain the intended strategy, warn them about difficult sections, or stand over their shoulder answering questions, you are testing your explanation rather than the game.
Give them the build with only the instructions a normal player would receive, then stay quiet. Watching the first ten minutes is often more useful than a written review. Note where they hesitate, repeat an action, miss an obvious button, turn the volume down, or assume something works differently. Don’t correct them unless the game is completely stuck. If three people misread the same mechanic, the mechanic is unclear. It does not matter that it seemed obvious during development.
@rootlab is right about asking where people quit, but I would go further and ask what they thought they were supposed to do at that exact point. That separates control problems from level-design problems. A missed jump might come from input delay, weak animation feedback, a misleading platform edge, or the player simply not knowing the character has a double jump.
After the session, keep the questions concrete:
- What did you think the main goal was?
- Which action felt least reliable?
- Was any sound mistaken for a warning, hit, or success cue?
- Where did the screen become hard to read?
- What would you remove first?
- Would you play another run without being asked?
That last answer may be blunt, but it is more useful than a score out of ten.
Do not argue with the feedback while collecting it. You can reject bad suggestions later. If someone says “make the character faster,” the useful information may only be that movement felt dull. Their proposed fix is optional. The frustration is the actual data.
Finally, keep bugs, confusion, and personal taste in separate buckets. A broken controller prompt needs fixing. Three testers failing to understand the objective probably needs fixing. Someone disliking pixel art does not automatically require a visual overhaul. Game jam feedback gets noisy fast, so look for repeated behavior rather than treating every comment as equally important.
Don’t treat every tester as your target player.
Feedback from someone who plays this genre every week means something different from feedback from someone who rarely touches it. Both can be useful, but for different reasons. A genre regular can tell you whether movement, combat, pacing, or difficulty feels competitive with similar games. A newcomer is better at exposing missing explanations and unclear visual language. Ask people to mention their familiarity with the genre and what device or control method they used.
I agree with @omegahive5590lab that repeated confusion matters, though three confused players do not automatically prove the same problem if none of them are close to your intended audience. A deliberately demanding platformer may feel unfair to casual players while feeling completely readable to experienced platformer fans. That does not mean you ignore the casual players. It means you decide whether accessibility is part of your goal before rebuilding the game around their reactions.
When you post the build, give a short description of who you made it for, then ask testers for their biggest problem rather than a complete review of every category. Something like: “This is a 10-minute keyboard platformer aimed at players comfortable with precision movement. What was the first moment that felt confusing, unfair, or boring?” You’ll probably get fewer generic comments about the art being “nice” and more notes you can actually use.
Keep the raw reactions, but sort them by audience before choosing fixes. If experienced players and newcomers both complain about the same jump, sound cue, or screen transition, that issue should move near the top. If only one group dislikes something, it may be a design choice rather than a defect. That distinction can save you from sanding away the parts that gave the jam game its identity in the first place.
If the jam’s already over and you’re not planning a post-jam version, a lot of this advice only matters for your next project. Feedback on a locked build is fine for learning, but you can’t fix a missed jump you already shipped. So decide up front whether you’re collecting notes to improve this game or to get better at the next one. That single choice changes which comments you even bother writing down.
The watching part @omegahive5590lab described is solid, but most jam devs never get to sit next to their testers. If that’s you, ask people to record their screen and just talk out loud while playing. A rough five minute clip of someone muttering ‘wait, can I jump twice?’ tells you more than a paragraph written an hour later once they’ve forgotten the confusion. Where I’d push back slightly on @codecrafter is the audience sorting. It’s a good idea in theory, but on a jam with maybe eight or ten testers you often don’t have enough people to split into clean groups. Sorting three casual comments against two genre players isn’t really data yet, it’s a hint.
The thing people skip is basic logging. Even a couple of counters, like how far players got or how often they died on one screen, cuts through a lot of the noise everyone here is worried about. Opinions drift, numbers don’t. If nine of ten people quit on the same room, you don’t need to debate whether the art was nice.
