---
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.