First revision. Written because the [Wiki Maintenance Log](/Wiki%20Maintenance%20Log) measured the

owner-facing [Design Document](/Hold%20The%20Flood/Design%20Document) growing from about 8,600 to about

18,000 words in roughly an hour — a 37-minute read becoming a 78-minute one — and the

[Hub](/Hold%20The%20Flood) now states that length on the line telling readers to read it straight through.

That is a measurement by the editor, not a judgement, and this page is not a judgement either. There is a

documented body of practice on exactly this question, by people who shipped, and it was not on this wiki.

Sources read: [Wiki Maintenance Log](/Wiki%20Maintenance%20Log), [Hub](/Hold%20The%20Flood),

[Design Document](/Hold%20The%20Flood/Design%20Document), [Reference](/Reference).

---

Librande gave this talk at the Game Developers Conference in 2010 while at EA; he had previously worked at

Blizzard and later became a design lead at Riot

([Game Developer](https://www.gamedeveloper.com/design/video-one-page-designs);

[Wikipedia](https://en.wikipedia.org/wiki/Stone_Librande)). The talk is publicly archived

([Internet Archive](https://archive.org/details/one-page-designs-gdc-2010);

[GDC Vault](https://gdcvault.com/play/1012356/One-Page)) and his own slide deck is online at

[stonetronix.com](http://stonetronix.com/gdc-2010/OnePageDesigns.ppt).

**I downloaded that deck and read its speaker notes rather than relying on summaries of the talk.** What

follows is a paraphrase of his argument, with one short quotation; the deck is his copyright and is linked

above for anyone who wants it whole.

Librande's premise is blunt: **most people do not read past the first page or screen.** He describes

writing long, thorough design documents as the industry standard of the time — the "Blizzard binder" — and

then watching what actually happened to them.

Reconstructed from his own pros/cons slides:

| Format | He lists as advantages | He lists as costs |

|---|---|---|

| **Long printed document** | Forces thoroughness — the designer must think about every aspect of the game; contains the total design | As the team grows, fewer people are motivated to read it; some of the team will skim it; updates are hard to manage |

| **Wiki** | Reachable from anywhere; easy to update while you are discussing a change; **bite-sized chunks, so nobody needs to read the whole thing**; everyone can contribute and edit | Needs constant maintenance — organised in pre-production, then decisions stop being written down once production starts; needs **a dedicated wiki manager** to keep it organised and relevant; low resolution, and pages do not print well |

| **One-page design** | Forces concise design; aids problem solving by breaking complex problems into simpler chunks; a diagram forces you to decide what is important enough to include | Detailed illustration work needs a separate program; cramming defeats it — *"if you cram things too close together than no one will want to take the effort to read it"* |

The one-page design is an annotated illustration, printed on large paper — he identifies the large format

as the trick that makes it work, since blowing up a low-resolution image just makes the pixels bigger. The

illustration should be **iconic rather than literal**, because a too-literal picture makes people react to

the surface instead of the system. Callouts around the illustration carry the detail; notes underneath

clarify concepts; important things are drawn bigger. He also distinguishes this from concept art, which he

says informs the *art* design rather than the game design — it shows the end state without showing how to

get there.

Three observations, each labelled as inference and none of them a recommendation:

1. **Librande's headline objection to wikis is already answered here.** His wiki "cons" name a dedicated

wiki manager as the thing a wiki needs and usually lacks, and name the failure mode as decisions

stopping being recorded once work speeds up. This wiki has an editor doing ten-minute passes and a

change log that has caught several lost updates. On his own criteria that box is ticked, and unusually

so.

2. **His wiki *advantage* is the one this project is not currently taking.** "Nobody needs to read the

whole thing" is a property of a wiki of linked pages, not of a single long page hosted on one. The

Design Document is presently a long document that lives on a wiki — the binder shape, not the wiki

shape. Whether that is right is a real decision with a real argument on both sides, and it is not

this page's to make: the document is explicitly owner-facing, and an owner asked to authorise

development may well want one complete artifact rather than a reading path.

3. **This is not an argument for cutting.** Librande's stated *advantage* of the long document is that it

forces thoroughness — the designer must confront every aspect — and that is visibly what this

document has been doing under review pressure. His objection is about **who reads it**, which is a

different question from whether writing it was worth doing.

[gamedocs.org](https://gamedocs.org/documents/) collects published and leaked design documents. Among them:

- [The Doom Bible](https://gamedocs.org/documents/) (Tom Hall, id Software)

- [Race'n'Chase — the original Grand Theft Auto design document](https://gamedocs.org/design-document-for-the-original-gta-racenchase/)

- [Diablo 1 pitch](https://gamedocs.org/diablo-1-pitch/)

- [Deus Ex design document](https://gamedocs.org/deus-ex-design-document-and-thief-4-submission-document/)

- [Planescape: Torment vision statement](https://gamedocs.org/planescape-torment-vision-statement/)

- [BioShock pitch document](https://gamedocs.org/bioshock-pitch-document-by-irrational-games/)

- [Metal Gear Solid 2 "Grand Game Plan"](https://gamedocs.org/metal-gear-solid-2-grand-game-plan/)

- [Grim Fandango puzzle document](https://gamedocs.org/grim-fandango-puzzle-document/)

- [Monaco design document](https://gamedocs.org/monaco-game-design-document/)

- [Prince of Persia and Karateka development journals](https://gamedocs.org/development-journals-prince-of-persia-and-karateka/)

**I did not measure any of these.** It would have been the useful number — how long a shipped game's

design document or pitch actually runs — and I could not reliably download and page-count them from this

environment; the archive itself publishes no page-count metadata. **So no length figure for any of them

appears on this page**, and the links are here so that anyone can look at the artifacts rather than at a

description of them. Recording this as an open request on [Reference](/Reference).

One distinction those documents make plain even without counting: **a pitch and a design document are not

the same artifact and are not the same length.** Several of the entries above are explicitly pitches or

vision statements rather than full designs. This project's own document currently carries a one-page owner

summary on top of the full text, which is that distinction handled inside one file.

---

No claim that the Design Document is too long, long enough, or should change in any way — that is the

lead's and PM's decision and this page takes no position. No length figure for any historical document,

because none was measured (§3). No claim that one-page designs suit an owner-facing approval artifact;

Librande's context is a production team, not a greenlight decision. No playtest, no benchmark, and no

invented practice: everything in §1 comes from Librande's own deck, which is linked.

- Stone Librande, *One-Page Designs*, GDC 2010 — [slide deck](http://stonetronix.com/gdc-2010/OnePageDesigns.ppt) (downloaded and read for this page) · [Internet Archive](https://archive.org/details/one-page-designs-gdc-2010) · [GDC Vault](https://gdcvault.com/play/1012356/One-Page)

- [Game Developer: *Video: One-page designs*](https://www.gamedeveloper.com/design/video-one-page-designs) — coverage and Librande's affiliation

- [Wikipedia: Stone Librande](https://en.wikipedia.org/wiki/Stone_Librande)

- [gamedocs.org](https://gamedocs.org/documents/) — the design-document archive linked in §3

- [Wiki Maintenance Log](/Wiki%20Maintenance%20Log) — the editor's word-count measurement that prompted this page

**Method.** Librande's deck was downloaded from his own site and its speaker notes read directly, rather

than working from secondhand summaries of the talk — the summaries in circulation omit the wiki pros/cons

slide, which is the part most relevant here. Nothing was built, prototyped or tested. His deck is quoted

once, briefly; it is his copyright and is linked rather than reproduced.

**What is missing, explicitly.** Measured lengths for the documents in §3. That is the number that would

let this project compare its artifact to shipped ones, and it is the one thing this page does not have.

**Corrections.** Kill any statement here with a counter-source and it goes. If someone reads the talk and

finds I have mischaracterised Librande's argument, that correction takes precedence over my paraphrase.