Game Design Fundamentals

What is Game Design?

GameGame design is the act of deciding what a game should be." — Jesse Schell [1]

The MDA Framework

TheThe MDA framework — Mechanics, Dynamics, Aesthetics — was developed by Robin Hunicke, Marc LeBlanc and Robert Zubek across a series of GDC workshops between 2001 and 2004, and formally published in 2004 [2]. Its core insight is that a game can be read on three separate layers, and that different people encounter those layers in opposite orders. The designer works from the bottom up: mechanics first (the rules and systems actually coded), hoping the dynamics that emerge from play produce the intended aesthetics — the feelings the player ends up with. The player experiences it top-down: the feeling comes first, and only a curious or analytical player ever looks underneath to see which rule produced it. Confusion between these layers is a common source of design mistakes — "make it more fun" is an aesthetics-layer note that says nothing about which mechanic to actually change.

Designer creates Mechanics → generates Dynamics → creates Aesthetics Player experiences Aesthetics → through Dynamics → from Mechanics

Core Aesthetics (8 Kinds of Fun)

LeBlanc's own contribution to the MDA work names eight recurring aesthetics that games satisfy, and it's worth naming a few games against each one to see the taxonomy actually discriminate — a rhythm game and an RPG can both be "fun" while pulling on almost none of the same aesthetic [2].

Core Loops

TheThe fundamental cycle of player activity.

Almost every game, however complex it looks from outside, is built from a small number of loops nested inside one another, each running at its own timescale. Zooming in on any single moment of play reveals the fastest of these; zooming out to a whole play session reveals the slowest. Distinguishing the three is useful because a problem with the game rarely shows up on the loop it actually lives in — a "boring" moment-to-moment feel is usually a micro-loop problem, while a game that's fun for an hour but nobody comes back to the next day is usually a macro-loop problem, and no amount of micro-loop polish fixes it.

Micro Loop (Second-to-Second)

The micro loop is the moment-to-moment rhythm of play: the player does something, the game responds, and the player adjusts based on that response. This is the loop that has to feel good on its own, thousands of times in a row, before anything built on top of it matters — it's why a platformer's jump or a shooter's aim needs so much individual tuning attention.

Input → Process → Feedback → State Change → Repeat

Meso Loop (Minute-to-Minute)

One level up, the meso loop strings several micro-loop interactions into something with a shape: a fight, a puzzle, a quest. This is the timescale at which most tactical decisions live — whether to engage an enemy, which route to take, what to spend a resource on — and it's usually the loop a player is describing when they say a game is "engaging" moment-to-moment beyond the raw feel of an individual input.

Encounter → Decision → Outcome → Reward → Progress

Macro Loop (Session-to-Session)

The macro loop is the reason a player opens the game again tomorrow rather than starting something else. It operates across whole sessions rather than single encounters, tying today's progress into a reason to return — an unlock still one grind away, a daily reward, a story beat left mid-cliffhanger. Live-service and free-to-play games live or die on this loop specifically, which is why retention metrics (see Testing & Iteration below) are built almost entirely around measuring it.

Session Goal → Play → Progress → Meta-progression → Retention

Loop Design Principles

The same handful of properties make a loop at any of these three timescales work, which is why they're worth stating once rather than three times.

Player Types (Bartle Types)

RichardRichard Bartle's 1996 essay "Hearts, Clubs, Diamonds, Spades: Players Who Suit MUDs" proposed a taxonomy along two axes — acting versus interacting, and a focus on the world versus a focus on other players — that produces four archetypes, each mapped onto a playing-card suit [3]. It was written about text-based multi-user dungeons nearly three decades ago, but the categories transferred almost unchanged into modern MMOs and live-service design, which is a fair test of whether a model has actually found something real about player motivation rather than an artefact of one genre.

Design insight: Most players are hybrids. Design for multiple types.

Game Mechanics Categories

MostMost games draw their mechanics from a fairly small recurring toolbox, mixed and re-skinned rather than invented fresh each time. Naming the categories is useful less as trivia and more as a checklist when designing: a game leaning entirely on combat mechanics with no progression or exploration layered on top will feel thinner than one drawing from several categories that reinforce each other.

Systems Design

