“We’re getting way too much feedback from players”.
I’ve heard this phrase more times than I’d like to admit during my years in the gaming industry.
And every single time, it makes me flinch a little because this statement is usually a red flag that something went wrong much earlier in the development process.
Here is my take on this:
The Real Problem Isn't the Feedback
There’s actually no such thing as “too much feedback” from players.
The real issue lies in the timing. When development teams say they’re overwhelmed by player input, it usually means one of two things happened:
- The feedback is arriving when the game is already too far along to act on it
- The feedback is completely unstructured (though that’s a whole other conversation)
When you don’t establish a proper user testing pipeline early in development, you inevitably end up in a situation where you’re testing the entire game all at once.
At that point, you’re just confirming problems you should have discovered and solved months ago.
A Real-Life Example
This reminds me of a AAA title our team at Antidote worked on a while back.
When the project came to us, our UX team immediately started uncovering significant issues. We’re talking about fundamental problems with difficulty curves, pacing issues and (perhaps most critically) a massive disconnect between what players expected vs. what the game actually delivered.
The findings were comprehensive and honestly, not that surprising to anyone who had been paying attention to player behavior patterns in similar games.
But here’s where the story takes a frustrating turn:
By the time the project reached our desks, the game was essentially built.
The core systems were locked in. The difficulty progression was hardcoded into level design that had already gone through multiple art passes. The pacing issues were baked into a narrative structure that couldn’t be fundamentally altered without rebuilding entire sections of the game.
When "Tweaking" Isn't Enough
What could the team do at that point?
They focused on what was still refinable – UI adjustments, some numerical tweaks to weapon damage, minor adjustments to enemy spawn patterns. Surface-level changes that, while helpful, couldn’t address the core structural issues our testing had revealed.
The game was eventually shipped and sadly, it didn’t receive the reception it expected and truly deserved.
The reviews echoed many of the issues we’d identified in testing:
- “pacing feels off”
- “difficulty spikes come out of nowhere”
- “not what I expected based on the marketing”
Not the best outcome.
The Iterative Testing Mindset
This experience reinforced something I believed for years: playtesting, or user research for that matter, shouldn’t be a last-minute checkbox on your development timeline.
It should be woven into the fabric of your entire development process, starting from the very first concept or prototype.
Think about it this way: when you test early and often, each round of feedback addresses a smaller, more manageable set of variables. Test a core mechanic in isolation and players might tell you it feels sluggish. Fix that before you build ten levels around it and you’ve saved yourself weeks (or months) of rework.
Test your onboarding flow before you’ve created 40+ hours of content and you might discover that players are getting confused about a fundamental system.
Address that early, and every subsequent piece of content benefits from clearer player understanding.
Build Testing Into Your DNA
The most successful projects we’ve worked on treat user feedback as a compass.
They’re constantly checking in with players, asking small but crucial questions:
- Does this core loop feel engaging after 10 minutes? After an hour?
- Are players understanding this mechanic the way we intended?
- Is the difficulty curve creating the emotional experience we want?
- Do players have the right expectations going into this section?
When you approach testing this way, feedback becomes a tool for refinement rather than a source of overwhelming criticism.
You’re iteratively improving specific elements before they become load-bearing walls in your design.
Start Small, Test Often
If you’re working on a game right now, here’s my advice: start testing something this week.
It doesn’t have to be perfect or complete.
Got a single mechanic working? Get it in front of a few people and see if it clicks.
Have a rough level layout? Watch someone navigate it and see where they get confused.
Working on UI mockups? Show them to potential players and observe their first reactions.
The goal isn’t to get perfect feedback, it’s to start building that testing pipeline and iteration mindset that will serve you throughout development.
Each small test now saves you from overwhelming feedback later.
The Bottom Line
When someone says “we’re getting too much feedback”, what they usually mean is “we’re getting feedback we can’t act on”.
So the next time you hear someone complain about this, maybe the real question should be how to start testing early enough that the feedback feels manageable and actionable.
Trust me, your future self will thank you!
