How To Write Design Docs

The Three-Document Order: Setting, Story, Systems

Tim always creates design documents in the same order: Setting, then Story, then Systems. The order matters because each document builds on the previous one:

• Setting defines the space the game inhabits
• Story describes the high-level experience every player will go through
• Systems create mechanics that support what the first two documents established

If your system mechanics are completely disconnected from your setting or story, you probably haven't made good system mechanics.

Setting: The Elevator Pitch

The setting document is often the first thing a publisher sees. Tim's guidelines:

• Describable in a sentence or two (the elevator pitch)
• Should be evocative — make people interested immediately
• Must be easy to place stories and quests within
• Avoid settings that are too authoritarian or restrictive — players need room for agency
• Follow the formula: "Here's something easy to explain... but there's a twist"

The twist is what makes it original, and exploring the implications of that twist generates the setting's richness.

Fallout example: Post-apocalyptic setting, but 1950s-inspired. Leonard Boyarsky's idea of the retro-futuristic aesthetic was itself inspirational — the 1950s already predicted radiation, mutations, monsters, rogue robots, and roving gangs. The setting practically wrote itself.

Arcanum example: Standard Lord of the Rings fantasy world, but an industrial revolution happened. Every fantasy game seems stuck in the 14th century — what if technology kept advancing and started conflicting with magic?

Story: Let Players Be Themselves

The story should make sense within the setting, let players explore it, and — critically for Tim — let players create whatever character they want. Tim is emphatic: if you assign a character, name them, or define their role, you've already lost him as a player.

Fallout example: The Vault had been sealed, so neither the dweller nor the player knew what was outside. The water chip was a deliberate McGuffin to get you out. The genius detail: the Vault dweller was selected by lottery. Nobody wanted to go. This justified any character build — even a low-intelligence character ("they probably gave this guy two weeks and started planning another lottery").

Arcanum example: You're a nobody taking an airship to a new continent looking for work. The airship gets shot down by orcs flying biplanes. You get caught up in something bigger. The game even pokes fun at the "chosen one" trope — Virgil thinks you're the chosen one, but your character thinks he's crazy.

Both games were completely open-world, letting players explore in any direction with quests and storylines waiting everywhere.

Systems: Mechanics That Reinforce Setting

System mechanics must support the setting in both tone and actual mechanics. They should reinforce what you've told the player the world is like.

Fallout: The wasteland is dangerous and unpredictable, so the game gives you combat skills, stealth skills, dialogue skills — a full toolbox. Radiation mechanics exist because of course there's radiation. Drugs exist because this setting would have them for healing, radiation, poison.

Arcanum: Spells and tech schematics reflect the setting's magic-vs-technology conflict. But the brilliance was the magic/tech meter on your character sheet. Every spell purchase pushed you toward magic; every schematic pushed you toward tech. The cultural war in the setting was literally happening on your character sheet with every build decision.

Goals on Every Page

The most important practice Tim advocates for system design docs — which he credits to Josh Sawyer from their work on Pillars of Eternity:

Every mechanic page should have explicit goals listed at the top. These goals range from high-level to specific, and they must justify why this mechanic exists in the game. Not vague goals like "let the player have fun" — specific, testable goals.

The Outer Worlds Example

High-level goal for combat: "Melee and ranged combat should feel different and offer substantially different play experiences, but neither should be significantly more powerful than the other."

Specific melee goal: "Melee combat needs to be simple and easily accessible for casual players, but have higher-skill maneuvers for advanced players."

This led to concrete design decisions:

• Melee always hits if the target is in range and arc — no hit roll. Skill determines damage.
• Ranged requires accuracy — skill determines whether you hit at all, then the weapon determines damage.
• Advanced melee techniques (power attack, sweep attack) give depth for experienced players while keeping the baseline simple.

Why Goals Matter: Two Separate Discussions

Explicit goals let teams separate two fundamentally different debates:

1. "Is this a good goal?" — a discussion about design direction
2. "Does this mechanic achieve the goal?" — a discussion about implementation

Tim found that people — designers, other team members, reviewers — constantly conflate these. Someone says "I don't like that melee weapons always hit," and without explicit goals, you can't distinguish whether they disagree with the goal (making melee and ranged feel different) or the implementation (auto-hit as the differentiator).

Teams must agree on goals first. Without that alignment, people end up making different games on the same team. Tim saw this happen at Carbine and sometimes at Obsidian — teams where people weren't working toward the same goals.

On Feedback and the Designer's Burden

Tim observes that everyone — management, players, reviewers — thinks they're a game designer. Programmers and artists don't face this:

• Nobody tells a programmer "you're obviously using quicksort, you should use insertion sort"
• Nobody hands an artist redrawn animations and says "put these in"

But everyone feels qualified to redesign game mechanics. This makes unconstructive feedback particularly damaging. Saying "I don't like that" or "that's stupid" is worthless — nobody can act on it.

Having explicit goals in system design documents transforms these interactions. Instead of "okay, thanks for that comment," you can respond: "That's how we're making the distinction between melee and ranged — how would you make that distinction?" That's a productive conversation.

Summary

Tim Cain's design document process:

1. Setting — evocative, easy to pitch, with a twist that makes it original
2. Story — makes sense in the setting, lets players create any character, gives them agency
3. Systems — mechanics that directly reinforce the setting and story
4. Goals on every page — explicit, testable goals that enable constructive debate and team alignment

Source: Tim Cain — "How To Write Design Docs"

References

• Tim Cain. YouTube video. https://www.youtube.com/watch?v=ohHLUKj3NTk