GDnD Wiki

GDnD Wiki

This site is for Ulster University students and staff. Enter the class access password to continue.

Systems Thinking

7 min read

Summary

Systems thinking is the cognitive discipline of understanding things by their relationships and interactions, rather than by analysing their parts in isolation. Sellers (Advanced Game Design, 2018) argues it is the single most important skill a game designer can develop, because games are systems — and designing systems without thinking systemically produces games that behave in surprising, often broken, ways.

The failure mode it diagnoses is reductionism: breaking a design down into parts and optimising each part individually, without modelling how the parts interact. Reductionism works fine for mechanical assemblies (where parts don’t meaningfully interact) but fails for any system with feedback loops, including games, economies, and ecosystems.

(Sellers, Advanced Game Design, see source-advanced-game-design)

Visual models

Reinforcing loop

A reinforcing loop compounds change: more practice improves skill, better skill increases success, and success encourages still more practice.

Balancing loop

A balancing loop pushes the system back toward equilibrium: rising danger increases caution, caution reduces exposure, and lower exposure dampens danger again.

The formal definition of a system

“A system is the integrated whole that arises out of independent, interacting parts. Those parts have their own internal state, boundaries, and behaviors by which they mutually affect each other. This whole persists over time, adapts to external conditions, and has its own coordinated behaviors that emerge from the interactions of its parts.” — Sellers, Ch. 2

Every system has three kinds of building blocks:

Parts

The atomic units of the system. Each part has:

PropertyDefinition
StateInternal values that can change over time (health, position, velocity, wealth)
BoundariesWhat separates the part from other parts; what it is and is not
BehavioursHow it acts on and reacts to other parts

In a game, parts include: the player avatar, enemies, items, terrain tiles, UI counters, rules — anything that has state and can affect other things.

Loops

Parts interact via their behaviours, creating loops — cycles of cause and effect that circle back to affect earlier parts. Loops are the engine of a system.

Reinforcing loops (positive feedback): A causes B, B amplifies A. Growth or decay compounds. Examples:

  • Money buys upgrades → upgrades earn more money
  • Practice improves skill → skill makes practice more rewarding

Balancing loops (negative feedback): A causes B, B counteracts A. The system seeks equilibrium. Examples:

  • High price reduces demand → lower demand drives price down
  • Player health drops → player becomes more cautious

Unintended consequences loop: A common systems failure pattern. A balancing loop is applied to solve a problem, appearing to work. But a delayed outer reinforcing loop brings the problem back worse. Sellers’ canonical example is the cobra effect:

The British colonial government in India, concerned about cobra populations, offered a bounty for dead cobras. This worked — until enterprising citizens started breeding cobras to collect the bounty. When the bounty was cancelled, the breeders released their now-worthless cobras. The cobra population was larger than before the programme.

The outer loop (financial incentive → cobra breeding → more cobras) was hidden by a delay and only became visible after the fix had seemed to work. This pattern — “fixes that fail” — recurs in game design wherever a designer addresses a symptom without modelling the underlying loop.

Wholes and emergence

When parts form loops, they create wholes — higher-level systems with properties not present in any individual part. These are emergent properties.

Emergence is what makes games interesting. The rules of Chess are fully enumerable; “strategy” is not a rule — it emerges from the interaction of rules as players apply them. A game system’s emergent properties cannot be tested or discovered by reading its rules; they only appear during play.

Hierarchy: Wholes are themselves parts in higher-level systems. A cell is a system of molecules; a tissue is a system of cells; an organism is a system of tissues. Games exhibit similar hierarchy: a combat mechanic is a system of rules; a boss fight is a system of mechanics; a campaign is a system of encounters.

Why game designers must think systemically

Reductionist design produces games that feel arbitrary, fragile, or exploitable. If a designer tunes each mechanic in isolation, they miss the interaction effects — the unintended consequences loops — that emerge when the mechanics interact during play.

Systems thinking provides two practical tools:

  1. Causal loop diagrams: A sketch of parts (nodes) and their causal relationships (arrows), labelled + (amplifies) or − (counteracts). These make hidden loops visible before the game is built.

  2. Hierarchical perspective-shifting: The ability to zoom in to examine a sub-system in detail, then zoom out to see how that sub-system behaves as a part in a higher-level system. Sellers identifies this as a trainable skill central to systemic game design.

Structural coupling

Sellers draws on Maturana and Varela’s (1987) concept of structural coupling to describe the game-player relationship: when two systems interact closely over time, each adapts to the other’s structure. In a well-designed game, the game’s state-space is broad enough to keep adapting to the player as the player adapts to the game. This is the mechanism behind core loop engagement and behind second-order-design.

“A game and player also form a structurally coupled relationship. If the game is systemically designed, it will have defined a sufficiently broad and diverse state-space that it can adapt to the player as the player adapts to it.” — Sellers, Ch. 2

Reductionism critique

Sellers (Ch. 1) argues that the Western scientific tradition has produced a strong default bias toward reductionism — understanding things by analysing their components. For many domains this is appropriate. But for complex adaptive systems (weather, markets, ecosystems, games), reducing to parts loses exactly the information that matters: the loops, the emergent properties, the unintended consequences.

The double pendulum is his physical illustration: a single pendulum is perfectly predictable; a second pendulum added to the end makes the system chaotic and unpredictable from the same starting conditions. The new behaviour is not in either pendulum. It is in their interaction.

In practice

When designing any system:

  1. Identify the parts — what are the nodes that have state?
  2. Identify the behaviours — how do parts affect each other?
  3. Sketch the loops — what cycles form? Which reinforce, which balance?
  4. Ask: what emerges? What unintended consequences loops might hide here?
  5. Build and playtest: emergence cannot be fully modelled on paper.

Systemic red flags:

  • “This mechanic works perfectly in isolation” (reductionist success, systemic risk)
  • A fix that works in the short term but is then cancelled, leaving things worse (unintended consequences loop)
  • Players consistently find one dominant path (a loop has collapsed the decision space — see game-balance)
  • Surprising emergent bugs (e.g. cat deaths in Dwarf Fortress from alcohol poisoning — a systemic cascade nobody designed)

Open questions

  • Sellers argues that reductionism is the enemy of good game design. But many great games have very few interacting loops (e.g. Tetris). Is the systems-thinking argument only compelling at a certain scale of design complexity?
  • Causal loop diagrams are used in systems dynamics but are uncommon in game design practice. Why? Are they too abstract for day-to-day design work, or simply unfamiliar?
  • Emergence can be delightful (unexpected strategies) or catastrophic (exploits, soft-locks). Is there a reliable method for steering toward the former and away from the latter?

Graph View

Backlinks