Part VI: Systems Design

Chapters 24--28

Your game has mechanics, psychology, levels, and narrative. It works, it feels good, it has a world, and it means something. Now we make it deep.

Systems design is the discipline of building the interconnected machinery beneath the surface of a game --- the economies, progression structures, combat frameworks, AI behaviors, and social systems that give a game its complexity, its longevity, and its capacity to surprise. If mechanics are atoms, systems are molecules. They are built from mechanics, but they behave in ways that the individual mechanics don't predict. And they are what separate a game you play for two hours from a game you play for two hundred.

This is the part of the book where your game becomes a living thing. Not in the AI sense --- in the ecological sense. A well-designed game is an ecosystem where resources flow, challenges escalate, abilities unlock new strategies, enemies adapt, and the player's decisions create ripple effects they don't fully anticipate. That aliveness is what makes games endlessly replayable. It is what makes players theory-craft on Reddit and build spreadsheets optimizing their builds and argue about whether the broadsword or the longsword is better for quality builds. (It's the longsword. This is not debatable.)

Systems design is also where games most often go wrong. A badly designed economy breaks progression. A flat progression system makes the late game tedious. A predictable AI makes combat boring. An unbalanced combat system trivializes everything. Systems are interconnected, and a failure in one system cascades through the others. The difficulty of systems design is not in building any single system --- it is in making all of them work together.

What You Will Learn

Chapter 24: Game Economy Design introduces the concept of resources as a design tool. Every game has an economy, even games that don't seem like they do. Celeste has an economy of lives (infinite), time (your real time), and strawberries (optional collectibles). Dark Souls has an economy of souls (XP and currency in one), Estus Flasks (healing), humanity, and weapon upgrade materials. Breath of the Wild has an economy of rupees, ingredients, weapons (which break), arrows, and stamina. An economy is any system where the player acquires, spends, and manages resources. Designing that system --- how resources enter the game, how they are spent, how scarcity creates tension, how abundance creates satisfaction --- is one of the most powerful and most overlooked design skills. We will cover sources and sinks, inflation, dual currencies, and the critical concept of meaningful choice: if the player's economic decisions don't involve genuine tradeoffs, your economy is decorative, not functional. You will design your game's internal economy and implement a shop or trade NPC.

Chapter 25: Progression Systems tackles the question of how the player's capabilities change over time. Why does getting stronger feel so good? Because progression is a feedback loop: the player invests effort, receives expanded capability, uses that capability to overcome challenges that were previously impossible, and feels the satisfaction of growth. Experience points, skill trees, ability unlocks, equipment upgrades, Metroidvania-style gate keys --- these are all progression mechanics, and they serve the same fundamental function: making the player feel that their time investment has produced meaningful change. Dark Souls's progression is brilliant because it operates on two tracks simultaneously: your character gets stronger (stats, weapons, spells), and you get better (pattern recognition, timing, spatial awareness). The best progression systems reward both. The worst reward only the character, making skill irrelevant. You will add ability unlocks or upgrades to your project --- new powers that change how the player interacts with the world and open previously inaccessible areas.

Chapter 26: Combat Design is the biggest chapter in this part, and deservedly so. Combat is the most complex real-time system in most action games, and getting it right is extraordinarily difficult. It requires precise timing, readable enemy behavior, satisfying feedback, meaningful player choice, escalating challenge, and the ineffable quality that the fighting game community calls "feel" --- the responsiveness, the weight, the rhythm that makes hitting an enemy satisfying a thousand times in a row. We will cover attack design (hitboxes, hurtboxes, damage frames, recovery frames), defensive mechanics (dodge, block, parry, and when to use each), enemy design (archetypes, combinations, the importance of readable telegraphs), and boss design (phases, escalation, the climactic test of everything the player has learned). Dark Souls is the primary case study: its combat is a conversation between player and enemy, where spacing, timing, and stamina management create a depth that sustains hundreds of hours. You will build a combat system and a boss fight for your project --- with attack, dodge, hitboxes, and at least two boss phases.

Chapter 27: AI Design addresses the thing that makes enemies feel alive. A well-designed enemy AI does not need to be smart --- it needs to be readable. The player must be able to observe, predict, and exploit enemy behavior. That requires consistent behavioral patterns with enough variation to prevent exploitation. We will cover finite state machines (the workhorse of game AI), behavior trees, flocking, pathfinding basics, and the principle that enemy AI exists to create interesting decisions for the player, not to simulate intelligence. An enemy that perfectly predicts and counters the player's actions is technically impressive and absolutely unfun. An enemy with a clear patrol pattern, a predictable attack telegraph, and one surprising behavior that the player has to learn --- that is good AI design. You will implement enemy AI for your project using a finite state machine: idle, patrol, chase, attack, and retreat states. Simple, readable, and satisfying to fight against.

Chapter 28: Multiplayer Design is the one chapter in this part where the progressive project stays theoretical. Your game is single-player --- and deliberately so, because multiplayer introduces complexity that would overwhelm a first project. But understanding multiplayer design is essential for any designer, because multiplayer changes everything. When you add another human to the system, you can no longer predict behavior. You can no longer balance around a single player's skill. You must account for griefing, cheating, social dynamics, matchmaking, network latency, and the fundamental tension between cooperation and competition. We will cover network architecture (authoritative servers vs. peer-to-peer), lobby design, matchmaking philosophy, cooperative and competitive design patterns, and the social contract that every multiplayer game implicitly establishes. You will write a one-page multiplayer design spec --- a hypothetical multiplayer mode for your game --- as a design exercise.

Systems Thinking

The common thread through all five chapters is systems thinking --- the ability to see a game not as a collection of features but as a network of interconnected systems where changes in one part propagate through the whole.

Consider Dark Souls. The combat system interacts with the progression system (weapon scaling, stat investment). The progression system interacts with the economy (souls for leveling and purchasing). The economy interacts with the world design (souls dropped on death, retrieved from corpse). The world design interacts with the AI (enemy placement creates risk around corpse recovery). Every system is connected to every other system, and the connections create meaning. Losing a large number of souls is devastating because those souls were both your progression currency and your purchasing currency. Retrieving your corpse is tense because the enemies between you and your bloodstain are placed to threaten you. The systems create the experience. Not individually --- together.

Breath of the Wild takes the same approach. The weapon economy (durability, abundance, variety) interacts with combat (you must constantly adapt your fighting style to whatever weapon you have). Combat interacts with the environment (fire, electricity, water, metal, wind). The environment interacts with exploration (weather affects traversal, time of day affects encounters). Exploration interacts with the economy (everything you find is a resource). The systems loop back on themselves in ways that generate thousands of unique situations the designers never scripted.

That is what systems design creates: a game that is more than the sum of its parts. A game where the player's experience is unique, emergent, and endlessly varied. A game that surprises even its creators.

Your Project After Part VI

By the end of these chapters, you will have:

  • An internal economy with a shop or trade NPC
  • Ability unlocks or upgrades that change how the player interacts with the world
  • A combat system with attack, dodge, hitboxes, and satisfying feedback
  • A boss fight with at least two phases
  • Enemy AI using finite state machines (idle, patrol, chase, attack, retreat)
  • A one-page multiplayer design spec (theoretical)

Your game will have depth. Not just length --- depth. The player will make meaningful decisions about how to spend resources, which abilities to unlock, how to approach combat encounters, and how to exploit enemy behavior. Those decisions will interact with each other in ways that create a unique experience for each player.

That depth is what makes players stay. Mechanics get them in the door. Psychology keeps them in the room. Levels give them somewhere to go. Narrative gives them a reason. But systems --- systems give them a game they can inhabit. A game with enough complexity to reward investment, enough interconnection to surprise, and enough depth to sustain the kind of engagement that turns a game from something you play into something you love.

We are building a small game. A 2D action-adventure that will take a player maybe an hour to complete. But a small game with deep systems teaches more than a large game with shallow ones. And the systems thinking you develop here will scale to any game you ever make.

Chapters in This Part