systems-design

name

systems-design

description

Structural architecture of game systems: the interaction matrix, coupling analysis, emergence, possibility space, cursed problems, and build order. Use when choosing which systems a game needs, evaluating whether to add or cut one, planning build sequence, or when a game has many features and still feels shallow — 'there's a lot to do but it all feels the same'. Also for diagnosing dominant strategies that collapse the possibility space, and for naming a design tension that cannot be engineered away. This is the between-systems altitude: for one mechanic's quality use game-design, for whether a mechanic affects outcomes at all use mechanic-ablation.

Systems Design

Purpose: Tools for designing, evaluating, and diagnosing the structural architecture of game systems — how they interact, what they produce together, and why depth comes from interaction rather than accumulation.

Core philosophy: Games are not built from features. They are built from interacting systems. Depth comes from how systems interact, not how complex they are alone. A game with four tightly interacting systems is deeper than a game with twelve isolated ones.

Sources: Cursed Problems is Alex Jaffe, "Cursed Problems in Game Design" (GDC 2019) — the term, the framing, and the resolution rule are his. Systems-over-features thinking follows Doug Church, "Formal Abstract Design Tools" (1999) and Will Wright's writing on simulation-driven design. Possibility space follows Jesse Schell, The Art of Game Design (3rd ed., 2019). The interaction matrix and its health indicators are this plugin's own construction — no external source; treat the thresholds as working values.

---

Core Framework: The System Interaction Matrix

The interaction matrix is the primary diagnostic tool. It maps every game system against every other system and classifies the interaction.

Interaction Types

Type	Symbol	Definition	Example
Feeds	→	A generates input for B	Combat → Loot (kills produce drops)
Constrains	⊣	A limits B's option space	Stamina ⊣ Combat (fatigue restricts combos)
Enables	⊕	A creates conditions for B to function	Exploration ⊕ Crafting (discovery unlocks recipes)
Conflicts	⊗	A and B compete for the same resource or player attention	Building ⊗ Combat (same time budget)
Emergent	✦	Interaction produces behaviors neither system creates alone	Stealth ✦ AI (guards create patrol puzzles)
Independent	·	No meaningful interaction	Weather · Inventory

Template

Build this matrix early. Update it as systems evolve.

             | Combat | Craft | Explore | Stealth | Economy |
-------------|--------|-------|---------|---------|---------|
Combat       |   —    |       |         |         |         |
Craft        |        |   —   |         |         |         |
Explore      |        |       |    —    |         |         |
Stealth      |        |       |         |    —    |         |
Economy      |        |       |         |         |    —    |

Worked Example: Action-Survival Game

             | Combat | Craft  | Explore | Stealth | Economy |
-------------|--------|--------|---------|---------|---------|
Combat       |   —    | →Feed  | ⊗Attn   | ✦Emrg   | →Feed   |
Craft        | ⊕Enabl |   —    | ⊕Enabl  | ⊕Enabl  | ⊣Constr |
Explore      | →Feed  | →Feed  |    —    | ⊕Enabl  | →Feed   |
Stealth      | ✦Emrg  | ·Indep | →Feed   |    —    | ·Indep  |
Economy      | ⊣Constr| →Feed  | ⊕Enabl  | ·Indep  |    —    |

Reading the matrix:

• Row = source system, Column = target system
• Combat → Craft (Feed): combat produces materials for crafting
• Stealth ✦ Combat (Emergent): combining stealth with combat creates ambush tactics neither system produces alone
• Stealth · Economy (Independent): no meaningful connection — potential missed opportunity or acceptable isolation

Matrix Health Indicators

• Any row or column that is all · (Independent): Vestigial system. Cut it or connect it.
• Many ✦ (Emergent) cells: Strong sign of depth. Protect these interactions.
• No ⊣ (Constrains) cells: Systems may lack tension. Players can engage everything without trade-offs.
• Dense ⊗ (Conflicts) cells: Players may feel pulled in too many directions. Reduce competing demands.

---

System Selection

