Design Vision

A vision doc opens with a read on the moment: what’s gone stale in the genre you’re entering, what players still love about it, what’s quietly pushing them away. You don’t need everyone to agree with the read. You need everyone to know which read the project is betting on, because every argument for the next two years traces back to it.

Then the bet, in one sentence. “This extraction shooter is about dread.” “This builder is about cozy logistics.” “This racer is about one more run.” One sentence, no commas doing extra work. Every feature that can’t explain itself in terms of that sentence is already suspect.

Close the opening with a prototype goal: the smallest playable thing that proves the bet. If the bet is dread, the first milestone is one loop that makes a playtester’s hands sweat. Small, testable, and cheap to be wrong about. A vision without a falsifiable first milestone is a mood board.

I come from music production, so I call this what a producer would: digging in the crates. Every new game is a remix of games that came before it, and pretending otherwise just means you’ll sample badly. That’s why the Kleon line sits at the top of this page. Steal like an artist, openly and on purpose.

The discipline that keeps a teardown from turning into an afternoon of just playing video games is the “looking for” list. Pick the three or four crates your idea descends from, and write the list before anything gets booted. Say you’re building a cozy survival game: you’d dig through survival crafting (pressure curves, death penalties), farming sims (the daily loop, chore cadence), and roguelites (run structure, what carries over). Each genre gets its own short list of what you’re there to study, written in advance.

Write the list first and you come back from the crates with parts. Skip it and you come back with impressions, and impressions don’t survive the first design review.

Most vision docs stop at pillars: three or four nouns on a poster that everyone nods at and nobody uses. Pillars are good at describing and bad at deciding. What the team actually needs is a set of razors: tests you run every individual design system through while it’s in development. When two designs both look right, the razor picks. That’s the difference. A pillar is a mission statement; a razor settles an argument at the whiteboard.

Razors are project-specific by nature, but they all share a shape: a value, stated as an instruction, aimed at a tradeoff you know is coming. A horror game might carry “if a change makes the dark less scary, it’s wrong, no matter what else it fixes.” A co-op game might carry “every system must be more fun with a friend than alone, or it doesn’t ship.” A cozy game might carry “nothing in this game is allowed to make the player feel late.” Three or four of these are plenty. More and they start contradicting each other, which is its own kind of information.

Notice how fast they settle things. A gorgeous lighting pass that brightens the corridors? The horror razor kills it in one sentence. A daily login streak in the cozy game? It makes players feel late, so it’s out, and nobody has to schedule a meeting about it. That’s the test of a good razor: it makes decisions in your absence.

Before the centerpiece lands, the team needs shared language, and two borrowings earn their keep. Caillois sorted play into four forms back in 1958 (competition, chance, simulation, and vertigo: agon, alea, mimicry, ilinx), which is still the fastest way to ask “what kind of fun is this, actually?” The MDA framework (mechanics produce dynamics produce aesthetics) is mostly useful here as a consensus tool: rank the aesthetics high, medium, and low as a team, and you find out early whether one of you is building a power fantasy while another is building a sport. The argument about adjectives ends, and the list goes on the wall.

Then the model itself. The Inside-Out Model is three rings. The innermost ring is the toy: the core verbs and the kit, the thing that has to be fun in an empty gray room before anything else earns the right to exist. The middle ring is the session: whatever makes one sitting feel complete, the goal that ends it and the between-rounds beat that starts the next one. The outer ring is the hobby: the reason week six exists. Mastery and competition on one side, friends, identity, and ritual on the other.

The horizontal line through the rings matters just as much. It splits every ring into lean forward (the parts that demand skill and attention) and lean back (the parts players do between heartbeats). A healthy game has something in all six zones, and a surprising number of troubled ones turn out to be missing a whole half.

Here’s why this is the keeper: the model is a scheduling tool wearing a diagram costume. It solves what we work on first, next, and later. The toy is first; if ring one isn’t fun, rings two and three are decoration. The session is next. The hobby is later, and “later” is a real commitment, because the outer ring is the easiest place to over-invest before anyone loves the toy. Tag every system in the backlog with its ring number and most of the roadmap argument evaporates.

Treat the first milestone as a gym rather than a level: a flat gray space with stations that each isolate one feel question. A station for movement. A station for each combat or interaction family. A station for the format itself, whatever pressure makes your sessions end. Every station gets the same graduation path: dummy targets, then AI, then humans. If a station can’t answer its question with gray boxes, the question isn’t about feel.

The rule for all of it is three words: fast fast fast. Use the simplest assets possible that still get the feel. Marketplace models, stock physics, programmer art. Replace assets in the gym as you go. Take the learnings from gym sessions and build test map one. And then the sentence I’d tattoo on every prototype team’s wall: what is playable on test map one is the prototype. That’s the entire anti-scope-creep program in eleven words.

Every vision has one system it can’t survive without. In a melee game it’s the swords. In an extraction shooter it’s the economy. In a builder it’s the pathfinding. In a kart racer it’s the drift. That system gets its own deep dive in the vision doc, before a single asset exists, because if it feels bad the game is dead on arrival and everything else is embalming.

The deep dive has three layers. First the core questions, argued on paper where they’re cheap: is this system the primary verb or a last-ditch tool? What’s its risk-reward shape? Does it play differently against AI than against humans? Second, the variations: lay out the family of options along clear axes (fast and short-range versus slow and heavy is the classic), so the tradeoffs are visible before they’re tuned. Third, the honest tuning plan: numbers get dialed in by playtest, to taste, with the goal that every option is viable for a skilled hand.

And one more thing belongs in a vision doc that almost nobody puts there: what you don’t know. The engine nobody on the team has shipped in. The discipline you don’t have yet. The platform certification you’ve never been through. Write it down in the doc, in bold if you have to. Declaring your constraints is part of the vision. A team can route around a known gap. An unspoken one ships bugs.