Do You Need a Game Design Document? A History

I've held design documents from the early commercial game era. Not many survive. The ones that do live in private collections, university archives, and—more often than anyone in the industry likes to admit—nowhere at all. When a studio shuttered in 1994 or 2002 or 2011, the documents usually went with it. Box of floppy disks in a dumpster. A folder on a server no one kept paying for. The institutional knowledge of how a game got decided—what it was supposed to be before the compromises and the crunch and the publisher mandates—just gone.

That's the context I bring to Imphenzia's recent video on game design documents, which is genuinely useful and aimed squarely at the solo indie developer trying to ship something. His core argument: most people either skip documentation entirely or write a hundred-page monster that kills their momentum, and neither extreme serves them. A single-page GDD is the practical middle ground. "Game design documents aren't just homework," he says. "They're your anti-scope creep shield."

He's not wrong. But the history of this practice is longer and stranger than the indie dev conversation tends to acknowledge, and it changes what's at stake in the question.

What Documentation Looked Like Before "Indie" Was a Category

Before Steam, before itch.io, before a solo developer could reach a global audience from a spare bedroom, game design documentation was almost entirely an internal corporate artifact. It wasn't a tool for personal focus—it was a deliverable, a contract between the design team and the production team and, eventually, the publisher. The documents that have been recovered from studios like Origin Systems, Lucasfilm Games, and early Bullfrog Productions are remarkable objects: dense, idiosyncratic, full of crossed-out mechanics and handwritten margin notes that tell you more about how a game got made than any postmortem ever could.

What those documents almost never had was a one-sentence pitch. They assumed an audience of colleagues who already knew what the game was. The formalization we now associate with GDD structure—core actions, mechanics, systems, pitch—is a retrofit, a pedagogical scaffold built after the fact to help new developers think clearly. Marc LeBlanc and colleagues introduced the MDA (Mechanics, Dynamics, Aesthetics) framework in 2004 as a way to teach and analyze game design; Jesse Schell's The Art of Game Design, which Imphenzia cites for the definition of game design as "deciding what a game should be," synthesizes frameworks like this rather than originating the hierarchy. The vocabulary is newer than it feels.

That matters because it means the one-pager Imphenzia is advocating for is a contemporary invention solving a contemporary problem. The early commercial era didn't have indie developers with scope creep issues—it had underfunded studios with milestone panic and publishers who changed requirements mid-development. The documentation problems were different. In some ways, they were worse. And in the cases where detailed design documents did exist and did survive, they've proven to be irreplaceable.

The Preservation Angle That Nobody's Talking About

The reason GDDs matter to me in ways they don't to most game dev YouTubers is that I've seen what happens when they don't exist or don't survive. Researchers trying to reconstruct the development history of games from the 8- and 16-bit era are often working entirely from interviews, shipping code, and whatever design notes developers kept in personal files. The Lucky Ones. For every designer who kept a binder of notes that a historian later photographed, there are a dozen games whose design intentions are simply unknowable now.

A GDD, even a one-pager, is a primary source. It's evidence of intent. It records what a game was trying to be before the reality of development pushed it somewhere else. From a preservation standpoint, the distance between "what was planned" and "what shipped" is often the most interesting story a game has to tell. And you can only tell that story if the document survived.

Imphenzia describes how his game Line War—which he says originated as a board game he'd been developing for fifteen years before converting into a digital GDD and eventually shipping after four years of development—saw its GDD become less relevant over time as the project evolved. That's a completely normal development trajectory. But it's also a description of exactly the kind of documentary drift that makes historical research so difficult. The document that captured the original intent became a historical artifact the moment the game started changing—and whether it was preserved or discarded matters enormously to anyone who might want to understand Line War's design history a decade from now.

The Tension Imphenzia Doesn't Quite Name

The most interesting tension in the video isn't whether to write a GDD. It's between two different theories of what a GDD is for.

Theory one: a GDD is a constraint device. It keeps you focused, prevents scope creep, holds you accountable to an original vision. This is Imphenzia's primary framing, and it's the one most indie dev discourse defaults to.

Theory two: a GDD is a record of thinking. Its value isn't just prospective (keeping you on track) but retrospective (preserving how a game got decided). On this theory, the document that gets ignored or superseded partway through development isn't a failed document—it's evidence.

These two theories aren't in conflict, but they have different implications. If you believe primarily in theory one, then a document that becomes irrelevant is just overhead. If you believe in both, then you preserve the old versions rather than overwriting them, and you treat the record of change as valuable.

The preservation community operates on theory two, necessarily. But I don't think it's irrelevant to working developers either. Imphenzia's confession that he "wasted years focusing 100% on technical game development, making cool explosions, but zero fun and retention" is the kind of insight that only becomes legible in retrospect—and the document that might have named that problem at the time is exactly what a one-pager is supposed to create.

The game that got found through what looked like scope creep, rather than lost to it, is always a more complicated story. Spelunky started as an experiment in procedural generation; the roguelite structure that made it iconic wasn't in any original brief. Katamari Damacy famously had a pitch that centered on a feeling, not a mechanic—"make someone feel like they've become big." These aren't arguments against planning. They're reminders that the constraint and the discovery have to coexist, and the document is only as useful as the developer's ability to tell the difference between productive drift and disintegration.

What the One-Pager Actually Does Well

None of this is a case against Imphenzia's central recommendation. A one-page GDD that forces you to articulate your core actions, your mechanics, your systems, and—critically—your one-sentence pitch, is doing real intellectual work. The pitch requirement in particular is underrated. "You have to explain the game in one sentence that inspires people to play it," he says. "This will be your first line in the description of your Steam page, too. So it's not just a shelf warmer. It will be put to the test."

That's a genuine discipline. It's also, if you keep the document, a historical artifact the moment you write it. The pitch for what you thought you were making on day ninety of development is different from the pitch on day nine hundred. Saving both versions is free. The information value compounds over time.

He describes a spectrum from no document to a hundred-page beast, with the one-pager as the sweet spot for solo indie developers and small teams. That's a reasonable map of the territory. His own case studies—Unfair Rampage, which he says started under the working title Chrono Crusader before evolving through a brief and then a one-pager; Ultranova, still in development with a hundred-plus-page document and a separate single-page overview—illustrate that the right document type is context-dependent and changes as projects mature.

The one-page format won't save a game that doesn't have design yet. But it will, reliably, force the question. And the question—what is this game supposed to be?—is the one that every abandoned project, from the bedroom dev's half-built prototype to the studio's canceled AAA release, failed to answer clearly enough.

I just think the document deserves to outlive the development cycle. Not because you'll need it—but because someone else might.

Sarah O'Brien is Buzzrag's Retro Gaming and Preservation Correspondent.