Install
openclaw skills install game-design-fantasy-extractorExtract 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.
openclaw skills install game-design-fantasy-extractorExtract 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.
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:
If the fantasy could describe fifty unrelated games, it is too weak to guide design.
Generate:
Clarify:
Write:
Look at:
Ask:
Ask:
State the strongest emotional promise in plain language.
Check whether the fantasy is genuinely systemic or mostly cosmetic.
Examples:
Ask:
Many designs carry secondary fantasies. That is fine until they collide.
Look for:
Name the strongest secondary fantasies and whether they strengthen or muddy the main one.
For each major system, ask:
Use this format:
| System or loop element | Supports fantasy? | Why |
|---|---|---|
| ... | Strongly / Partly / Weakly / No | ... |
Prefer a compact form such as:
Good examples are concrete and emotionally legible. Bad examples sound like box-copy mush.
For each important fantasy claim, specify:
Examples:
Use this structure unless the user asks for something else:
Use this quick pass when speed matters:
This extractor is especially useful for:
Common patterns to watch for:
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.