designing-one-button-games
Designing One-Button Mini-Games
A library-agnostic guide for designing one-button mini-games. The aim is an intuitive, visually self-explanatory game that rewards skilled play and contains at least one mechanic the player has never seen before.
When to Use
- Invent a new one-button game from a theme, prompt, or set of inspiration tags.
- Audit an existing one-button design for monotonous-input dominance, unfair death, or lack of novelty.
- Decide between competing mechanic ideas before implementation.
This skill covers design only. Implementation details (rendering, collision, audio) belong to engine-specific skills such as developing-with-crisp-game-lib or the target engine's implementation skill.
Design deliverables should still name implementation-facing invariants when balance depends on them. An invariant is a testable rule the later implementation must preserve, such as "repeated taps within 12 frames cannot create another scoring pulse." Do not write engine code here; write the rule that implementation must uphold.
At design time, keep constants qualitative unless the balance claim depends on a threshold. It is acceptable to write "minimum-age bloom" or "short cooldown" here, then defer choosing frame counts to the implementation pass, derived from the intended action cycle. If a deterministic seed or generator does not exist yet, state the seed/precheck invariant now and mark the actual first-case check as an implementation-time validation item.