Design or audit compact games for any input scheme. This skill owns rules, controls, scoring, hazards, difficulty intent, and engine-neutral invariants—not rendering, collision code, audio implementation, or numeric tuning.
Keep constants qualitative unless a balance claim requires a threshold. Defer frame counts to implementation from the intended action cycle. When deterministic generation does not exist yet, specify the seed/precheck invariant and mark the first-case check for implementation-time validation.
Core Rules
- Express the core experience in one sentence. Fix button count and the role of each phase/button before secondary systems; respect a brief's count and record the physical binding for every action so screens cannot invent conflicting keys.
- Game-over is single, visually obvious, and follows from a hazard or world-state collapse — never from a "did not press" punishment.
- Make every available monotonous policy strictly worse than skilled play: idle and mashing always; hold-only for one-button; single-button spam and hold-everything for multi-button.
- Score in-world causes (precision, graze, chain, route, pressure cash-out), never raw input facts. Keep survival score only when survival is the mastery signal and name the skilled pattern that separates it from monotony.
- Add state only for a new player decision. Each important variable needs a trigger, in-world feedback (never only a HUD number), and a decision purpose; otherwise remove it. Zero-state designs are valid when geometry/physics alone creates decisions—say why.
- Pair safety/power inputs with a readable cost such as lost score, drain, exposure, hitbox, speed, pressure, or recovery.
- Name which quantities scale and why. Default smooth motion/spawn pressure to
sqrt(difficulty); use steeper scaling only for intentional escalation. - For every balance-critical monotony claim, give at least one testable, engine-neutral implementation invariant.
One-button-specific rules:
- One binary input only: press, hold, release—no second key, chord, or swipe.
- Explicitly justify unused phases; never add a meaningless action to fill a table.
Design Procedure
- Associate: state the first images/sensations. For contradictory seeds (for example,
on_pressed:jumppluson_pressed:shoot), read the reference guide §7 and treat the contradiction as tension; do not discard one side. - Deviate: record the first obvious mechanic, forbid it, and explore an opposite, negation, or extreme.
- Commit: state the momentary core experience, then fix button count, bindings, and phase/button roles.
- Harden: define decision-making state, triggers, in-world feedback, and safe/risky tradeoffs.
- Reject monotony: explain why every applicable monotonous policy loses and why remaining inputs still create skill when a phase is unused.
- Specify economy: define causal score events and justified difficulty scaling.
- Sketch invariants: state the implementation rule behind each risky claim; expand pulses, shields, charge, combos, and repeated score windows with
implementing-gameplay-invariants. - Verify: run reference guide §9. If implementation exposed an emergent behavior, document it and explicitly preserve it as a design revision or reject it.
Treat seeds as stimulus for steps 1–2. From step 3 onward, do not be bound by them. A finished design that no longer references the original tags is fine.
For a new design, deliver: name/slug, seeds, core mechanics, state/tradeoff, object specifications, design-principle analysis, novelty basis, similarity check, causal scoring, difficulty intent, controls/bindings, and implementation invariants. Use reference Appendix A as a layout example.
References
references/mini-game-design-guide.md— detailed principles, input/movement tables, contradiction handling, checks, output format, and SCAMPER prompts.implementing-gameplay-invariants— translate risky balance claims into code-level checks.maximizing-game-feel— use after rules/balance stabilize or when polish affects play.