How Long Should Your Indie Game Be?

Exactly as long as the design stays interesting — and for most indies that's shorter than fear suggests: a dense 6-hour game outperforms the same game padded to 15, because padding is visible, reviews punish it, and most players never finish even short games. Price-per-hour anxiety is mostly a developer projection; players remember intensity and endings, not durations. That's the short version — the sections below get into the how, the why, and the mistakes worth dodging.

The padding tax and the completion reality

The instinct — 'longer justifies the price' — produces the recognizable padding suite: fetch quests, backtracking, repeated encounters, grind walls. Players name it instantly in reviews, and it converts a tight game into a bloated one at real development cost. Meanwhile the completion data is humbling: typical completion rates hover well under half even for acclaimed short games — most players experience your first hours, not your runtime total.

The strategic conclusion: invest in the hours players actually play (the opening, the core loop's density) rather than the hours that exist to be counted. A game remembered as 'no wasted minutes' wins word-of-mouth that 'long' never does.

Genre anchors and the price conversation

Expectations are genre-shaped: a narrative adventure at 4-8 hours is normal, a roguelike measures in replayed hundreds, an RPG under 20 raises eyebrows, a puzzle game lives on density. Anchor against the comparables your store page invites: players judge length within the genre conversation your tags and price started. Hours-per-dollar complaints concentrate where the genre promise and the runtime visibly mismatch.

Price accordingly rather than padding accordingly: a shorter game priced honestly with strong reviews outsells the same game padded toward a higher tier and reviewed as bloated. And replayability — systems, difficulty, NG+, routes — answers the value question more cheaply than content length ever does, where the design genuinely supports it.

Design for density, end on time

The craft target is density: each hour earning its place with something new — mechanic, twist, escalation, payoff. The cut test: if a chapter vanished, would the experience miss it or thank you? Most mid-game content fails that test in first drafts; cutting it is how 'tight' gets made. Watch your playtest funnels for the sag — where sessions end mid-game is where density failed.

And stick the landing: endings punch above their weight in reviews and memory, and a game that ends one beat before the player expected beats one that ends three beats after they stopped caring. 'Leave them wanting more' is ancient advice because the alternative — leaving them checking the clock — is what 'too long' actually means.

Friction is only good when you chose it

Challenge the player chose is fun; friction they didn't is churn. A hard boss is a choice. An unskippable cutscene on retry, a save point twenty minutes back, a menu that takes four clicks to do one thing — those are taxes, and players pay them in goodwill until it runs out.

Audit your game for unchosen friction regularly. Every annoyance you remove makes the difficulty you kept feel more fair.

Respect the player's time and they'll give you more of it

The features players praise as 'polish' are mostly respect dressed up: fast loading, instant retries, generous checkpoints, settings that stick, the game remembering where they left off. None of them are glamorous to build. All of them show up in reviews.

When in doubt, optimize the loop players repeat most. Seconds shaved off the thing they do a hundred times beat minutes added anywhere else.

The quiet work that protects all of this

Everything in this post gets undone by an unstable build. A great store page, a clever marketing beat, a perfect jam entry — none of it survives 'crashed twice, refunded'. Stability isn't a feature players praise, but it's the floor everything else stands on.

Give yourself visibility before you need it: crash reports with stack traces, a simple way for players to flag issues from inside the game, and a habit of fixing the top recurring error before adding anything new.

Putting it to work

Don't try to act on all of this at once. Pick the one change that costs you the least and pays the most this week, do it, and see what actually happens before reaching for the next.

Most of this rewards steadiness over intensity. A small improvement made every week, checked against how real players respond, outruns any single burst of effort — in this corner of game development and every other one.

The players who quit silently are your real critics. Build ways to hear them.