Module 9 · Game design theory

MDA and the core loop

You cannot program a game to be "fun" directly. You code mechanics, from which emergent dynamics arise at runtime, and only then does the player feel the aesthetics. The designer walks that chain right to left, the player left to right. And the unit you actually turn is the loop.

~16 min🎲 design model

The gist in 30 seconds

A game is a system you experience through repetition. The core loop is the smallest repeatable unit (Tetris: fall→rotate→land→clear). The meta / engagement loop wraps it in progression and meaning (Hades: clear a room→new dialogue→you start to care). MDA gives the causal chain: Mechanics (the rules you code) → Dynamics (the behavior that arises at runtime) → Aesthetics (what the player feels). The key asymmetry: the designer works right to left (I want suspense → which dynamics → which mechanics), the player experiences it left to right. "Fun" is not built directly — you build mechanics and turn them until the emergent dynamics deliver the aesthetic you wanted. Which is why design is empirical: dynamics are emergent, and you observe them in a prototype rather than deducing them on paper.

The mechanism: the loop as the atom, MDA as the causality

The core loop and the meta loop

The core loop is the smallest repeatable unit of gameplay: Elden Ring (meet an enemy→read it→dodge/parry→strike), Tetris (falls→rotate→lands→line), poker (ante→hand→bet→showdown). The meta loop is the larger progression loop on top (died→came back stronger→back to the boss). A good loop rests on four properties: clarity (the goal is obvious), feedback (an instant response to an action), escalation (difficulty grows inside the loop) and variation (sub-variants: enemies, abilities). Without them, 60 hours of "enter a room→grind it down→loot→repeat" is monotony under cosmetic difficulty jumps.

Core loop vs engagement loop

The core loop is mechanics only: what the player does. The engagement loop is mechanics plus context: why they care. Hades: core = shoot→dodge→special→clear; engagement = the same thing → new dialogue → a character references your previous runs → you get hooked on their arc. The same mechanics plus different context = different retention — which is why Hades resonates and a roguelike with identical mechanics but no wrapping does not (the same conversation about retention, but from the design side).

MDA: mechanics → dynamics → aesthetics

Mechanics are the rules and systems (what the code implements). Dynamics are the behavior that arises as the rules interact at runtime. Aesthetics are the player's experience. Traced through poker:

The asymmetry is the whole point of MDA. An analyst and a player read the chain left to right (rules → emergent play → feeling). The designer works right to left: "I want it to be tense" → which dynamics produce tension (uncertainty, hidden information) → which mechanics produce those dynamics (face-down cards, probabilistic resolution). You never code "suspense" — you code mechanics and turn them until the emergent dynamic delivers the aesthetic you wanted.

Why this is empirical rather than deducible

Dynamics are emergent: they arise from mechanics interacting with each other. The number of pairwise interactions across $n$ mechanics grows quadratically:

D_{pairs} = \frac{n (n - 1)}{2}

10 mechanics → 45 pairwise interactions (and that is without triples and chains). You cannot enumerate and predict all of it — which is why design is empirical: you prototype, play, and see which dynamics actually arose and what aesthetic they produced. It is an inverse problem with an emergent middle — solved by observation, not by deduction.

The 8 kinds of fun (LeBlanc)

"Aesthetics" is the most underspecified slot in MDA. Marc LeBlanc's answer (in the original 2004 paper and in talks) is a taxonomy of 8 kinds of fun, concrete goals instead of a vague "make it fun": Sensation (Journey, fighting-game hit effects), Fantasy (The Sims, Skyrim), Narrative (The Last of Us, Disco Elysium), Challenge (Dark Souls, Celeste), Fellowship (MMOs, co-op), Discovery (Outer Wilds, Subnautica), Expression (Minecraft, modding), Submission (Candy Crush, idle games). A game usually aims at 2–3 of them; trying to hit all 8 dilutes each one. A practical review habit: when a prototype "feels off", write down which kinds of fun you intended and which ones it actually delivers.

🕹 What to play — and what to notice

Hades core vs engagement loop

Mechanically a simple roguelike. It hooks you because of the engagement loop: every run advances the dialogue, and the characters remember your deaths. The same core loop plus a wrapping of meaning = hundreds of hours of retention.

🎮 Do: play a run and write out in one line the core loop (pure mechanics: shoot→dodge→special→clear), then the engagement loop (what makes you start the next run — dialogue, relationships, a meta unlock). Feel the difference between "what I do" and "why I care".

Poker / Balatro an MDA trace, live

Simple mechanics (cards, betting, rankings) → rich dynamics (bluffing, risk/reward, reading people) → a strong aesthetic (suspense). Balatro takes poker's mechanics and, through a new dynamic (multiplier jokers), delivers a completely different aesthetic — combo mastery.

