Neither of those factions appears anywhere in this game's original plan. That plan still exists, unchanged, and its second sentence reads:
Two playable races - Dwarves and Goblins - compete for domination through resource gathering, base building, and combat.
It fits on a couple of pages. Its unit table is two columns wide, one for Dwarf and one for Goblin, with seven rows for seven jobs. The game it describes is called Game Commander. The game that shipped has 9 playable factions with a roster page each, 229 units, and is called Shards of Stone: Ash and Iron.
This post is about the writing that got it from one to the other. The operational notes, the routing table and the standing instructions that keep a model productive between sessions, are a different thing entirely, and they are covered in documentation written for a machine to read.
What a faction specification looked like at the start
Alongside that plan sat 29 numbered specifications covering everything from the project skeleton to how you win. Exactly two of them describe a race, one for dwarves and one for goblins, and each is a single short page. Here is essentially all of the dwarf one that is not a heading:
Earth tones, iron grey, deep blue, gold trim. Stone and metal architecture. Organised, symmetrical buildings. Sturdy, bearded characters. A mountain-and-forge aesthetic. Miner: pickaxe, helmet, brown beard. Ironguard: heavy plate armour, shield and axe. Crossbowman: leather armour, heavy crossbow.
The acceptance criterion for the whole roster was one line: all fourteen unit types defined with correct stats. Fourteen, being two races times seven jobs. That was the entire game the project set out to build.
I want to be precise about what this does and does not show. Nothing here proves the prose was written before the code, and it is not the claim. What it shows is the shape of the target: a plan for a two-race game, and a shipped game with nine factions, naval warfare, a campaign, a dungeon crawler and a mode where you drop into a hero and play it in third person, none of which any plan mentions.
The design bible arrived a week later
The proper design documents landed together, about a week in. Three of them.
The pillars document holds five design pillars, who the game is for, and the elevator pitch. The factions document, by some distance the longest of the three, covers how each faction should feel to play and what makes it mechanically distinct. The balance document holds the counter triangle (melee beats siege, siege beats ranged, ranged beats melee) plus economy tuning, target pacing, and the known problems.
The most useful section in any of them is the shortest. The pillars document ends with a heading called "What This Game Is NOT", and under it: not a competitive esport, not a city builder, not a 4X game, not a mobile cash grab, not a Warcraft clone. Five refusals.
That section does more work than the five pillars above it. A pillar is an aspiration and a model will happily satisfy it in a direction you did not want. A refusal is a boundary. The difference shows up in what got built: "not a 4X game" is why the balance document sets a target of 15 to 25 minutes per match, and treats a game that regularly runs past 30 minutes as a bug in the damage-to-health ratio or in how fast resources run out, rather than as a long game.
Not everything came first
The hero design and the elemental system were both written up months later, at the same time as the thing they describe.
So the honest version of the practice is not "write it all down, then build it". It is that the writing and the game arrive together, and the writing is aimed at the reader who comes to it next rather than at the one who comes to it first. The elemental document opens by naming where the truth actually lives: the list of damage types, the counter table, and the single place every damage calculation passes through. A reader always knows where to check whether it is still true. That property is what the rest of this post turns on. What it specifies is the damage and armour system.
The document that reviews its own game
The faction differentiation review is the strangest and most useful thing in the folder. It is a design review of this game, written against this game, ranking all nine factions by whether their advertised signature has anything real behind it. The tiers are Rich, Moderate, Thin and Baseline, and every row has to name the thing in the running game that backs the claim, so "ratmen have a signature mechanic" resolves to corruption spreading, tunnels being dug and monsters crawling out of them, rather than to a paragraph of intent.
A ranking that names its evidence cannot be argued with by writing better prose. What that review found, and what got built off the back of it, is nine factions that actually play differently.
It has only ever been edited twice, and the second edit is the interesting half. It is the one that gave the goblins a scrap-harvesting economy and a pillage mechanic, and it ticks two of the review's own recommendations off in place at the same time. The document was never softened and it was never filed away once read. A design document that records what is still weak is worth more than one that records what is done, because the second kind is indistinguishable from marketing.
Every number in a design document is wrong eventually
Here is the failure, and it is systemic rather than incidental.
The design documents carried per-faction counts: how many spells a faction had, how many units, how many buildings. Every one of those figures was correct on the day it was typed and false within a fortnight, because the game kept growing. The goblin roster alone was filled out twice more after its count was written down: once when hero abilities were ported into re-tuned versions for ordinary units, and once when a Forge school of magic gave the War Wagon its first ability at all.
Nothing flagged any of it. A stale number in a document produces no error, no warning and no failing test. It sits there looking authoritative, and the next reader, which on this project is usually a model with no memory of having written it, treats it as current. The cost was real: briefs written from those documents carried figures that did not survive contact with the game, and sorting that out took a full reconciliation nothing else on the project had ever needed.
The fix, for every surface a reader sees, is that counts are no longer typed at all. Any number in a marketing page or in one of these posts is written as a placeholder that asks the game for the answer while the site is being built, and a placeholder the build cannot resolve stops the build rather than quietly rendering nothing. A post that hardcodes a roster size is wrong within a week. A post that asks is correct by construction.
What prose is actually good for
There is a reason writing carries more weight on this project than it would on most. Adam directs the work by reading plans and judging outcomes, not by reading code, so a design document is not a summary of the game for him. It is the interface to it. That makes "what does the balance document say" a real question with a real answer.
Beyond that, three practices survive being lifted out of this project.
Write the refusals, not only the aspirations. An aspiration leaves the direction open, and a model will cheerfully pick one Adam did not want. A refusal is a boundary, and boundaries produce numbers you can test: "not a 4X game" is where the 15 to 25 minute target came from, and a match that regularly runs past 30 minutes is therefore a bug with a suspect list rather than a matter of taste. For every aspiration in your document, write down the thing it rules out.
Reserve prose for the rules that cannot be enforced any other way. Anything that can be a type, a test or an automatic check should be one, because those are enforced and a document is not. What is left over is the part worth writing carefully. The hero document states that the player should always have a meaningful button to press. Nothing anywhere in the game enforces that, and it is nonetheless the single sentence that determined the shape of every hero in it. The balance document states that no single unit type should win the game on its own. Neither can be automated. Between them they have shaped hundreds of decisions.
Keep one document that criticises the game, and make every row name its evidence. A claim anchored to something in the running game cannot be answered with better prose, only by changing the game, which is what stops the review being quietly softened. The habit that keeps it alive is smaller than it sounds: edit the review at the same time as you satisfy part of it, ticking items off in place and leaving what is still weak visible underneath.
What prose is bad at is anything countable, and the rule that falls out of it is blunt: if a document states a number, either generate that number or delete it.
What the next document should be
The marketing pages and these posts already ask the game for their counts. The obvious next move is to give the design documents the same treatment, and there is a decent argument against it, which is that a design document full of live numbers stops being a design document and becomes a report.
The narrower and more useful version is a check that reads the small set of documents which claim a specific constant (the elemental system being the clearest case) and complains when the game disagrees. That is a much smaller job than regenerating everything, and it is the difference between prose that describes the game and prose that is checked against it.
