Demo Design: What to Include and What to Hold Back

A demo is an argument, not an excerpt: curate the slice that proves your hook (compressed onboarding, accelerated to the loop's good state), end deliberately on a peak with the next desire visible — the wishlist ask lands on the high — and hold back the depth that rewards purchase: late systems, story payoffs, the second biome. Include enough to convince; withhold enough to want. That's the short version — the sections below get into the how, the why, and the mistakes worth dodging.

Curate; never just truncate

'The first hour' is the lazy demo, and it's usually your weakest material: logos, tutorials, slow ramp. The crafted demo edits reality: onboarding compressed (demo players accept faster teaching), the loop reached in minutes, progression accelerated so the demo's thirty minutes deliver what the full game spreads over ninety, and one taste of mid-game spectacle as a promise of depth. Honesty bounds the craft — everything shown must be truly representative — but pacing is yours to bend.

Length targets the finish: 20-45 minutes most players complete beats 90 most abandon, because the wishlist conversion happens at the end, and only finishers reach it.

Engineer the ending and the ask

Where the demo stops is its most important design decision: end on a peak — the boss down, the twist landed, the new power demonstrated once and locked — with the next desirable thing explicitly visible ('the world map unfurls, eleven regions greyed out'). The cliffhanger isn't manipulation; it's the demo doing its one job at the moment of maximum goodwill.

Then the end screen earns its pixels: wishlist button (the entire point), mailing list, Discord, release window — and a thank-you in your actual voice. Demo players who finished are your highest-intent audience all campaign; treat the final screen like the conversion page it is.

What to withhold, and what the demo teaches you

Hold back: story resolutions and reveals (demo spoilers permanently tax the full game), the systems whose discovery is the mid-game's joy, content breadth (one biome polished, not three thinned), and anything unrepresentatively rough. Carrying demo progress into the full game (save import) is a cheap loyalty gift where feasible — players mention it years later.

And instrument everything: the demo is the largest honest playtest you'll ever run — completion funnels, quit points, settings touched, plus crash reporting across hardware you've never met. The wishlists are the demo's visible yield; the data is the invisible one, and it's often worth more.

Design for the player who tells you nothing

For every player who writes feedback, dozens just quietly quit. They didn't understand the mechanic, missed the door, found the difficulty wall — and you'll never hear about it. Good design assumes silence and builds the signals in: watch where testers stall, track where sessions end, notice what nobody uses.

When you can't watch players directly, instrument the game so it tells you what they couldn't. Where players stop playing is the most honest review you'll ever receive.

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.

Plan for the bugs you won't see coming

Whatever else you take from this, build yourself a way to hear about problems. Once your game is on other people's machines, most failures happen out of sight: the crash on hardware you don't own, the save that corrupts once in fifty exits, the bug players mention in a review instead of a report.

A lightweight crash and bug reporting setup — even just Bugnet's free tier wired into your engine — turns that silence into a fixable list. The devs who look calm at launch aren't luckier; they just see their problems earlier.

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.