Game Design Design Pillars Extractor#

Extract the real pillars a design is built around, not the polite slogans attached to it.

Use this skill when a team has a pile of mechanics, references, and ambitions but no sharp articulation of what the design actually prioritizes. The goal is to reverse-engineer 3 to 5 actionable pillars from the game's systems, loops, and tradeoffs.

Good pillars are directional. They help decide what to keep, what to cut, and what kinds of changes are off-brand. Bad pillars are just nice words wearing capital letters.

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#

A meaningful design pillar does two things:

• names what the design is trying hard to deliver
• implies what the design is willing to sacrifice to deliver it

If a pillar does not create a constraint, it is not a pillar yet.

What to produce#

Generate:

1. Extracted pillars - 3 to 5 clear, testable pillars
2. Support map - which systems actually reinforce each pillar
3. Conflict map - where systems or candidate pillars push against each other
4. Missing or weak dimensions - important priorities that are undefined, accidental, or under-supported
5. Decision guidance - which pillars should dominate future choices

Process#

1. Define the extraction target#

Clarify:

• what exact game, feature set, or loop is being analyzed
• whether the pillars are for the whole product or a subset
• whether you are extracting current pillars or intended pillars

Write:

• Extraction target
• Scope
• Current versus intended state

2. Map the dominant design behaviors#

Look at:

• core loop
• repeat decisions
• reward structure
• punishment structure
• progression model
• randomness profile
• pacing
• agency level
• social or solo emphasis

Ask:

• What does the design repeatedly encourage the player to do?
• What kinds of decisions matter most?
• What behaviors are rewarded, tolerated, or ignored?

3. Infer the implicit priorities#

Ask:

• What is this design optimizing for in practice?
• What is it willing to make harder, slower, riskier, narrower, or less accessible in order to preserve that?
• Which experiences seem central rather than incidental?

This is where you move from feature description to design intention.

4. Detect tradeoffs and contradictions#

Look for places where:

• one system rewards patience while another rewards speed
• one feature pushes mastery while another floods the loop with noise
• one layer promises freedom while another funnels players into one dominant path
• a supposed pillar is not actually reinforced by gameplay

Do not hide contradictions. Surface them.

5. Synthesize 3 to 5 pillars#

For each pillar, provide:

• Name
• What it means
• What it prioritizes
• What it sacrifices
• Which systems support it

Prefer short, sharp names that imply a stance, such as:

• Controlled Chaos
• Readable Mastery
• High-Risk Commitment
• Expressive Preparation
• Ruthless Momentum

Avoid vague filler such as:

• Fun
• Immersion
• Engagement
• Quality
• Innovation

6. Identify missing or weak pillars#

Ask:

• Which important experience dimensions are currently accidental or under-defined?
• Which design goals are talked about but not structurally supported?
• Which player promises are present in language but absent in systems?

7. Turn the pillars into decision guidance#

State:

• which pillar should win when tradeoffs appear
• which features do not support any pillar and should be challenged
• which future ideas fit or violate the extracted set

Response structure#

Use this structure unless the user asks for something else:

Extraction Target#

• ...

Extracted Design Pillars#

1. ...
2. ...
3. ...

For each pillar:

• Meaning: ...
• Prioritizes: ...
• Sacrifices: ...
• Supporting systems: ...

Conflicts and Contradictions#

• ...

Missing or Weak Pillars#

• ...

Decision Guidance#

1. ...
2. ...
3. ...

Fast mode#

Use this quick pass when speed matters:

• What does the design reward most consistently?
• What is it clearly willing to sacrifice?
• What three priorities best describe the actual game?
• Which feature does not belong?

Usage notes#

This extractor is especially useful for:

• early concept framing
• preproduction alignment
• pitch cleanup
• feature triage
• post-prototype coherence checks
• making design docs less hand-wavy

Common patterns to watch for:

• teams often confuse feature lists with pillars
• a pillar that cannot say "no" is not doing any work
• contradictory pillars usually reflect unresolved design conflict, not healthy nuance
• the strongest pillar should be obvious in repeated gameplay, not just in slide decks
• if every pillar sounds universally positive, they are probably too generic to guide decisions

Working principle#

Mechanics reveal priorities even when the team does not.

Use this skill to extract the principles the design is actually living by, then decide whether those principles are worth keeping.