Not every game needs every possible system. Start from intent, not from a feature list.

Derivation Method

1. Start from experience pillars (from game-vision) — what does this game want players to feel?
2. Derive core loop verbs — what does the player do repeatedly?
3. Identify required systems — which systems do those verbs demand?
4. Add supporting systems — only if they strengthen the core loop
5. Stop — resist the urge to add more

The Three-Gate Filter

Before adding any system, it must pass all three gates:

Gate	Question	If "No"
Pillar	Does this system serve an experience pillar?	Cut it — no pillar means no purpose
Decision	Does it create meaningful player decisions?	Redesign it — systems without decisions are content, not systems
Interaction	Does it interact with at least 2 other systems?	Defer it — isolated systems add complexity without depth

A system that fails any gate is a candidate for cutting or deferral, not implementation.

---

Coupling Analysis

How tightly systems depend on each other determines the architecture's flexibility and depth.

Coupling Spectrum

Level	Description	Example	Properties
Tight	Systems are inseparable; changing one requires changing the other	Combat ↔ Health	High cohesion, brittle if poorly designed, essential for core loop
Loose	Systems enrich each other but function independently	Trading ↔ Exploration	Flexible, composable, good for supporting systems
None	No interaction whatsoever	Weather ↔ Inventory (if weather has no gameplay effect)	Waste — the system exists but contributes nothing to the whole

Coupling Guidelines

• Core loop systems should be tightly coupled. The actions at the heart of your game must be inseparable. If you can remove one without affecting the others, it's not truly core.
• Supporting systems should be loosely coupled. They add depth and variety, but the game must function (at reduced quality) without them.
• No system should be completely uncoupled. An isolated system is dead weight. If it doesn't interact with anything, it's consuming development budget and player attention for zero depth.
• No system should couple to everything. A system that touches every other system is a god-system — brittle, hard to tune, impossible to test in isolation. If you find one, decompose it.

Coupling Diagnostic

• Every core loop system is tightly coupled to at least one other core system
• Supporting systems have 2-3 loose couplings, not 0 or 7+
• No system is completely isolated
• No single system is coupled to more than 60% of all other systems
• Removing any supporting system degrades but doesn't break the core loop

---

Emergence Analysis

Emergence is when interacting systems produce behaviors that no individual system was designed to create. It is the source of depth, replayability, and "I can't believe that worked" moments.

Emergence Categories

Category	Description	Response
Beneficial	Player creativity, unexpected strategies, emergent narratives	Protect. Do not patch out. Highlight in tutorials or community.
Neutral	Surprising but harmless behaviors	Monitor. May become beneficial or degenerate over time.
Degenerate	Exploits, content trivialization, infinite loops, economy breaks	Fix. But understand the root interaction before patching — a naive fix often creates new degenerate emergence.

Predicting Emergence

You cannot predict all emergent behaviors. The combinatorial space of system interactions grows factorially. But you can be systematic about the ones you check:

Step 1: Two-system interactions. For each pair of systems, ask: "What happens when a player uses A and B together in ways I didn't explicitly design?" Trace the most obvious combinations.

Step 2: Three-system chains. For each triple, trace: "If A feeds B and B enables C, what does A indirectly produce in C?" Three-system chains are where most non-obvious emergence lives.

Step 3: Accept the unknown. Beyond three systems, the combinatorial explosion means you will encounter emergence in playtesting that you did not predict. This is not a failure — it is the nature of systems.

Designing for Graceful Emergence

Since you can't predict everything, design systems that handle unexpected interactions gracefully:

• Cap extreme outputs. If any value can grow unbounded through system interactions, cap it.
• Preserve invariants. Define rules that must never be violated (e.g., "health never exceeds max," "economy never goes negative") and enforce them at the system boundary, not inside individual systems.
• Playtest early with system combinations. Don't test systems in isolation and then combine them. Combine them immediately and let emergence reveal itself while you can still adjust.

---

Possibility Space

The possibility space is the combinatorial space of all meaningful player choices across all systems.

