| name | game-design-fantasy-extractor |
| description | Extract the core player fantasy from a game, feature, loop, or pitch based on what the design actually lets the player do, feel, and become. Use when a team can describe mechanics but cannot clearly articulate the fantasy those mechanics are supposed to deliver, when a concept feels emotionally vague, when a pitch names features instead of a player promise, or when you need to test whether the claimed fantasy is real, weak, conflicted, or absent. |
Game Design Fantasy Extractor
Extract the fantasy the design is actually trying to deliver, not just the genre wrapper or marketing line sitting on top of it.
Use this skill when a team can explain systems, verbs, and content, but cannot cleanly state what the player is meant to feel like, become, or emotionally inhabit. The goal is to infer the core player fantasy from the design itself, test whether the systems support it, and expose where the fantasy is generic, split, or fake.
Read references/family-conventions.md when you want the shared style, prioritization, and diagnosis rules for this game-design skill family.
Read references/output-patterns.md when you want the preferred recommendation and minimal-fix structure.
Core principle
Players do not attach to mechanics in the abstract. They attach to what those mechanics let them be.
A useful fantasy statement does three things:
- names who the player becomes
- implies what emotional payoff they are chasing
- is supported by repeated gameplay, not just theme dressing
If the fantasy could describe fifty unrelated games, it is too weak to guide design.
What to produce
Generate:
- Core fantasy - the strongest player-facing fantasy implied by the design
- Supporting fantasy layers - secondary fantasies or emotional promises present in the design
- Fantasy support map - which systems reinforce the fantasy and which fail to do so
- Fantasy conflicts - where systems, pacing, or progression undermine the claimed fantasy
- Design implications - what must be strengthened, clarified, cut, or re-framed
Process
1. Define the extraction target
Clarify:
- what exact game, feature, loop, or pitch is being analyzed
- whether the fantasy is for the whole product or one experience slice
- whether you are extracting the current fantasy or pressure-testing a claimed one
Write:
- Extraction target
- Scope
- Claimed fantasy if any
2. Identify the player verbs and role
Look at:
- what the player repeatedly does
- what power they exercise
- what decisions they make
- what social or world position they occupy
- what consequences they create
Ask:
- What role is the player actually inhabiting?
- What kind of agency does the design grant?
- Is the player expressing mastery, care, domination, discovery, survival, performance, stewardship, rebellion, creation, or something else?
3. Infer the emotional promise
Ask:
- What is the player supposed to feel at their best moments?
- What fantasy payoff keeps the loop emotionally coherent?
- Does the design promise competence, cleverness, power, danger, intimacy, authorship, belonging, control, chaos, or transformation?
State the strongest emotional promise in plain language.
4. Separate fantasy from theme skin
Check whether the fantasy is genuinely systemic or mostly cosmetic.
Examples:
- a game dressed as leadership but functionally about spreadsheet optimization
- a game themed as outlaw chaos but structurally punishing improvisation
- a game marketed as freedom while funneling players into narrow routes
Ask:
- If the art and fiction layer were stripped away, would the same fantasy still be legible through play?
- Is the fantasy delivered by action, or merely narrated at the player?
5. Identify supporting and competing fantasies
Many designs carry secondary fantasies. That is fine until they collide.
Look for:
- power fantasy versus vulnerability fantasy
- mastery fantasy versus cozy ritual fantasy
- freedom fantasy versus authored narrative control
- social belonging fantasy versus individual dominance fantasy
Name the strongest secondary fantasies and whether they strengthen or muddy the main one.
6. Map support and contradiction
For each major system, ask:
- does it reinforce the fantasy
- distract from it
- undermine it
- replace it with a different fantasy
Use this format:
| System or loop element | Supports fantasy? | Why |
|---|
| ... | Strongly / Partly / Weakly / No | ... |
7. Write the extracted fantasy sharply
Prefer a compact form such as:
- You are ...
- You get to feel like ...
- This is a game about becoming ...
Good examples are concrete and emotionally legible.
Bad examples sound like box-copy mush.
8. Convert the fantasy into design implications
For each important fantasy claim, specify:
- Fantasy promise
- What the design must deliver repeatedly
- What the design should avoid because it breaks the fantasy
Examples:
- outlaw improvisation -> systems must reward bold opportunism, not only rigid planning
- city stewardship -> player actions must visibly improve or shape the world
- predator mastery -> encounters must showcase dominance, not constant attrition panic
Response structure
Use this structure unless the user asks for something else:
Extraction Target
Core Fantasy
Supporting Fantasy Layers
Fantasy Support Map
Fantasy Conflicts
Design Implications
- ...
- ...
- ...
Minimal Reframe or Fix
Fast mode
Use this quick pass when speed matters:
- What does the player actually get to be here?
- What feeling is the design promising at its best?
- Which system most strongly supports that fantasy?
- Which system most obviously betrays it?
- What one change would make the fantasy clearer?
Usage notes
This extractor is especially useful for:
- early concept framing
- pitch cleanup
- fantasy-first ideation
- checking whether mechanics match emotional promise
- identifying why a concept feels flat despite competent systems
- aligning narrative, art, and design around one player promise
Common patterns to watch for:
- teams often describe setting instead of fantasy
- many designs claim freedom while structurally delivering obedience
- multiple fantasies can coexist, but only if they are hierarchized
- a fantasy without systemic support is just expensive decoration
- if the player role is vague, the fantasy probably is too
Working principle
A design is not just a set of mechanics. It is an answer to the question, "what do I get to become while playing this?"
Use this skill to make that answer explicit and test whether the game earns it.
