Flukz — open-source shmup community resource open-source GPL devlog  ·  about
// indie shmup & game-dev resource

Game Dev · July 6, 2026

Designing a Demo Build for an Indie Shmup: What to Include and What to Cut

The default instinct is to demo the first stage, since it is the part of the game that exists earliest and needs the least explanation. That default is usually the wrong choice for a shoot-em-up.

A demo has a different job than the full game: it needs to convince someone who has never played your game, in a session that might last five to ten minutes, that the full experience is worth their money and their time. The first stage of most shmups is deliberately gentle — sparse enemy waves, a slow ramp into the mechanics, patterns that teach rather than challenge. That design choice is correct for the full game's difficulty curve, discussed in designing difficulty curves that feel fair, and it is close to the worst possible choice for a standalone demo, which needs to hook a player fast rather than ease them in gently.

A demo needs its own difficulty curve, not a slice of the real one

The strongest shmup demos compress a difficulty arc that would normally span an hour of the full game into ten minutes: a short, genuinely gentle opening (maybe ninety seconds, not five minutes) followed by a rapid escalation into the kind of dense, visually striking patterns that show off what the game is actually about, capped with a boss fight that demonstrates the full moveset even if it is a simplified or shortened version of a later-game encounter. Players evaluating a demo are asking "is this fun at its best," not "is this a fair, well-paced introduction" — the demo's job is closer to a highlight reel with playable connective tissue than a faithful miniature of the opening hour.

Scope the demo like a game jam entry

The scoping discipline covered in building a shmup for a game jam transfers almost directly to demo design: pick the smallest set of content that fully demonstrates the core loop, cut anything that requires the player to already understand systems from later in the game, and resist the urge to include a little bit of everything. A demo with three mediocre partial systems reads as unfinished; a demo with one complete, polished vertical slice reads as a promise the full game can keep.

What to explicitly cut from a demo

Save data and demo-to-full-game continuity

A frequently overlooked detail: demo save data should not silently carry over into the full game purchase, since players are often confused about whether their demo progress persisted, and mismatched expectations here generate support requests and frustration for very little actual benefit. If continuity is desired, make it an explicit choice at first launch of the full game ("Import demo progress?") rather than an automatic, invisible behavior. This is the same category of explicit-choice-over-silent-behavior principle discussed in cloud saves and cross-platform sync, where surprising players with automatic data decisions consistently causes more frustration than it saves in convenience.

Timing the release

Demo release timing matters as much as demo content. Aligning a demo launch with a platform-wide discovery event, where many players are actively browsing new demos rather than searching for your specific game by name, produces dramatically more first exposure than releasing quietly on an arbitrary date. Events like Steam Next Fest exist specifically for this purpose, and building a demo on a timeline that lets it hit one of these windows, even if that means delaying the demo by a few weeks, is usually worth the wait.