Last time, this side-series covered the concept document — the pitch-level part of a game design document. If you haven't read that one, it's worth starting there, since everything below builds on it. This time, we're covering everything the concept document leaves out: the design document, the technical document, and a handful of questions that keep coming up about how a GDD actually works in practice.

The Design Document: Almost Everything You'll Actually Build

Where the concept document stays broad enough for a stranger to understand in a few minutes, the design document goes deep into nearly everything the game will actually contain. Depending on your game, this list shifts around, but it usually covers most of the following: menus and UI, core mechanics, the game world, story, characters, levels (main and side), player controls, progression and upgrade systems, in-game economy and purchasing, sound and music, atmosphere, AI, reward systems, combat systems, resource gathering, and camera direction.

You don't need to specify all of these to the same depth. Some of them — camera behavior, atmosphere, anything central to how the game actually feels — deserve real detail here, spelled out clearly enough that anyone reading knows exactly what's intended. Others, like the visual design of a menu or the exact texture of the soundtrack, work better as a clear goal and a set of constraints, with the actual execution left to whoever owns that discipline. You review what they bring back against what the document says you're going for, not against your own mockup of what you'd have made yourself.

The Technical Document: Where Ambition Meets Hardware

The piece that's easy to forget entirely is the technical side: the document that pins down what hardware and software the game actually has to run on, and what that means for every other decision. It's common for mobile games, for instance, to set a baseline requirement like a minimum of 1GB of RAM, and then tune graphics, texture resolution, and level of detail to fit under that ceiling rather than the other way around. Reaching that number isn't arbitrary either — it usually comes out of a real analysis of target frame rate, detail level, and who your actual player base is likely to be.

Teams under real optimization pressure go further and put hard numbers on individual assets: a character model for a high-detail PC game might get capped at 30 to 40 megabytes of graphics memory, or the same limit gets expressed as a polygon budget instead. The specific method matters less than having an actual line written down somewhere, instead of everyone guessing at what counts as "too much" for their own piece of the game. Naughty Dog's games are a good reference point here — few studios have squeezed as much visual fidelity out of hardware that, on paper, shouldn't have supported it, and that comes from exactly this kind of discipline, not from better hardware.

It's worth remembering that a game is not just its highest-fidelity character models. Spend your hardware budget on those and starve everything else, and you'll notice the trade-off everywhere else in the game. The rest of the technical document usually covers the tools and software each discipline uses, expected output formats and quality, animation frame counts, and similar production standards — plus, often, a note on which optimization shortcuts are explicitly allowed for a given task, so nobody wastes time second-guessing whether a technique is acceptable. Optimization itself is a deep enough topic that it deserves its own study in whatever area of development you end up specializing in — this is just enough to know it belongs in the document at all.

Questions People Always Ask

Does a GDD have to be one single file? No. You're free to split it into several documents — plenty of teams keep separate files for specific systems — but try not to let that turn into clutter. A design document that's scattered across a dozen loosely connected files is much harder to maintain and much harder to hand to someone new.

Is there a fixed standard for writing one? No, and there never really has been. What experience does suggest is a rough minimum: the concept, design, and technical areas covered so far across this pair of articles. Some teams add a fourth section specifically for testing plans and a step-by-step QA process, but the three above are the ones every serious document ends up needing in some form.

Is a GDD unchangeable? Does it kill the team's creativity? The core concept — the ideas locked in by the end of pre-production — rarely changes once production starts, because changing it usually means reopening pre-production and eating costs a team already scaled up for production can't easily absorb. But everything about how those concepts actually get built stays wide open. Say the document specifies that a character's abilities need to be visible on screen at all times, along with roughly how much screen space that's allowed to take up. The person responsible for the UI is still completely free to design however they want within that constraint, and team leads can approve it or ask for another pass. Nobody on a healthy team is just executing someone else's orders — they're designing inside boundaries someone else defined. Adjusting the number of levels or reworking a combat system is a normal, expected part of that process; rewriting the story or overhauling the game's whole atmosphere partway through production is not, for exactly the cost reasons above.

What's the best way to actually learn to write one? Write one for a real project and watch where it fails you. Reading about design documents only gets you so far — you find out what's actually missing, and how far your stated goals hold up against reality, once you're building against your own document and running into its gaps yourself.

That closes out this detour into the game design document. From here, this series goes back to where the last article left off: actually opening an engine and building your first game.