Somebody on your team writes "15-20 hours of gameplay" on the Steam page. Nobody checks the arithmetic. Six months later the game is four hours long, the last third is a grey-box, and the only way to reach fifteen hours is to count the time players spend lost.
Playtime is not a marketing adjective. It is a budget, and it is the one budget indie teams almost never write down. You can price it the same way you price art or audio: pick a target, measure what one unit of content actually costs, divide, and look at the number honestly before you commit to it in public.
Start from minutes, not from hours
An hour of gameplay is not a thing you can build. It is an emergent result of building rooms, encounters, conversations, puzzles and levels. So the first move is to name your content unit — the smallest chunk your team actually produces and schedules.
Most projects have two or three:
- A platformer: a room or screen, plus a boss.
- A narrative adventure: a scene (one location, one conversation set).
- A tactics game: a mission map, plus an enemy type.
- A roguelike: a room template, an item, an enemy.
- A puzzle game: a puzzle.
Pick the unit you can count in a task board. If you cannot write "build one of these" as a ticket, it is not your unit.
Measure the two numbers that matter
For each unit you need two figures, and both come from reality rather than optimism.
Minutes per unit (first play). Not your time — you know every solution. Use playtest timings from people who have never seen the build. If you have telemetry on level-enter and level-exit events, you already have this; if not, a stopwatch and five testers is enough to start.
Build days per unit. Take the last three units you finished and count calendar days from "ticket opened" to "nobody is still touching it" — including audio, the bug that showed up in the next playtest, and the second pass after feedback. The number will be uncomfortably bigger than your estimate. Use the uncomfortable number.
A typical small-team table looks something like this. Treat the figures as the shape of the calculation, not as industry norms — yours will differ:
| Content unit | Minutes per unit (first play) | Build days per unit | Minutes bought per build day |
|---|---|---|---|
| Combat room, existing enemies | 2.5 | 1.5 | 1.7 |
| Puzzle room, new mechanic | 4 | 6 | 0.7 |
| Dialogue scene, 1 location | 6 | 3 | 2.0 |
| Mini-boss, reused art | 3 | 5 | 0.6 |
| Full boss, bespoke everything | 7 | 20 | 0.35 |
| Cutscene, in-engine | 1.5 | 4 | 0.4 |
That last column is the only one your schedule cares about. It tells you something uncomfortable and useful: dialogue scenes and simple combat rooms are the cheap hours, bosses and cutscenes are the expensive ones, and the player does not experience them in proportion to what they cost you.
Do the division before you promise anything
Now the arithmetic. Say you want a six-hour game — 360 minutes — from a team of three with nine months of production left, call it 150 working days each, so roughly 450 person-days. Reserve a third for systems, UI, store page, porting and the final bug month, and you have about 300 person-days of content budget.
At an honest blended rate of 1.2 minutes of gameplay per build day, 300 days buys you 360 minutes. The budget closes — exactly, with nothing spare, which means it does not close at all. Any of these will break it: one boss more than planned, one mechanic that needs a second pass, one team member sick for two weeks.
This is the moment the budget earns its keep. You have three honest moves and one dishonest one:
- Cut the target. A tight four-hour game that reviews well beats a padded seven-hour game. Four hours is 240 minutes; now you have 100 person-days of slack.
- Shift the mix. Trade one bespoke boss (20 days, 7 minutes) for six combat rooms (9 days, 15 minutes). Same slot in the pacing curve, half the cost, more than twice the minutes — as long as you are honest that six rooms are not as memorable as one great boss.
- Buy reuse deliberately. See below.
- Pad. Longer walks, respawning enemies, fetch chains, slower text. This always works and players always notice.
Reuse is a design decision, not a shortcut
The cheapest minutes in your game come from combinations. One enemy that only charges plus one enemy that only shoots plus one narrow corridor gives you three distinct fights for the price of two enemies and a room. This is why roguelikes and tactics games get long: their unit cost is near zero once the systems exist.
Decide your reuse ratio up front and write it into your level plan: what fraction of units introduce something new, and what fraction recombine what exists. A pattern that holds up in practice is roughly one in four — every fourth unit introduces a new mechanic, enemy, hazard or beat, and the three between it recombine. Teach, test, twist, then rest.
Two rules keep reuse from reading as repetition:
- Never reuse a thing in the same arrangement twice. The same archer is a different fight on a ledge, behind a shield-bearer, or in the dark.
- Cap the recombination streak at three or four units. Past that, players stop reading new combinations as new content.
If your plan has eleven consecutive rooms built from the same three enemies, the budget closed on a spreadsheet and the game is going to feel thin in playtests. That is the kind of thing you want to see in a level list before it is in a build. In GameDesignerX, laying the levels module out next to the mechanics and enemy entries makes the pattern obvious — you can see at a glance which stretch of the game introduces nothing.
Two honest thresholds to keep in mind
The refund window. Steam refunds any purchase with under two hours played, within fourteen days of purchase. If your game is under two hours, every single buyer can refund it after finishing — which does not mean you cannot ship a 90-minute game, but it does mean price, framing and expectations all have to account for it.
The abandonment point. Most players never finish most games. Design so the strongest content is not held back for the final hour: the mechanic you are proudest of should appear before the midpoint, and your best encounter should be something a player who stops at 60% has already seen.
A checklist before you commit to a number
- Content unit named, and it matches a real ticket on the task board.
- Minutes-per-unit measured on at least five first-time players, not estimated.
- Build days per unit taken from finished units, including second passes.
- Person-days of content budget calculated after reserving a third for systems, UI, store and bugs.
- Target playtime × blended minutes-per-day fits the budget with at least 20% slack.
- Reuse ratio written down and visible in the level plan.
- No recombination streak longer than four units.
- Strongest mechanic lands before the midpoint.
- Public playtime claim matches the budgeted number, not the hoped-for one.
Re-run the division every milestone
A content budget is only useful if it is alive. At each milestone, take the units you actually finished that month and recompute your real minutes-per-build-day. If the first two months bought 0.8 minutes per day against a plan of 1.2, you are not 30% behind — you are going to be 30% short at the end, and you find that out with six months left instead of six weeks.
The teams that ship on scope are rarely the fast ones. They are the ones who did the division early, wrote the number down, and let it cut features while cutting was still cheap.