Demo Design: Picking the 20 Minutes That Decide Whether Players Come Back

Most first demos ship the first twenty minutes of the game. The logo, the slow walk through the village, the tutorial that teaches jumping, and then — just as the interesting mechanic finally unlocks — a card that says "Thanks for playing!"

Players did not see your game. They saw your onboarding. A demo is a separate design deliverable with its own goal: convince a stranger, in one sitting, that the full game is worth their attention. That usually means shipping the part of your game that is actually good, not the part that happens to come first.

Here is a workflow for choosing that slice, budgeting it, cutting it down, and instrumenting it so the demo teaches you something too.

A demo is a product, not a build branch

Three different things get called "the demo", and conflating them is where teams lose weeks:

• A press build — forgiving, skippable, often with cheats enabled, sent to maybe thirty people.
• A playtest build — instrumented, unpolished, meant to answer a specific question.
• A public demo — a shipped product with a store page, a support burden, and no patch for the weekend you are asleep.

Only the third one needs capsule art, a crash-free first five minutes, and a version you can defend. Decide which you are making before you scope it. If the answer is "all three", you are making the public demo and using it badly for the other two jobs.

Pick the slice with three candidates, not one

Do not debate the demo slice in the abstract. Write down three concrete candidates and score them. A scoring pass takes an hour and ends the argument.

Candidate	Shows the hook	Standalone	Build cost	Spoils
Opening village + first dungeon	Weak — hook unlocks at minute 25	High	Low	Nothing
Mid-game heist with full toolkit	Strong	Medium — needs pre-set loadout	Medium	One map
Bespoke side mission, demo only	Strong	High	High	Nothing

Four criteria, scored high/medium/low:

1. Does it show the hook? The one sentence you use to describe your game — can a player feel it inside five minutes? If your pitch is "grappling-hook courier in a vertical city", a demo with no grappling hook in the first minute is the wrong slice, however polished.
2. Does it stand alone? Can a cold player understand the goal without the plot that precedes it? A heist is legible with no setup. A betrayal is not.
3. What does it cost to carve out? Mid-game slices need pre-set loadouts, unlocked abilities, and an escape hatch where the rest of the game used to be.
4. What does it spoil? Spending your best boss on the demo is a real cost. Spending your third-best is usually fine.

The bespoke demo mission often wins on design and loses on cost — it is a whole level nobody plays in the shipped game. For a two-person team, a mid-game slice with a pre-set loadout is usually the right trade.

Budget the minutes before you build

Fifteen to twenty-five minutes of content is a sensible target for a first public demo: long enough to teach a system and let a player feel competent with it, short enough to finish in one sitting. Write the budget as a table and treat it as a constraint, the way you would treat a memory budget.

Segment	Target	Purpose
Boot to player control	under 60s	No logos you can skip building, no unskippable cinematic
Teach the core verb	2–3 min	One verb, no text walls
First real use of the verb	4–5 min	Player succeeds at something
Complication	5–7 min	Add a second system, or a pressure
Payoff beat	3–4 min	Set piece, mini-boss, or escape
End card	30s	Ask for the one thing you want

If a segment overruns in playtests, cut inside that segment rather than stealing from the payoff. The payoff is the part players describe to friends.

Cut aggressively, then add demo-only scaffolding

Things to cut from the demo even though the full game needs them:

• Settings menus beyond audio, controls, resolution, and your accessibility toggles.
• Side content that branches away from the slice — a demo map with four exits and one that works teaches players your game is broken.
• Collectibles with no payoff inside the demo.
• Any cutscene over 45 seconds.
• Difficulty options you have not tuned. Ship one well-tuned curve rather than three guesses.

Things to add that only exist in the demo:

• A pre-set loadout. Hand the player the abilities the slice assumes, with a one-screen card naming them.
• A hard stop. Design the boundary. A locked door with a reason beats an invisible wall.
• An end card that asks for one action. "Wishlist" or "join the Discord" — one, not both. Put it before the credits, not after.
• Save carry-over, or an explicit promise not to. Players will ask. Answer it on the store page, not in a support email.

Instrument it like a playtest you cannot attend

A public demo is the largest playtest you will ever run, and you will not be in the room for any of it. Six events are enough to learn what you need:

1. demo_start — with build version and platform.
2. segment_enter — one per segment in your budget table.
3. death or fail — with location and cause.
4. core_verb_used — counted, bucketed per minute.
5. demo_complete — reached the end card.
6. quit — with elapsed time and current segment.

That gives you a funnel across segments, a death heatmap, and the one number that matters most: how many players reach the payoff beat. If most quit during the "teach the core verb" segment, the problem is not your marketing.

Keep the raw numbers wherever you already track metrics, and keep the decisions somewhere durable — if you use GameDesignerX, the playtesting module is a reasonable place to park session notes and the balance sheet next to the build they describe, so next quarter you still know why you shortened the tutorial.

Freeze checklist

Work backwards from the publish date. Two weeks before is not too early for the freeze.

• Demo slice locked, no new content after freeze
• Runs on your minimum spec machine, start to end card, twice
• Controller and keyboard both fully playable, including menus
• Remapping works, or is honestly absent from the store page
• Subtitles on by default
• No placeholder audio, no debug text, no developer console binding
• Analytics events firing, verified in a clean install
• Store page: capsule art, one 30-second trailer, five screenshots that are not all the same room
• A build number visible in a corner or the pause menu — you will need it for bug reports
• Someone who has never played it finishes it unaided, on video

That last item is the only true gate. If a fresh player cannot reach your end card without a developer in the room, the demo is not finished regardless of what the checklist says.

After it ships

Give yourself a window — a week or two — then do a single pass. Read the funnel, watch three recordings end to end, and write one page: what players did, what they said, and the three changes you are making to the full game as a result. File it with your milestones so the next demo starts from evidence instead of memory.

The demo's real output is not wishlists. It is the first honest data you have ever had about whether your hook lands on people who owe you nothing.