It is week nine. Your programmer wants to add crafting, because the materials are already dropping and "it's basically free." Your artist thinks the game needs a hub town. You have a nagging feeling that both are wrong, but the only argument you can make out loud is "I don't know, it doesn't feel like our game." So the crafting goes in. Four weeks later you cut it, having spent four weeks.
Design pillars exist to make that argument sayable in ten seconds. Most teams write them, pin them to a wall, and never use them again — because what they wrote were compliments, not constraints.
A pillar is a constraint, not a compliment
Here are three "pillars" of the kind that turn up in indie design documents everywhere:
- Fun, fast-paced combat
- A rich, immersive world
- Meaningful player choice
Every one is unfalsifiable. Nobody on the team was going to argue for boring combat or meaningless choice. A statement that no feature can fail is not a filter; it is a mission statement with extra steps.
Compare those with constraints that actually have teeth:
- The player always knows what happens next turn. (Into the Breach shows every enemy's exact attack before you move. That single rule kills fog of war, kills to-hit percentages, kills hidden spawns.)
- Death ends the run and advances the story. (Hades makes dying narratively productive, which forbids save-scumming, forbids mid-run checkpoints, and requires writers to budget dialogue for repeat deaths.)
- Light and sound are the only detection channels. (The classic Thief stealth model. No magic awareness cones bolted on later, no "the guard just knows.")
Each of those sentences deletes something. That is the whole job.
The three tests
Before a pillar goes in your document, run it through these:
| Test | Question | Fails if |
|---|---|---|
| Cut test | Name two features this pillar forbids. | You can't name any, or you name only things nobody wanted. |
| Conflict test | Does it push against another pillar? | All pillars point the same direction — then you have one pillar written three ways. |
| Observability test | Could a playtester, with no document, tell whether you honoured it? | It describes an intention inside your head rather than something on screen. |
The conflict test surprises people. Good pillar sets are in tension: "every run is under 25 minutes" versus "every system is deep enough to master" will fight each other constantly, and that fight is where your design decisions actually live. A pillar set with no internal tension gives you no information, because it never has to choose.
A 90-minute workshop to write them
You do not need an offsite. You need everyone who will build the thing, one timer, and a rule that nobody writes an adjective.
0–15 min — List the moments. Everyone writes three to five specific moments they want a player to have. Not qualities; moments. "The player realises the tutorial boss was teaching them the parry window." "The player screenshots their base and sends it to a friend." Specificity is the whole exercise.
15–35 min — Cluster. Group the moments that depend on the same underlying property. Usually four to six clusters appear, and two of them are the same cluster.
35–60 min — Draft one sentence per cluster. Present tense, about the game or the player, no adjectives. "The player can always see the whole battlefield." "Every item is findable again." "Combat is read-and-react, never reflex."
60–80 min — Apply the three tests. Any pillar that fails the cut test gets rewritten or dropped. Out loud, for each pillar: "This forbids ___ and ___."
80–90 min — Rank them. Three to five, in priority order. The order is the deliverable: when two pillars collide at 2am during a milestone crunch, the ranking decides, not the loudest person in the channel.
Three pillars is usually right for a small team. Five is the ceiling. Seven means you have a feature list.
Making them operational
A pillar nobody consults is decoration. Three habits turn them into a working tool.
1. Attach pillars to features at proposal time. When a feature enters your backlog, it names the pillar it serves and the pillars it strains. A crafting system might serve every item is findable again while straining every run is under 25 minutes. Writing that down converts a vibes argument into a trade you can price. In GameDesignerX this is a natural fit for the idea log and mechanics modules — the pillar reference lives on the entry, so the justification travels with the feature instead of dying in a chat thread.
2. Keep a pillar ledger. One table, appended to whenever a pillar settles an argument:
| Date | Decision | Pillar invoked | Outcome |
|---|---|---|---|
| Wk 9 | Cut crafting | Runs stay under 25 min | Materials repurposed as run currency |
| Wk 11 | Hub town → single vendor screen | Death ends the run | Saved ~3 weeks of art |
| Wk 14 | Added enemy intent icons | Player sees next turn | Playtest confusion dropped |
The ledger does two jobs. It proves the pillars are load-bearing — if a quarter goes by with no entries, your pillars are wallpaper. And it stops the same argument being re-litigated in month five by someone who joined in month four. This is exactly what a decision log is for; the pillar is just the reason column.
3. Open playtest debriefs with the pillars. Instead of "what did you think?", ask your own team: for each pillar, what did we see in the session that confirms or contradicts it? A pillar that says the player always knows what happens next turn turns into a specific observation — did they ever get hit by something they could not have seen? That is a yes/no, and it goes in the ledger.
When to break one
Pillars are not sacred. They are hypotheses about what makes your game itself, and playtests can falsify them.
Break a pillar deliberately, not quietly. The honest version is a short entry: we are revising pillar 2 because in six sessions players never used the information it protects. Then rewrite the sentence, re-rank, and re-check features already approved under the old wording — usually one or two of them no longer have a justification and should go back to the backlog.
The failure mode to watch for is erosion: nobody formally changes a pillar, but each sprint adds one small exception. Six exceptions later the rule is gone and nobody remembers deciding. The ledger is the defence. If an exception is not written down, it did not happen.
Checklist
Before you call your pillars done:
- Three to five pillars, ranked in priority order
- Each is one sentence, present tense, no adjectives
- Each names two features it forbids
- At least one pair is in genuine tension
- A playtester could judge each one without reading your document
- They live where features are proposed, not in a slide deck
- A ledger exists, and it has at least one entry per month of production
Teams that do this ship smaller games that feel more deliberate. Teams that do not ship the average of every idea anyone had. The four weeks you save on the crafting system you never built are the cheapest four weeks you will ever find.