🎮 Do an MDA trace: take any game, write down 3 mechanics → which dynamics arise from them at runtime → which aesthetic you feel. Then run it backwards (as the designer): name an aesthetic you would want to strengthen and work out which mechanic to touch for it.

A "grindy" game diagnosis through MDA

When a game "feels like a grind", that is an aesthetic observation. Trace downwards: which loops repeat (kill→XP) → what behavior emerges (players min-max efficiency) → conclusion: the mechanics are tuned for grinding, not for exploration.

🎮 Notice: in a game that bored you, identify which dynamic the players optimize (farming speed? the safe route?) and which mechanic produces it. Often "boring" means the mechanics reward a different dynamic than the designer intended.

Deep end · the inverse problem and the combinatorics of emergenceskippable

Why aesthetics cannot be designed directly

The mapping from mechanics to aesthetics is surjective and not uniquely invertible: the same aesthetic (suspense) comes from different dynamics (hidden information, a timer, an irreversible choice), and each dynamic comes from different mechanics. The designer solves the inverse problem $M = f^{- 1} (A)$ with no closed form for $f$ — only by trying. And the middle (dynamics) is emergent: with $n$ interacting systems there are already $n (n - 1) / 2$ pairwise links, and once you add triples and temporal chains the space of outcomes is not enumerable on paper. Hence the iron rule: dynamics are a property of runtime and are only visible in a playable prototype.

The consequence for process

That is why a playable vertical slice gets built early (see scope and prototype): until you run it you do not know the dynamics, which means you do not know the aesthetics. A "design document" does not replace a prototype precisely because it describes mechanics, while what sells a game is a dynamic the document cannot predict.

Deep end · design: the loop, the 8 kinds of fun, MDA in reviewskippable

Designing the loop

A core loop is tuned along four axes: clarity (the player always knows the next step), feedback (every action produces a response — a damage number, a knockback, juice), escalation (difficulty rises within a session) and variation (sub-variants keep the loop from turning into noise). The engagement loop adds a stake: why repeat it — progression, meaning, relationships, a meta unlock.

The 8 kinds of fun as a checklist

Not "make it fun" but "which 2–3 kinds of fun am I aiming at" — and at every review, check the intended against the delivered. Different players look for different kinds of fun (this is orthogonal to the motivations in Bartle/Quantic Foundry — mapping between them is a rough analogy, not an identity).

MDA as a bug-report language for design

"Boring/grindy/unfair" are aesthetic symptoms. You diagnose by tracing down to the mechanic, treat it by editing the mechanic, and re-check the dynamic with a playtest — because editing a mechanic changes the emergent middle unpredictably.

Analogy

MDA is cooking. Mechanics = the ingredients and steps of the recipe (what you control directly). Dynamics = the chemistry in the pan (the Maillard reaction, emulsification — emergent: you created the conditions but you are not placing molecules by hand). Aesthetics = the taste in the guest's mouth. You do not cook "delicious" directly — you adjust the ingredients and the technique, the chemistry happens on its own, and taste comes out at the end of the chain. And you taste as you go (playtest), because you cannot predict the chemistry from the recipe alone.

Why it matters

MDA and the loop give you two things: a language for reasoning about why a game feels the way it does, and a method — design from the aesthetic backwards to the mechanic and verify the dynamic with a playtest. The loop is the unit you iterate on. This is the foundation of design judgment. And the frame "the system is emergent in the middle → observe rather than deduce; design backwards from the target behavior" carries far beyond games — it is exactly how to think about any system whose behavior only shows up at runtime.

🔁 Beyond games — where this transfers

The lesson is about an inverse problem with an emergent middle: you specify the target behavior but control only the rules, and you see the result by running it.

ML / AI (your domain): MDA is exactly reward design / specification in RL. You cannot code "the agent plays interestingly" — you shape a reward (the mechanic), observe the emergent policy (the dynamic) and check it against your intent (the aesthetic). Reward hacking is a mismatch between dynamic and aesthetic: the agent optimizes the letter of the mechanic rather than the feeling you meant (just as a "grindy" game optimizes the wrong dynamic). Quadratic emergence ⇄ why a trained system cannot be statically verified: behavior is a property of runtime and is assessed empirically (an eval harness = a playtest). Core loop vs engagement loop ⇄ a proxy metric vs the true goal (Goodhart: mechanical retention ≠ meaningful retention). "Design backwards from the experience" ⇄ objective-first / eval-driven development: target behavior and evaluation first, then the system, then measure the gap. And the 8 kinds of fun ⇄ decomposing a fuzzy goal ("good") into concrete measurable sub-criteria (the way "helpful" gets split into specific evals).

