Part V · Chapter 32
Putting It All Together
Everything in this book, used together, on three projects. The original plan for this chapter named three examples: a project derived from a small game I liked, a project to spread Nonviolent Communication, and the ultimate dream game. Each one shows a different side of the method.
- The derivative shows how a small, finite game becomes a foundation for something infinite.
- The NVC project shows the fork between a game and an interactive tool, and how to do the tool honestly.
- The dream game shows the whole technical side working together on the biggest design, including the wall it hit and how the purpose got it past.
Each walkthrough follows the same path: inspiration, feelings and needs, purpose, the medium, inventory, foundations, content, structure, and the first build. Notice how each step answers questions the previous one raised, and how the purpose settles every decision.
Walkthrough 1: from a small ragdoll game to a universe#
The inspiration#
Floppy Heroes is a simple gladiator-like game. Two or more ragdoll characters with armor and weapons fly freely through the air, but can't control their rotation. They try to collide cleverly, dealing damage while protecting their weak spots (exposed skin, the head) through careful positioning and timing of their limbs, armor and swords. There's a basic versus mode, and a ten-level gauntlet against randomized opponents with increasingly dangerous gear. You can unlock and customize your character. That's it. No further metagame.
I found it really satisfying, despite how simple it is. And I also felt it was too simple and restrictive to enjoy beyond a few sessions.
Feelings and needs#
Two sets of feelings, as in the robot game of Chapter 2. While playing: delight, amusement, absorption, the tactile satisfaction of physics doing something unexpected. After a few sessions: restless, disappointed, wanting more. Translated: the game met needs for play, physical mastery, surprise and humor, and then stopped meeting the need for variety and meaning, because its structure ran out.
Notice what that tells me. The mechanic isn't the problem; it's wonderful. The structure is the problem. That's the specialist's approach to "something old": keep what meets the needs, find where the old design stops meeting them.
The first idea, and why it wasn't enough#
My first thought was the beginner's: make my own version with free rotation, guns and futuristic gear, and more interesting levels with hazards and props. Bigger, more features. But checked against the needs, that only adds content to a finite structure. It would meet the need for variety a little longer, and then run out the same way. Additive content on a dead end.
Finding the real purpose#
Then I looked at some of my older design documents, especially one for a universe-simulation "super game", and saw the connection. The ragdoll room battler is a perfect moment-to-moment core for something much bigger. The purpose became: the tactile joy of free-flying physics characters, in a world that never runs out of new situations to use it in.
That purpose is a mechanics-driven one, so the medium is clearly a game, and the structure has to be infinite (Chapter 24).
The design that follows#
The result is a design I call RoomSpace. Every step comes from the purpose:
- The world is made of rooms, like 2D terrariums or aquariums seen from the side, each with its own local climate: weather, gravity, flora and fauna, liquids, gases, materials. The original game's arena became the building block of a universe. A room can be a spot on a planet's surface, underground, underwater, in the sky or in deep space.
- Rooms connect through doors, and influence each other: what happens in one affects its neighbors. Thousands of rooms make planets, and planets make a universe.
- The characters keep the core feel: ragdoll humans who can push against gravity and move anywhere in a room, like fish in an aquarium. Any character can interact with any object, item or element, which makes all items multiplicative (Chapter 23).
- Biomes come from forces, not templates (Chapter 22). The generator adds materials and conditions, and the climate and biome emerge. Players can change a room's climate through their actions, turning a desert into a forest and back.
- The universe follows equivalent exchange: matter is never created or destroyed, only transformed. That's the "natural laws" link of the dependency chain (Chapter 21), and it gives balance for free.
- Hardware is a law of nature. Only the room the player is in is fully simulated. Every other room is a semi-dormant file, updated when needed by a background "universe events" process, which can trigger events when the player arrives. That keeps the universe huge but always within the computer's limits (Chapter 26).
- The metagame is a platform. The same universe can host conquest, adventure, terraforming, investigation, or all of them at once, through an infinite overarching goal and generated campaigns. Like waking up on a free Sunday and deciding what kind of day it'll be.
The first build#
Here's where scope maximization pays off (Chapter 28). The full design is huge, but the first build is tiny: one ragdoll character, one bare room, a few basic weapons and armor pieces, and a game manager that sets up the room and resets it. That's basically the original game with free rotation, which is exactly the first idea I had. The difference is that now it's built on a framework designed to grow: each system can later be swapped for a more advanced one that was planned from the start, until the room battler has grown into the full universe, without ever needing a rewrite from scratch.
The simple idea and the huge idea turned out to be the same project at two points in time. The design work is what connects them.
Walkthrough 2: a project to spread NVC#
The inspiration#
Discovering Nonviolent Communication was one of the most important things that ever happened to me. It explained so much about people, conflict and myself that I'd been confused by my whole life. And I felt two things at once: huge relief and hope, and frustration and sadness that nobody had taught me this sooner, and that most people still haven't heard of it. So the urge comes: make something that spreads it.
Feelings and needs#
Relief and hope: met needs for understanding, peace and connection. Frustration and sadness: unmet needs for contribution (I want others to have this too), for a more peaceful world, and for being understood myself. So the purpose of the project is mostly the need to give (Chapter 12): to contribute to other people's lives by passing on something that made mine more wonderful.
The fork: game or tool?#
This is the most important decision in this project, and the most tempting one to get wrong. The obvious beginner's idea is "a fun game that teaches NVC": cute characters, points for using the right words, levels that unlock as you learn. That's gamification, and it would fail for every reason in Chapter 12. The intention is a real-life change (people actually communicating differently), so if I disguise it as a game, players will eventually notice they're being taught, feel manipulated, and associate NVC itself with being manipulated. That would be a disaster for a project whose whole point is honesty and connection.
So the honest choice is an interactive tool, and it says so up front: "This will help you understand people and be understood. Here's how. Try it."
Designing the tool#
Following the four steps for an awareness tool from Chapter 12:
- Re-create the inspiration. The moment that moved me was seeing a conflict dissolve when the needs underneath it were finally heard. So the tool opens with that experience: a short, real-feeling exchange where two people are stuck in judgements and blame, and then the same exchange where one of them hears the need behind the other's words, and everything changes. The user doesn't read about it. They watch it happen, and feel the difference.
- Show the need behind it. Then the tool shows what was going on underneath: the feelings and needs on both sides, using the feelings and needs lists. The point is the realization that the "enemy" needed the same things as everyone else.
- Offer a concrete way to use it. Practice, on the user's own material. They write down something someone said to them, or something they said, and the tool walks them through translating it: what was observed, what was felt, what was needed, what could be requested. The feelings and needs lists are always at hand, the way you'd print them out for a partner (Chapter 2). Practice scenarios come from situations people actually face, including some from game development: an angry review, a teammate who missed a deadline, a partner who wants a feature you think is wrong.
- Show the effect. The most important step. The tool invites the user to try one translation in real life, and come back and note what happened. Their own growing record of real conversations that went better is the only progress bar the tool has.
What it deliberately doesn't have: points, grades, streaks, achievements, praise, or any nagging to come back. Those would contradict the very thing it teaches. People who have the need will come and come back because it keeps meeting it. That's power with people, applied to the tool itself.
And if I want to make a game?#
There's a second, separate option, and it's important to keep it separate. If I ever make a game where NVC appears, it has to be a real game first, with its own purpose. Say a postal-service game with an infinite overarching goal (Chapter 24), where some quests involve neighbors in a dispute. If the game's world simply works in such a way that hearing what each side needs resolves the dispute better than taking sides, players will get practice at it as a side effect, just because it's the most effective way to play. No lessons, no lectures. If it ever started to feel like a lesson, I'd take it out, because the game comes first.
Beyond the tool#
Sharing it follows from the purpose: it should be free, because the purpose is to give, and money in the way would block exactly the people who need it most. Support for its creator can come from those who want to say thank you (Chapter 30). And the presentation should feel like what it is: calm, warm and honest, not flashy. Its store page should read like an invitation, because that's what it is.
Walkthrough 3: the ultimate dream game#
The inspiration#
You'll read in Growing as a Designer how much of my life went into Cortex Command: clumsy physics soldiers delivered by rocket, every bullet a real object, terrain you dig through. Over the years more games piled on top of it: the grid tactics of Advance Wars, the fort under fire of Forts, the ship systems of FTL, the squad preparation of XCOM. And under all of them, an old fantasy: the mobile fortress, a base that carries your squads, factories and guns right into the fight.
The dream is all of it in one game, set in my own AAL universe. Its working name is AAL Bunkerships, after those mobile fortresses. On my site it's called Tactical Arsenal Command.
Feelings and needs#
While playing those games: absorbed, playful, clever when a plan worked, and delighted when the physics did something nobody planned, like a fallen soldier's rifle tumbling down a shaft and going off at the bottom. After a match: tired, and strangely empty. That bothered me enough to write out why. I found two causes.
- Friction. Strategy matches demand constant vigilance, and the best part is the sigh of relief at the end. Friction grows a need for efficiency, session after session, so I'd rush and brute-force just to get away from it sooner.
- The reset. All the care I put into a base and its logistics was thrown away when the match ended, and the next map started from zero. If the structure doesn't value finesse, why bother with it next time?
Translated: those games met needs for play, creativity, competence, surprise and humor, and left needs for meaning (work that counts), continuity, ease and autonomy unmet. The purpose: the playful, inventive joy of tactical physics combat, in a campaign where everything you build and every battle you fight counts, without the friction.
The medium#
Commanding squads, mobile fortresses and starships is far too dangerous and too expensive for real life (Chapter 10), and the joy is in the mechanics, so it's a game. Because the missing needs are meaning and continuity, its structure has to be infinite (Chapter 24).
Notice what the purpose doesn't ask for: a simulated universe, which RoomSpace needed. This purpose is about battles and the fleet you fight them with, so the world can be a galaxy of regions and missions. The purpose decides the scale, too.
Inventory#
Physics combat is expensive. Dozens of characters, projectiles, explosions and debris have to exist at once, and the game must never lag. So the technology shapes the design from the start (Chapter 20):
- Cheap bodies. Each character is one sprite moved by physics forces, not a ragdoll with limbs. Projectiles are fairly slow and effects are few, because many will fire at once. Terrain is tiles that can be partly destroyed, down to an indestructible bedrock.
- A limit with a reason. How many ships and squads you can bring is set by your Command Core, the machine that controls them. It has a fixed processing capacity, like a party of six creatures in Pokémon. The hardware limit becomes a law of the world, not an arbitrary rule (Chapter 22).
The human side: no level ever has a bottomless pit or an instant death. In the sky, in orbit or at sea, everything carries an emergency float that brings it back up, so even a gun thrown overboard floats back within reach. And the resources: one designer, and a design this big. That decides the first build.
Foundations#
Before any gun or ship, the standards (Chapter 21): one weapon system that can represent any firearm, melee weapon, shield, tool or grenade; one character system for humans and non-humans alike; standardized elements (fire, smoke, electricity, acid, water, oil, plasma), status effects, and resources that come in renewable and nonrenewable forms.
Bunkerships follow the same rules as everything else. Every system on board is a physical module you can see and shoot: the reactor, airlocks, hangars, heat sinks, the maintenance network. If it exists, it works, and that's its capacity. That gives balance by real-life logic (Chapter 25): a bigger ship has more to maintain and more weak points, like the exhaust port on a certain moon-sized battle station. The difficulty doesn't rise or fall with wealth; it changes flavor.
Content#
Instead of fixed factions, the game has brands. An automated galactic arms supplier with no favorites sells several, each a complete military kit with its own style. Before a campaign you choose your licenses: one brand gets the best discount, and every extra one costs more. Because everything is built on the same standards, every brand's gear works with every character and every other brand, so each new item multiplies instead of adding (Chapter 23).
Missions are generated from templates (rescue, recon, delivery, infiltration, sabotage, chase and escape, bunkership against bunkership) and chained across a turn-based grid map of the region. Opponents come from AI archetypes based on the seven deadly sins and virtues, which shape their designs and tactics. Modders can add to all of it.
Structure, and the wall#
The first structure I had was Cortex Command's own: factions fighting over resources on fair, balanced maps, red against blue. Checked against the purpose, it was exactly the wall from my notes. Every match funnels into a competition of elimination, and then resets. Finite, full of friction, and none of it counts.
The way through was the service frame from Chapter 24. The player is an agent of a large administration agency, clearing threats from a galaxy. That's the infinite overarching goal. When a galaxy is secure, a small pioneer team moves on to the next one, which has quirks of its own. The local goals are missions on a bounty board: accept them, save them for later or dismiss them. Nothing is forced.
- Progress never goes backwards. A victory advances the galaxy; a failure only delays it, and someone else in the agency picks up the slack. You can't lose the game or ruin it.
- The fleet persists. Ships and squads are built from your blueprints and wait in a huge hangar, where you name them and keep a journal of their operations. They can be lost. You can't.
- The friction moves out. The slow economy lives in separate, peaceful regions, where you first mine and then restore the land to life, shipping supplies to the front. Combat regions are about action.
- Abundance from the start. You begin with more than you need, and the hangar holds default ships for at least ten failed campaigns in a row. What you learn isn't scraping by; it's that you can't brute-force every problem.
- A memento. Each finished galaxy produces a unique generated artwork, a badge of that job that feels personal (Chapter 26).
The factions stayed, but not as red against blue. Rival factions are run by AI commanders whose styles come from the seven deadly sins and their opposite virtues, and each style has its strengths and a weakness to find. A proud commander builds symmetrical, perfect bases with elite units, overspends on looks, and does everything by the book, so you can outsmart their outsmarting: set a trap, and another one next to it. A greedy commander decks out the core of their base to insane levels, but sends attack squads out half-equipped, throws away cannon fodder, leaves the outer defenses thin, and gets distracted by small prizes. You meet a real variety of opponents instead of one AI with a difficulty slider, and when you lose, they regroup and reshuffle, so a second attempt is never a save-load repeat.
Around the factions live the elements that belong to nobody: wildlife, bandits, rogue machines, independents, sometimes space monsters, turning up mid-battle as hazards or opportunities. Up to four factions can share a region, allied or betraying each other, each chasing its own objectives, trying not to be bothered by the others, or trying to survive someone hunting them. It's less a team fight and more an ecosystem, and much of the drama comes from what everyone else is doing.
Basing the opponents on sins and virtues also settled a worry. In my notes I caught myself writing sneering villains, and saw the risk: players would see real people in them, and the game would rehearse contempt for those people for hours. Behaviors that anyone can fall into don't point at any real group, so the opponents stay fictional. Handle With Care explains why that matters.
The first build#
This one is different from walkthrough 1. The first build isn't one small version of the game but a series of small games, each a piece of the dream, each barebones but complete enough to release on its own:
- A "break the targets" run: one sluggish physics character, one gun, a randomized level, and confetti at the exit.
- A grid tactics game with three rock-paper-scissors units racing for the enemy core.
- A star map run of branching choices and limited resources.
- A loadout maker and a bunkership designer, both built around fulfilling clients' orders.
- Portrait, emblem and galaxy generators. The galaxy one later becomes the memento.
Each one is a proving ground for one system and the standards under it (Chapter 28). Then they grow, and get combined into the full game, the way a game like Terraria grew from a solid foundation. It's the same principle as before, the smallest complete thing first, applied to a design too big for a single first step.
And it doesn't have to be built alone. The same standards that make every brand compatible also make it possible for other creators to add brands of their own, and to be paid for them (Chapter 30).
The pattern#
Three very different projects: a physics toy, a communication tool and a galaxy-sized tactics game. The method was the same each time.
- Start from the inspiration, and find the feelings on both sides of it.
- Translate them into needs, and the needs into a purpose.
- Choose the medium the purpose calls for, and decide honestly: game or tool.
- Take inventory: the technology, the human, the resources.
- Build foundations and forces before content.
- Make content that multiplies, inside a structure that doesn't have to end, when the purpose calls for it.
- Maximize the scope on paper, and build the smallest complete version first.
- Carry the purpose out into everything around the game.
- At every single decision along the way: does this serve the purpose?
That's the Holy Grail, in practice.
Reactorcore
Game Design Technology: The Holy Grail of Fun