WhereWhere the previous section catalogued the pieces a game might use, systems design is about how those pieces interact once a player is actually turning them over for hours — the economy that governs a currency, the shape a character's growth takes across a whole playthrough. Get a system wrong here and no amount of individual mechanic polish will rescue it, because the problem isn't any one mechanic but the loop of incentives connecting them.

Resource Economy

Any in-game resource — gold, energy, crafting materials — can be modelled the same way a real economy is: something generates it, something holds it, and something removes it from circulation. Naming the four roles separately makes an otherwise vague complaint like "the economy feels broken" into a specific, fixable question: is a source over-producing, is a sink missing, or is a pool letting value accumulate with nowhere useful to go?

Sources → Pools → Sinks → Feedback

Balance rule: Source rate ≈ Sink rate over time

Progression Systems

Progression is the shape a player's growth takes across the whole game, and that shape is itself a design decision independent of any individual mechanic. A strictly linear progression guarantees every player sees the same content in the same order, which makes pacing easy to author but removes replay value; an open progression trades that authorial control for player agency and the harder problem of making sure the game still holds together no matter which order things are tackled in.

Difficulty & Flow

Flow Channel (Csíkszentmihályi)

PsychologistPsychologist Mihaly Csíkszentmihályi coined "flow" for the state of full absorption people report when a task's difficulty is closely matched to their skill — neither so easy it bores them nor so hard it causes anxiety [4]. It was developed studying work, sport, and creative practice generally, not games specifically, but it maps almost directly onto difficulty tuning: a game that's too easy for a given player produces boredom, one that's too hard produces anxiety, and the design goal is keeping the player inside the narrow channel between the two as their skill improves over a session.

Anxiety ↑
    │    ┌─────────────┐
    │    │   FLOW      │ ◄── Optimal experience
    │    └─────────────┘
    │         Boredom │
    └──────────────────→ Skill
         Challenge →

Dynamic Difficulty Adjustment (DDA)

Rather than trusting a single fixed difficulty setting to keep every player in their own flow channel, dynamic difficulty adjustment nudges the challenge up or down in response to how the player is actually doing — an easy target if a losing streak drags on, a slightly tougher one after several wins in a row. Used well it's invisible, quietly keeping a wide range of skill levels each in their own flow channel; used clumsily, or exposed to a player who notices the game is "cheating" for or against them, it can undermine the sense that skill matters at all, which is why some genres (competitive multiplayer especially) avoid it deliberately.

# Simple DDA
if player_wins_streak > 3:
    difficulty += 0.1
elif player_loses_streak > 2:
    difficulty -= 0.1
difficulty = max(0.5, min(2.0, difficulty))

// Simple DDA
if (player_wins_streak > 3) {
    difficulty += 0.1;
} else if (player_loses_streak > 2) {
    difficulty -= 0.1;
}
difficulty = std::clamp(difficulty, 0.5, 2.0);

// Simple DDA
if (playerWinsStreak > 3) {
    difficulty += 0.1;
} else if (playerLosesStreak > 2) {
    difficulty -= 0.1;
}
difficulty = Math.clamp(difficulty, 0.5, 2.0);

// Simple DDA
if (playerWinsStreak > 3) {
    difficulty += 0.1;
} else if (playerLosesStreak > 2) {
    difficulty -= 0.1;
}
difficulty = Math.Clamp(difficulty, 0.5, 2.0);

# Simple DDA
if player_wins_streak > 3
  difficulty += 0.1
elsif player_loses_streak > 2
  difficulty -= 0.1
end
difficulty = difficulty.clamp(0.5, 2.0)

Game Feel (Juice)

TheThe tactile, kinesthetic sense of interaction.

"Juice" is the games-industry term for the layer of feedback wrapped around a mechanic that has no effect on the underlying rules at all, and yet makes the difference between an action feeling inert and feeling satisfying. Strip the screen shake, particles, and sound out of a game's core attack and the numbers behind it are unchanged, but the hit will feel like it landed on cardboard rather than on something solid — which is why juice is treated as a first-class design concern rather than late-stage decoration bolted on once the mechanics are "done".

Level Design

AA level is where all the systems discussed above — mechanics, loops, difficulty, feel — get assembled into a specific, authored experience for the player to walk through. Two tools do most of the work: pacing, which controls the rhythm of tension and release across the level as a whole, and a small set of recurring spatial patterns that shape how the player physically moves through it.

Pacing