Size vs. Meaning

A large possibility space creates replayability and unique sessions. But size alone is not enough — the space must be meaningfully large.

Property	Meaningfully Large	Merely Combinatorial
Player experience	Different choices produce qualitatively different play sessions	Different choices produce different numbers but the same experience
Strategy diversity	Multiple viable approaches coexist	One approach dominates regardless of choices
Replayability	"I want to try a different build"	"I already know what happens"
Observation	Watching two players reveals different styles	Watching two players reveals the same patterns with different stats

Measuring Possibility Space Quality

The clearest signal that your possibility space is working: predictable player archetypes emerge from behavioral diversity.

When systems interact well, players self-sort into recognizable play styles (builder, fighter, explorer, optimizer) — but within each archetype, individual sessions differ. This is a measurable quality signal:

• If no archetypes emerge: systems aren't interacting enough to create distinct strategies
• If archetypes emerge but sessions within an archetype are identical: the possibility space is wide but shallow
• If archetypes emerge AND sessions within them differ: the possibility space is working

Expanding Possibility Space

The fastest way to expand meaningful possibility space is not to add more systems — it is to deepen interactions between existing ones. Each new interaction between existing systems multiplies the possibility space. Each new isolated system only adds to it.

---

Cursed Problems

Some design tensions are fundamental. They cannot be resolved through clever implementation — they require a choice at the vision level and acceptance of the trade-off cost.

Common Cursed Problems

Tension	Side A	Side B	Why It's Cursed
Physics vs. Controls	Realistic physics simulation	Responsive, predictable player controls	Realistic physics introduces latency and unpredictability that undermines player agency
Exploration vs. Narrative	Open-ended exploration	Tight narrative pacing	Free exploration breaks pacing; tight pacing restricts exploration
Customization vs. Balance	Deep player customization	Competitive balance	More build options = more edge cases = more balance failures
Complexity vs. Accessibility	Deep interacting systems	Low barrier to entry	Every system a new player must learn is a potential quit point
Emergence vs. Authorship	Emergent systemic outcomes	Hand-crafted narrative moments	Emergence disrupts scripted events; scripted events constrain emergence
Persistence vs. Freshness	Permanent player progress	Sessions that feel new and challenging	Accumulated power trivializes content that was once meaningful

Resolution Framework

1. Identify the tension — name both sides explicitly
2. Choose a side — one must be primary. "Both equally" is a non-decision that produces a mediocre compromise on both axes
3. Mitigate the sacrifice — once you've chosen, invest design effort in reducing the cost of the side you didn't pick
4. Document the decision — cursed problems resurface repeatedly during development. Without documentation, the team will relitigate the same trade-off in every feature discussion

Cursed problems resolved at the vision level stay resolved. Cursed problems deferred to implementation resurface as bugs, "feels wrong" feedback, and scope creep.

---

System Health Metrics

How to measure whether the system architecture is producing depth.

Telemetry-Based Metrics

Metric	What to Measure	Healthy Signal
Behavioral diversity	Session-to-session variance in player actions	Different players (and same player across sessions) take meaningfully different paths
Archetype formation	Cluster analysis on player behavior data	3-6 distinct play style clusters emerge naturally
System utilization	% of systems each player engages with per session	>70% of systems see meaningful engagement (not just incidental contact)
Depth gradient	Qualitative difference between novice and expert play	Expert play looks qualitatively different, not just faster or more efficient

Qualitative Metrics

Metric	Source	Healthy Signal
Session uniqueness	Playtest reports, community discussion	Players report "I didn't know that was possible" or "something unexpected happened"
Strategy sharing	Community forums, social media	Players share different approaches that all work
Vestigial detection	Playtest observation	No system is consistently ignored by players
Combo discovery	Playtest observation, analytics	Players find system combinations you didn't explicitly design

---

System Prioritization

What to build first when you can't build everything.

Build Order Principles

1. Core loop systems first, always. Nothing else matters if the 10-second loop isn't working. Every prototype session should exercise the core loop.

