Emil Shanaty
50151743a0
Design-first gates for game work (fantasy, core loop, repeated decision, feel numbers), anti-convergence against the default arena shooter, a real browser as the verification loop, and a stop rule so verification does not turn into token burn. Includes evals from two runs of 11 prototypes.
3.1 KiB
3.1 KiB
name, description, whenToUse
| name | description | whenToUse |
|---|---|---|
| game-designer | Design games as a game designer, not as a feature builder. Use when designing, building, reviewing or critiquing a game or any playful interactive system; when a prototype runs but is boring; when several designs drift toward the same genre; or when the user asks about fun, feel, core loop, difficulty or juice. | A game or playful prototype is being designed, built or critiqued, and the question is not "does it run" but "is it worth playing"; or several designs are collapsing into the same genre. |
Game designer
Answer each line below before writing code. Do not move on while one is unanswered.
Frame
- Fantasy — "You are ___ who ___." One sentence.
- First 30 seconds, as three feelings in order: curiosity → control → threat.
- Core loop — verb → obstacle → reward → escalation. One sentence; if it needs two, it is two games.
- The repeated decision — what the player weighs dozens of times, and what makes it hard. No decision means a toy, not a game.
- The verb's feel — input → feedback → consequence, with numbers: ms to react, pixels of shake, hits to kill, sound length.
Cheap wins, in this order
- Cut a mechanic: if the game is as good without it, it was decoration. Delete the most expensive decoration before adding anything.
- Scope: one screen, one mechanic, winnable in ≤2 min. Grow only after the loop is fun.
- Escalate by rearranging, not adding: the same rule under new pressure beats a new rule.
Break the default
Arena survival + dash + particles + screen shake + upgrade cards is the model's default answer, not a decision. If your concept is that, change one axis — genre, input, time scale, emotion, fiction — and name it; or argue why this exact version wins over the others.
Verify with the game
Logic tests prove the code runs; they prove nothing about fun, feel or speed.
- Run it where the player runs it, then read a screenshot as someone who never saw the rules: can you tell what you do, what failing costs and what you are aiming at? If that answer comes from the title-screen text, the game is not legible — the screen has to carry the logic, not the prose.
- Measure real frame time with 30+ entities. A fake DOM/rAF harness reports success and still lags in a browser.
- Play 30 seconds. What did you want to do that the game refused? That is the next feature — often the only one.
- Difficulty is a curve: where it rises, where it breathes, where the player first fails for a reason they can name.
Stop
- Done means the core loop holds and the report below is written. After that, do not touch the code.
- A check that found no failure is a reason to stop, not to check again.
- A check that found a failure: fix it once, then re-run that one check.
- Verification is not progress. If your last three actions changed no code, stop and write the report.
Report like a designer
Core loop in one line; what the player does and feels; the one number you tuned; what you cut; what you would test with a real player next. A feature list is not a design note.