A level that stays at one intensity throughout — all challenge, or all downtime — tends to feel exhausting or flat respectively; well-paced levels alternate between the two, giving the player a chance to breathe (and to consolidate what they've just learned) before ramping tension back up. The shape below is a common template rather than a rigid rule: not every level needs a twist, but almost every level benefits from a deliberate rise and fall rather than a flat line.

Intro → Tutorial → Ramp → Challenge → Twist → Climax → Resolution

Design Patterns

Beyond pacing, level designers reach for a handful of recurring spatial structures again and again, because each one reliably produces a particular kind of player behaviour. A lock-and-key structure controls the order content is seen in; a loop back to a familiar hub re-establishes the player's mental map while revealing that map has changed; an arena focuses a fight by removing escape routes. None of these is exclusive to one genre — the same handful of patterns show up in a 2D platformer and a 3D open-world game alike, just at different scales.

Balancing

BalancingBalancing is the ongoing work of making sure the choices a game offers are all worth making — that no single strategy dominates every situation, and that a design's stated trade-offs actually hold up once players start optimising against them.

The Triangle of Balance

Any item, unit, or ability in a game can be described along three axes that pull against each other: how powerful it is, how much it costs to use or acquire, and how broadly useful it is across situations. A design that lets one option score high on all three at once is, in practice, a design bug — it gives players no real reason to choose anything else, and the fix is almost always to pull one axis back down rather than to nerf the others up.

        Power
          │
    Cost ←┼→ Utility

Rock-Paper-Scissors Balance

Not every balance problem is solved by a single power curve, though — sometimes the goal is a cycle of counters, where no option is simply better than another, only better in a specific matchup. This intransitive structure rewards reading the opponent and adapting rather than converging on one dominant strategy, and it's why so many multiplayer games (fighting games, strategy games, team shooters) build their roster or unit list around counter-relationships rather than a strict power ranking.

Unit A beats B beats C beats A

Testing & Iteration

NoneNone of the frameworks above survives first contact with real players unchanged — design is an empirical discipline as much as a creative one, and the only way to find out whether a loop, a balance pass, or a level actually plays the way it was intended is to watch someone else play it. Different stages of development call for different kinds of test, because the questions worth asking change as the game matures.

Playtest Types

Testing too early with strangers wastes their time on a game that isn't ready to be judged fairly; testing too late with only friends risks a biased read, since people who like the designer tend to be forgiving. The useful pattern is to widen the circle of testers as the game solidifies — solo testing to catch the obvious breaks, friends once there's a real loop to react to, strangers once it needs to stand on its own, and live analytics once it's shipped and generating real behavioural data at a scale no playtest session could match.

Data-Driven Design

Once a game is live, playtesting gives way to telemetry — aggregate behavioural data from far more players than could ever be watched directly, at the cost of losing the qualitative "why" a live playtest session provides. The metrics below are the ones design teams watch most closely, precisely because each answers a question a designer's own intuition is bad at estimating from the inside: exactly where players are actually dropping off, and exactly how the economy is drifting over weeks of real play rather than a single test session.

References

1. Schell, J. (2019). The Art of Game Design: A Book of Lenses (3rd ed.). CRC Press. https://www.inventoridigiochi.it/wp-content/uploads/2020/07/art-of-game-design.pdf
2. Hunicke, R., LeBlanc, M., & Zubek, R. (2004). "MDA: A Formal Approach to Game Design and Game Research." Proceedings of the AAAI Workshop on Challenges in Game AI. https://aaai.org/papers/ws04-04-001-mda-a-formal-approach-to-game-design-and-game-research/
3. Bartle, R. (1996). "Hearts, Clubs, Diamonds, Spades: Players Who Suit MUDs." Journal of MUD Research, 1(1). https://www.researchgate.net/publication/247190693_Hearts_clubs_diamonds_spades_Players_who_suit_MUDs
4. Csikszentmihalyi, M. (1990). Flow: The Psychology of Optimal Experience. Harper & Row. https://archive.org/details/flowpsychologyof0000csik
5. Salen, K. & Zimmerman, E. (2003). Rules of Play: Game Design Fundamentals. MIT Press.
6. Dormans, J. (2012). Game Mechanics: Advanced Game Design. New Riders.
7. Rogers, S. (2014). Level Up! The Guide to Great Video Game Design (2nd ed.). Wiley.