2. Progression is the most critical system for retention. A game with excellent core mechanics and no progression loses players. Progression converts "fun for 20 minutes" into "fun for 20 hours." Build it second.

3. Economy and AI behavior are foundational. Most other systems are downstream of resource flow and entity behavior. Get these right early — retrofitting them is expensive.

4. Social systems are force multipliers. In multiplayer or community-facing games, social systems (trading, cooperation, competition, communication) amplify every other system. But they require all other systems to function first.

5. Team size determines system count. The number of systems you can build to equal depth is proportional to your team. Solo and small teams must ruthlessly cut systems until every remaining system is excellent. A game with three polished, interacting systems is better than a game with eight half-built ones.

Prioritization Checklist

• Core loop systems identified and built first
• Each system in the build plan passes the Three-Gate Filter
• System count is appropriate for team size and timeline
• Interaction matrix shows sufficient coupling at each development milestone
• No system is planned that doesn't interact with a system already built or planned for the same milestone

---

The Systems Thinker's Diagnostic

When told "the game has lots of features but doesn't feel deep," run this diagnostic in order:

Step 1: Check System Interactions

Build or review the interaction matrix. Count the · (Independent) cells.

• If >40% of cells are Independent: Systems are parallel silos. Depth requires interaction. Add connections before adding systems.
• If most cells are → (Feeds) only: The architecture is linear (pipeline), not interconnected. Look for opportunities to add feedback loops, constraints, and emergent interactions.

Step 2: Check Possibility Space

Are system interactions producing meaningfully different outcomes?

• Test: Have 5 players play the same content. Do their sessions look different? Not just different numbers — different strategies, sequences, and stories.
• If sessions look the same: Interactions exist but don't create divergent outcomes. Deepen the interactions or add constrain/conflict relationships.

Step 3: Check for Dominant Strategies

If one path through the systems is always best, the possibility space collapses to a single point regardless of how large it theoretically is.

• Test: Is community consensus converging on "the best build"?
• If yes: See game-balance for dominant strategy detection and remediation.

Step 4: Check System Utilization

Are players engaging with all systems, or ignoring some?

• If systems are being ignored: They may be vestigial (not connected), underpowered (not rewarding), or too costly to engage with (attention budget exceeded).
• Each ignored system is complexity without depth. Cut it, connect it, or buff it.

Step 5: Check Depth Gradient

Does expert play look qualitatively different from novice play?

• If expert play is just "faster novice play": The systems don't have enough interaction depth to reward mastery. Add layers that only reveal themselves through system mastery.
• If expert play looks different: The architecture is working. Focus on other symptoms.

---

Anti-Patterns

All five failure modes this skill used to list separately — feature-first thinking, system isolation, complexity hoarding, the 15-system trap, and content-over-systems — are the same mistake seen from different angles: adding breadth where depth was needed. Listing them separately implied five diagnoses when there is one.

Symptom: players say "there's a lot to do but it all feels the same." Design discussions ask "what feature next?" rather than "what happens when these collide?" The design document lists twelve systems. The response to shallowness is more content.

Why it happens: breadth is legible and depth is not. A new system is a visible deliverable; deepening an interaction between two existing systems is invisible on a roadmap and produces a better game.

Fix: subtract a system. Invest the freed budget in interactions between the survivors. Repeat until every remaining system is excellent. Route every feature proposal through the interaction matrix and the Three-Gate Filter before it reaches a backlog.

The one genuinely distinct failure is the inverse, and it is rarer: over-coupling. A system that touches everything is a god-system — brittle, untunable, impossible to test in isolation. If one system appears in most cells of the matrix, decompose it.

Cross-References

Three tight links. Everything else routes through the map, so adding a skill touches one file rather than twenty: references/routing-map.md (in game-design).

• game-vision — Pillars first — systems are derived from them, not invented
• mechanic-ablation — Prove a system affects outcomes before defending it
• game-balance — Tune the numbers at system boundaries