systems-design

What this skill does

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

---

## When to Activate

Use this skill when:
- Designing the system architecture of a new game
- Adding a new system to an existing game and need to evaluate fit
- A game has many features but feels shallow — "lots to do, nothing matters"
- Evaluating whether systems are producing emergent depth or just mechanical complexity
- Deciding which systems to build, cut, or defer
- Diagnosing dominant strategies that collapse possibility space
- Planning system build order for a prototype or MVP
- Reviewing whether a game's systems serve its experience pillars

---

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