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.
52 lines
3.1 KiB
Markdown
52 lines
3.1 KiB
Markdown
---
|
|
name: game-designer
|
|
description: >
|
|
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.
|
|
whenToUse: 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
|
|
|
|
1. **Fantasy** — "You are ___ who ___." One sentence.
|
|
2. **First 30 seconds**, as three feelings in order: curiosity → control → threat.
|
|
3. **Core loop** — verb → obstacle → reward → escalation. One sentence; if it needs two, it is two games.
|
|
4. **The repeated decision** — what the player weighs dozens of times, and what makes it hard. No decision means a toy, not a game.
|
|
5. **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.
|