Why Indie Devs Should Play More, Code Less

There's a specific kind of indie game that Steam is absolutely drowning in right now. Technically competent. Systems that work. Art that's fine. And somehow completely dead on arrival. Nobody wishlists it. Nobody finishes it. The developer, who clearly put in hundreds of hours, posts a bewildered launch-day thread asking what went wrong.

Imphenzia—indie developer and educator with a substantial YouTube following—thinks he knows what went wrong. And his answer, delivered in a recent five-minute video, is not about the code.

"The hundreds or thousands of hours you work to create your game may be useless if your game doesn't feel right to the players," he says. "And the only way that you can make it feel right is to understand the genre so deeply that you, yourself, feel the enjoyment in your bones."

His prescription: stop building and start playing. Obsessively. His specific target is 100 hours in the genre you want to make, playing the top two or three games until you're performing at what he estimates is the top 10% skill level. Not casual play—player-researcher play, with notes. What moment made you laugh? What made you scream and immediately try again? What actions feel rewarding? What annoys you?

It's a genuinely interesting argument, and one that cuts against how most aspiring developers think about skill-building.

The Tacit Knowledge Problem

The core of what Imphenzia is describing has a name in cognitive science: tacit knowledge. It's the kind of knowing that lives in your hands and gut rather than your head—the stuff you can't fully articulate but can immediately recognize when it's absent. A chef who's eaten thousands of meals knows what "balanced" tastes like without being able to write a formula for it. A skilled editor knows when a sentence is dead before they can explain why.

Games have enormous amounts of tacit knowledge baked in. The exact amount of controller feedback that makes a jump feel satisfying rather than floaty. The rhythm of an encounter that feels fair-but-hard versus unfair-and-cheap. The precise speed of a UI animation that reads as snappy versus jarring.

None of this lives in GDC talks or YouTube tutorials. Imphenzia is direct about this: "You can watch 200 YouTube videos. You can listen to every GDC talk and still make a game that feels off. And players smell inauthenticity."

That's a strong claim, and I'd argue it's largely right. The gap between knowing a design principle and feeling it is real, and it's the gap where most technically proficient indie games fall apart. You can know intellectually that Celeste's coyote time exists—that the game gives you a few extra frames to jump after walking off a ledge—without having felt the difference between a platformer that has it and one that doesn't. Knowing the term doesn't give you the muscle memory to implement it correctly, and more importantly, doesn't give you the player-side instinct to notice when your own implementation is slightly wrong.

The Review Mining Layer

Beyond the play-it-yourself argument, Imphenzia adds a market research dimension that's worth taking seriously on its own terms. His second step is to systematically analyze Steam reviews of successful games in your genre—positive reviews to map what players love and expect, negative reviews to find the exploitable gaps.

"Every negative is an open window," he says.

He cites Clair Obscur: Expedition 33 (he admits he's probably mispronouncing it) as a recent example: a turn-based RPG that broke through partly because it addressed years of accumulated player complaints about static, boring combat by injecting real-time mechanics. That's not an accident of inspiration—it's what happens when a team has read the genre's negative reviews closely enough to know exactly what itch hasn't been scratched.

This is the kind of insight that tends to feel obvious in retrospect and completely invisible beforehand. The negative reviews of dominant games in any genre are essentially a free product roadmap. Players are telling you exactly what they'd pay for if someone built it right.

Imphenzia acknowledges you can now run this analysis through AI—paste reviews into a chatbot, ask for a summary of complaints and praise. That's efficient. But he's also careful to add that if you want to actually internalize the feedback, reading it yourself is worth the time. There's a difference between knowing the summary and having sat with 100 individual player voices in your head.

The Tension Worth Naming

The argument is coherent. There's real experience behind it—Imphenzia describes spending time deep in Celeste, Dead Cells, and Hollow Knight before building Unfair Rampage, his precision platformer, breaking down "the movement, the jump trajectories, level design, pacing, progression, balance, challenges, and rewards." That's not someone talking theory. That's a process.

But here's where I'd push back a little, not to undermine the argument but to sharpen it: genre immersion is necessary but not automatically sufficient, and it carries its own risk.

The developers most thoroughly immersed in a genre are often the ones most likely to make something that feels like competent genre execution—correct in every local decision, somehow inert as a whole experience. Deep familiarity can breed a kind of invisible gravity toward the center of the genre rather than away from it. You learn the unwritten rules so well that breaking them feels wrong even when breaking them would be the right call.

Imphenzia addresses this directly—"you must know them so you can break them on purpose"—but the instruction is easier to give than to execute. Knowing that you should subvert an expectation and having the confidence to actually do it when your hands know what correct feels like are different things. The genre passion question runs underneath all of this: playing deeply in a genre you already love is much more likely to generate genuine insight than grinding through one you chose for market reasons.

There's also an access dimension that goes unmentioned. Spending 100 hours playing games before you write a line of code is advice that functions differently depending on your situation. For a developer with a day job and limited hours, it represents a significant time investment that delays any forward progress. Whether that trade-off makes sense depends on the specific project and the developer's current experience level. Someone who's already shipped three platformers has already internalized a lot of what those 100 hours would teach.

The Part That's Underrated

What I find most useful in Imphenzia's framework is the structured output at the end—not the general principle, but the specific deliverable he assigns.

After your 100 hours and 100 reviews, you're supposed to write down three things: one feeling you want players to have, three things you will never do because players hate them, and one expectation you're going to exceed. That's it. Not a game design document. Not a feature list. Three sentences that function as a north star.

That constraint does real design work. It forces a specificity that most indie devs avoid because specificity means commitment, and commitment means you can be wrong. It's easier to stay vague and preserve the feeling that you're making something for everyone. But games made for everyone tend to satisfy nobody—a dynamic that shows up in review sections over and over, where the negative reviews say some version of "this didn't have enough personality."

The homework is blunt and a little aggressive in how he frames it—"the cruel action you must take upon yourself right this minute"—but the underlying logic is sound. Before you build a system, know what feeling that system is supposed to produce. Before you design a level, know what players in your genre hate so you don't accidentally build it.

Most of the games clogging the Steam release queue in 2026 were made by developers who knew exactly how to build the thing. The question Imphenzia keeps returning to is whether they knew what the thing was supposed to feel like when it worked. Those are different kinds of knowledge, and only one of them ships a game anyone remembers.

By Mike Wierzbicki, Game Development & Industry Reporter, Buzzrag