Shmup Design · June 28, 2026

Leaderboards and High Score Tables in Indie Shmups: Design and Implementation

The high score table is the original retention loop. Before save states, before achievements, before social feeds, arcade shmups kept players coming back through the simple mechanism of a ranked list of scores visible to everyone who approached the cabinet. The underlying psychology has not changed. Implementing a score table well — local, online, or both — is one of the highest-return design investments in a skill-based shmup.

Published June 28, 2026

Score systems work because they give skilled play a permanent, visible record. Finishing a shmup is satisfying; finishing it with a higher score than your last run is satisfying and legible in a way that pure completion is not. The number encodes all the decisions the run contained: which enemies you grazed, how long you kept your combo multiplier running, how economically you used bombs. A high score is a compressed autobiography of a skilled run.

Local high score tables: the minimum viable leaderboard

A local high score table — typically ten entries, stored on disk, displayed at the title screen and game-over screen — is the simplest form and the one every shmup should have regardless of whether an online component is planned. The implementation is minimal: a sorted list of score structs (name, score, stage reached, date), serialized to a file on write, deserialized on load.

The storage format should be human-readable enough to survive version updates but not trivially editable for cheating. A signed JSON file or a simple binary format with a checksum serves both goals. The checksum does not need to be cryptographically strong for a local leaderboard — it just needs to catch accidental corruption and casual hex editing. A CRC32 over the score data is more than enough.

// Minimal score entry structure struct ScoreEntry: name: str # player initials, 3 chars score: int # final score value stage: int # stage reached before death ship: str # ship type if applicable timestamp: int # unix epoch checksum: u32 # CRC32 of above fields

Name entry remains a design question. Three-character initials are the arcade tradition and still feel right for a shmup with arcade roots. Full names or handles up to twelve characters feel more modern and are appropriate for a game with a social community component. Whichever you choose, the name entry UI should be fast and fun — a rotating character dial or a filtered keyboard where invalid characters are dimmed — because players will use it many times.

Scope filtering: per-ship and per-difficulty splits

A single global leaderboard for a shmup with multiple ships and difficulty levels produces scores that are not meaningfully comparable. A score on Novice difficulty cannot be ranked against a score on Lunatic. A score on the fastest, most powerful ship is not directly comparable to a score on the restricted starter ship.

The correct structure is separate leaderboards per configuration: one per ship type per difficulty. This produces more tables to display, but each table is internally coherent and motivates players to improve on the specific configuration they care about. The title screen should show the table for the last-used configuration by default, with navigation to switch. Players who are chasing a specific rank know immediately whether they have improved.

Online leaderboards: additional complexity, significant payoff

Online leaderboards multiply the motivational effect of a local table by exposing the player's score to a global community. Seeing that your personal best places 847th globally, and that the gap to 600th is achievable, is a more powerful pull than a local table alone. The infrastructure cost is non-trivial — you need a server, an API, authentication or at least a rate-limited submission endpoint, and anti-cheat measures — but third-party leaderboard services have reduced the hosting burden to near zero for small games.

Anti-cheat for an online shmup leaderboard has two layers. Server-side, impose sanity bounds: the highest possible score on a no-death clear of your hardest difficulty is a known quantity; submissions above it are automatically rejected. Implement rate limiting to prevent automated submission flooding. Client-side, attach replay data to submissions and validate a sample of them server-side by running the replay through a deterministic simulation. This is only possible if the game uses a fixed timestep and the simulation is fully deterministic, which is one of the strongest arguments for investing in that architecture early.

Replays: the leaderboard's most powerful feature

A score without context is a number. A score with an attached replay is a demonstration. The ability to watch how the top scorer navigated a stage, which patterns they memorized, which pickups they grabbed and ignored, transforms the leaderboard from a comparison metric into a teaching tool. Top players in competitive shmup communities spend significant time studying replays; making replays natively available and easy to share is a community feature with no equivalent.

A replay file is compact: it stores the initial RNG seed and the full input stream for the run, one input state per simulation tick. At 60 ticks per second for a 30-minute run that is 108,000 input states. At two bytes per state (one byte for button mask, one for analog axis) that is 216 KB uncompressed, smaller than a single texture. Compressed with a standard stream compressor it is closer to 20-40 KB depending on input variety. This is small enough to attach to every leaderboard submission without infrastructure concerns.

Displaying scores: the motivational moment

The moment a new personal best is displayed should feel like a reward. A score that does not beat the personal best still deserves a display that shows how close it came: the percentage gap, the stage where the run fell apart versus the personal best run. This information is actionable and it reframes a failed run as data rather than a simple loss. The player knows they need to survive Stage 3 longer; they have a concrete objective for the next attempt.

Rank display should show both global rank and local-table rank. Players who are not competing at the global level still care about their rank relative to the local table — beating a friend's score is a more immediate and personally meaningful target than a stranger's entry in the top 1000.