Product/UX: you build features (mechanics), users develop usage patterns (dynamics), and the metric is their satisfaction (aesthetics); JTBD is designing backwards from the outcome you want.

Systems: the emergent behavior of a complex system (microservices, an economy, traffic) cannot be deduced from component specifications — you load it and observe (a load test = a playtest).

Principle: if the middle is emergent, do not deduce — prototype and observe; design backwards from the target experience to the rules.

🔧 Take one apart and design one — at the table

What to play is above (🕹). Here — practising the frame itself.

🔧 An MDA trace of three games ~30 min

Take three favorite games. For each: 3 mechanics → the dynamics that arise → the aesthetic (which 2–3 of the 8 kinds of fun). Then do a reverse pass: pick an aesthetic you want to add and name the minimal mechanical change. Notice where you cannot predict the dynamic — those are the places that need a playtest.

🧪 Design a loop ~20 min, paper

Invent a core loop in one line (verb→…→repeat) and check it against the 4 axes (clarity/feedback/escalation/variation). Wrap it in an engagement loop: what gives you a stake in repeating it. Connect it to the game loop (the loop lives inside the frame loop) and to your own Novgorod — what its core loop is and what hooks people.

Checklist: did 3 MDA traces forwards and backwards; named the target kinds of fun; designed a core plus engagement loop; found the places where the dynamic has to be verified by playtest; connected it to reward design.

Connections

Flow and difficulty — the core loop has to sit inside the flow channel: challenge matched to skill, otherwise boredom or anxiety.

adjacent

The core loop and retention — the same loop from the monetization and retention side (D1/D7, the leaky bucket).

foundation

The crystallization of genres — emergence and systemic design: simple rules → complex behavior.

Player psychology — which motivations your aesthetic is aiming at.

Questions worth asking

Why can't "fun" be designed directly?

Because "fun" (the aesthetic) is a downstream effect of dynamics, and dynamics are emergent: they arise from mechanics interacting at runtime rather than being baked into any single mechanic. You control only the left end of the chain (rules/code). Between rules and feeling sits an emergent middle that cannot be deduced on paper (the number of interactions grows quadratically, and combinatorially once you add chains). So "fun" is a goal you approach in reverse (which dynamic produces the feeling → which mechanic produces the dynamic) and confirm with a playtest. There is no direct "make it fun" lever in code — only the mechanics levers and observing what grew out of them.

Core loop and engagement loop — what is the practical difference?

The core loop is pure mechanics ("what I do"): shoot→dodge→clear. The engagement loop is mechanics plus the context that gives you a stake ("why I care"): the same clearing, but it unlocks dialogue, moves a relationship, accumulates meta progress. The practical difference is retention: a strong core loop gives good first hours, but over the long haul it is the engagement loop that holds the player (meaning, progression, attachment). Two roguelikes with identical mechanics diverge exactly here: Hades with its wrapping hooks people for hundreds of hours, a "bare" roguelike for a few. And there is a Goodhart trap: you can inflate engagement with cheap hooks (dailies, FOMO) and the retention metric will rise while core enjoyment does not; retention like that is fragile.

Is MDA still used? "Aesthetics" gets criticized.

Yes, MDA (2004) remains the most cited framework in game design, though the criticism is fair: the "Aesthetics" slot is underspecified from the start, and the mechanics/dynamics split blurs at the boundary (sometimes it is unclear whether something is a rule or already emergent behavior). The answer to the first criticism is LeBlanc's taxonomy of 8 kinds of fun (concrete aesthetic goals). In practice MDA is valued not as strict theory but as a language and checklist: it forces you to separate "what I coded" from "what grew out of it" from "what the player felt" — and that separation alone catches a common beginner mistake (designing "features" straight away without asking what dynamic and aesthetic they will produce). There are newer frameworks too (Machinations for economies, Schell's "lenses"), but MDA is the base vocabulary.

How does MDA relate to reward design in RL?

Almost word for word. In RL you cannot specify "behave interestingly/safely" directly — you specify a reward (that is the mechanic: the rule the system optimizes), run training and get an emergent policy (the dynamic), which you evaluate against your intent (the aesthetic/specification). The pathologies match too: reward hacking is when the emergent dynamic optimizes the letter of the reward rather than the intended behavior, exactly as a "grindy" game optimizes a different dynamic than the designer wanted. And the method is the same: behavior is a property of runtime, so it cannot be proven from a specification, only measured empirically (an eval harness = a playtest), and you design in reverse from the target behavior. If you can read a game through MDA, you already know how to think about specifying and evaluating learned systems.