Game Dev · July 6, 2026
Achievement and Trophy Design in Shmups: Encouraging Mastery Without Padding
An achievement list built by listing every stage clear and every enemy type killed is not a design decision, it is a checklist generated from existing content. The better lists start from a different question.
Published July 6, 2026
The easiest way to build an achievement list is to enumerate existing content — one achievement per stage cleared, one per boss defeated, one per enemy type killed a hundred times. This produces a long list with almost no design value: it rewards playing the game, which players were already going to do, rather than encouraging any specific behavior or recognizing any particular skill. A more useful achievement list starts from a different question: what are the specific moments of mastery this game is actually trying to teach, and how can an achievement recognize a player who reached one of them?
Tie achievements to the skills your systems actually reward
If your game has a graze system, as covered in the graze system in shmups, an achievement for accumulating a meaningful graze count in a single stage recognizes a player who understood and engaged with that system deliberately, which is a much stronger signal than an achievement for simply finishing the stage. The same logic applies to scoring systems: an achievement tied to a specific combo length or extend threshold, discussed in scoring systems in shmups, teaches players that the scoring loop rewards sustained engagement rather than sporadic hits, and gives them a concrete target to aim for the second time through a stage.
Avoid achievements that punish exploration or experimentation
An achievement for "complete the game without using a continue" is common and generally fine, since it recognizes skill directly. An achievement for "complete the game without dying once" in a genre built around learning patterns through failure sends a different, worse message: it implicitly frames death as something to be ashamed of in a genre where death is the primary teaching mechanism. Achievements that discourage the exact behavior — trying a risky route, testing whether a pattern can be grazed instead of dodged — that produces the most interesting play sessions work against the game's own design rather than for it.
Hidden versus visible achievements
Hiding an achievement's description until it is unlocked works well for achievements that would spoil a surprise if revealed in advance — a secret boss, an unexpected ending branch. It works poorly for skill-based achievements, since a player cannot aim for a target they cannot see. A reasonable default is visible descriptions for anything skill- or mastery-related, so players can treat the achievement list as an informal list of challenges to pursue, and hidden entries reserved specifically for content-discovery surprises where the surprise itself is the point.
Scope achievements to what telemetry can actually verify
If you are already collecting the kind of gameplay telemetry discussed in telemetry and analytics for indie games, the same event data that feeds a death heatmap can drive achievement conditions directly, which keeps achievement logic consistent with how the rest of the game reasons about player behavior rather than maintaining a separate, parallel tracking system just for unlocks. This also makes it easier to spot achievements that almost nobody unlocks after release, which is a strong signal that either the achievement's threshold is miscalibrated or the underlying skill it is trying to recognize is not being taught clearly enough elsewhere in the game. Platform documentation such as the Steamworks achievements guide covers the technical integration; the harder part is always the design question of what is worth recognizing in the first place, not the API calls needed to unlock it.
How many achievements is too many
A list of eighty achievements feels generous on a store page and feels exhausting five minutes into actually playing the game, especially once a third of them are trivial completion markers diluting the ones that took real thought to design. A tighter list of fifteen to twenty-five, each one recognizing something a designer can articulate in a single sentence without falling back on "player did the thing," tends to age better and gets referenced more in community discussion than a bloated list nobody bothers to read past the first page. If a design instinct produces a long list quickly, that is usually a sign the list is leaning on enumeration rather than on genuine design intent, and it is worth cutting back before shipping rather than after players start commenting on the padding.
Post-release calibration is part of the job
Achievement completion rates published by platforms after launch are a direct, honest signal about calibration, and they are worth reviewing a few weeks after release rather than treated as a one-time design decision locked in before launch. An achievement with a near-zero completion rate across thousands of players is either miscommunicated, badly telegraphed, or tuned around a skill ceiling the difficulty curve never actually teaches players to reach. Adjusting a threshold post-release, or adding an in-game hint pointing toward an under-discovered system, costs little and often measurably improves how the achievement list functions as a guide to what the game values.