Systemic Game Design, Part 4: What Makes a System Good?

Main ideas / lessons conveyed

1. A “good” system feels good to interact with

   • Player-facing quality issues that break immersion or usability can include:
     • Bad jump controls (frustration)
     • Corny cinematic effects from bad voice acting
   • A systemic game falls flat if its underlying systems aren’t engaging.

2. Reliable randomness (neither too predictable nor too chaotic)

   • The “sweet spot” balances:
     • Calculable simulation (players can reason about outcomes)
     • Unexpected emergence (outcomes can still surprise)
   • Pure randomness can frustrate players because they can’t make informed decisions.
   • Better randomness includes meaningful probability structure that rewards inference.

#### Detailed illustration: dice probabilities

  - **1 die (6-sided)**
      - Unpredictable, with only **6 possible outcomes**
      - Each side is **equally likely**, with a **small possibility space**
      - Result: randomness can become **uninteresting** because there’s **no probability shape** to learn.

  - **2 dice (6-sided each)**
      - Expands range to **11 possible totals** (2–12)
      - Outcomes form a **curved distribution**:
          - **Middle values** are much more likely (up to **~6x** more likely than extremes)
          - The **5 middle totals** together have about a **2/3 chance**
          - Outer totals are collectively about **1/3 chance**
      - Result: players can make **more informed decisions** because probabilities are learnable.

  - **3 dice (process-based structure)**
      - Roll **one die first**, then predict knowing the **final step** will roll two more dice
      - Use the **highest two** values from the final two dice
      - Result: randomness becomes even more information-rich; players have **prior knowledge** before the final outcome.

1. Smart use of loops: positive and negative feedback
   • Loops come in two forms:

#### Positive feedback loops

  - **Definition:** Running the system makes it easier to run again.
  - Commodity example:
      - System needs **1 unit of X** to run
      - Produces **2 units of X**
      - Running it again becomes progressively easier because you **net more X**.
  - RPG example:
      - Party can participate in **one combat** before needing healing
      - After combat, they gain a **level**, increasing stats
      - That lets them participate in **two combats** before healing.
  - Design implication:
      - Positive loops create a sense of **progress**
      - Must be tuned carefully to avoid **too-fast growth**

#### Negative feedback loops

  - **Definition:** Running the system reduces your ability to run it again.
  - Commodity example:
      - If the system takes **1X** and gives **1Y**, you have a **net loss of X**
      - Less X remains to run it again.
  - RPG example:
      - Battles reduce **hit points**
      - Players spend **magic/skill points**
      - Therefore they can’t fight again until **healing/restocking**.

1. Use both loop types together to create durable “engines”

   • A good system often intentionally mixes:

     • Short-term losses (negative feedback)
     • To enable larger long-term gains (positive feedback)

   • Multi-step XY loop concept

     • System A: spends X and gains Y
     • System B: uses Y (or produces more inputs) to generate more X than started
     • Net effect restores and grows the positive feedback loop over multiple stages.

   • Expansion ideas

     • Add more commodities/upgrades for more efficient systems
     • Create loops that take fewer steps

   • Board game connection

     • This strategy is often called engine building—finding the most efficient loop combinations for the best gameplay.

2. Adjective/noun philosophy for systemic item design (modularity)

   • Key principle: Objects shouldn’t be defined only by their names.
   • Instead:
     • Their traits (adjectives)
     • And very simple categories (nouns) should define behavior and interactions.

#### Example

  - “Store that deals damage when attack is pressed” is functional but **not systemic**.
  - If there’s a “spear” doing similar damage, the difference should come from traits, e.g.:
      - Both are **weapons** (noun/type)
      - Both are **melee**
      - Spear can be **thrown**
      - Sword is **bladed** and **one-handed**
      - Spear is **pointed** and **two-handed**

#### Why this helps

  - Creates a **vocabulary** of reusable traits across items
  - Enables **mix-and-match modularity**, making more systems interconnected
  - Supports **emergent relationships** rather than hard-coded behavior

#### Practical benefit

  - Reduces work by avoiding bespoke trait coding for each object

1. Not every game needs systems, but some games particularly benefit from them
   • Systems can be added to many games (similar to how RPG-style leveling spread to other genres).
   • Some games embrace systems and make them a standout feature (teased for a later video).

---

Methodologies / instruction-style takeaway (organized bullets)

How to make randomness in systems “good”

• Aim for the sweet spot:
  • Outcomes should be somewhat predictable via simulation (players can reason)
  • Yet still allow unexpected emergence
• Avoid pure uniform randomness where all outcomes are equally likely and learnable strategy is minimal.
• Shape randomness with structured probability so players can infer likely ranges:
  • Use multiple components (e.g., dice totals) to create curved distributions where middle outcomes are more common than extremes.
• Make randomness responsive and information-rich:
  • Allow earlier rolls/knowledge to update what players expect before final outcomes.
  • Ensure players gain enough behavioral information to form intelligent strategies.

How to design loop-driven progression

• Implement positive feedback loops where running the system increases resources/conditions needed to run it again.
• Implement negative feedback loops where running the system consumes limited resources or reduces future capability.
• Use both together:
  • Accept short-term drawbacks (negative feedback) to enable long-term growth (positive feedback).
• Chain systems with commodity/XY-style loops:
  • System A converts X→Y
  • System B converts accumulated Y into more-than-starting X
  • This preserves and expands positive feedback across steps.
• If doing board-game-like design, target engine building:
  • Find loop combinations that maximize efficiency and gameplay value.

How to build systemic content (traits-first design)

• Define items using:
  • Simple nouns (broad categories/types like “weapon”)
  • Adjectives (traits like “one-handed,” “two-handed,” “bladed,” “pointed,” “throwable”)
• Ensure behavior and interactions come from traits, not only from object names.
• Differentiate similar items via trait combinations so they:
  • Become meaningfully distinct
  • Interact with other systems modularly
• Prefer modular traits over hard-coded relationships per object to:
  • Increase interconnectedness
  • Enable emergent outcomes
  • Reduce design workload

---

Speakers / sources featured

• The video creator/narrator (no name provided in the subtitles)
• Patreon supporters (credited via “brought to you by our amazing supporters over at Patreon”)