Game Design Document Generator

How to write a game design document

Six steps through 14 fields in 8 sections. The order is the point: each step makes the next one answerable.

1. 1

   Write the elevator pitch before anything else

   One or two sentences that name the genre, the hook, and what the player actually does. If you cannot write it, the design is not ready to document — and everything downstream, from art direction to scope, is guesswork. Ashen Depths, the worked example on this page, is "explore a living cavern that rewrites itself as you reclaim lost abilities": genre, hook and verb in one line.

2. 2

   Start from the template closest to your genre

   Ten templates — platformer, metroidvania, top-down RPG, visual novel, puzzle, survival, roguelike, idle, city builder and FPS — prefill the fields with the questions that genre actually has to answer. A roguelike document needs a run-length and meta-progression answer that a visual novel does not. Starting from the right one saves you from writing a generic document that avoids the hard questions.

3. 3

   Fill the core loop before the story

   The core loop is the sentence that describes what the player repeats: explore, fight, unlock, backtrack, discover. Narrative, art and monetization all hang off it, and a document that describes a world in detail without naming the loop is a pitch, not a design document. The builder puts Core Concept and Gameplay first for that reason.

4. 4

   Let the progress meter tell you what you are avoiding

   Each section shows how many of its fields are filled and roughly how long it takes to write. The sections people leave empty are usually the ones the design has not solved — monetization and release plan most often. An empty section is useful information: it marks the decision you still owe, rather than hiding it behind prose.

5. 5

   Export the Markdown and put it in your repository

   Download gives you a .md file with a predictable heading structure, so it renders in GitHub, GitLab, Obsidian, Notion or anything else that reads Markdown. Committing it next to your project means the design document is diffable, reviewable in a pull request, and versioned with the build it describes — which is the difference between a document that stays current and one that is abandoned after week two.

6. 6

   Paste it back in when the design changes

   The builder parses Markdown as well as producing it. Paste an exported document back into the import box and it repopulates the fields, so the tool is not a one-way export: you can keep editing in the structured view months later without retyping anything, and the file in your repository stays the single source of truth.

What belongs in each section

The 8 sections the builder walks you through, and the answer that actually earns its place in each.

Core ConceptTitle · Elevator pitch · Genre · Target audience

The part anyone reads first and the only part some people read at all. Target audience is the field most often filled with a non-answer: "everyone who likes indie games" tells you nothing, while "players who finished Hollow Knight and want something shorter" tells you the length, the difficulty and the storefront tags.

GameplayCore loop · Key mechanics

The loop is the repeated verb sequence; the mechanics are the systems that make it interesting the tenth time. Keep mechanics to the ones a player would notice — an inventory is a mechanic, a save system is a technical requirement.

Art DirectionVisual style · Sound & music

Written for whoever makes the assets, so name references and constraints rather than moods. "16×16 tiles, four-colour ramp per biome, no outlines" is directable. "Atmospheric and moody" is not, and will be interpreted differently by every person who reads it.

NarrativeStory synopsis · Main characters

A synopsis, not a script. What the player learns, in what order, and what changes because of it. If your game is mechanically driven this section can be short — a two-line premise is a legitimate answer, and better than three pages of lore nobody will implement.

ProgressionProgression systems

How the player gets stronger or gains access, and what paces it. This is where a metroidvania names its ability gates and an RPG names its level curve. Vague progression is the most common reason a mid-project scope estimate turns out to be wrong.

MonetizationBusiness model

Premium, free-to-play, demo-plus-paid, or explicitly none. "None, this is a portfolio project" is a complete and useful answer. Leaving it blank is what causes the awkward conversation four months in.

Technical RequirementsEngine, platforms & constraints

Engine, target platforms, input model and the constraints that follow from them. Deciding controller-first versus mouse-first here, rather than at the end, saves a UI rewrite; so does naming the minimum spec before you build the lighting.

Release PlanMilestones & scope

Vertical slice, alpha, beta, launch, and what is explicitly out of scope. The out-of-scope list is the most valuable line in the document: it is the one you point at when someone proposes a feature in month five.

Keeping the document useful

10 genre templates, Markdown in and out, and a deliberately small field count.

Why Markdown rather than a wiki

A Markdown file lives in the repository next to the code it describes. It diffs, it reviews in a pull request, and it branches with the feature it documents. A wiki page drifts from the build because nothing forces the two to move together, which is how design documents quietly become historical records.

It is saved in your browser, not on our server

The document autosaves to your browser's local storage as you type, so a refresh or a closed tab does not lose it. Nothing is uploaded and there is no account. That also means it is on one browser on one machine — export the Markdown for anything you need to keep, share or back up.

Short is a feature

Fourteen fields across eight sections is deliberately small. A design document that takes a week to write gets read once; one that fits on a few screens gets read before every milestone. If a section needs more depth, link out to it from the document rather than growing the document.

Where this fits in the pipeline

• Godot 4 2D Pipeline

  What to build once the design document exists, in the order that keeps rework down.

• 2D Procedural Level Generator

  Turn the level section of the document into a layout you can walk through.

• RPG Economy / XP Balancer

  Pressure-test the progression curve the document commits you to.

• 2D Game Dev Lab

  Every tool in the pipeline in running order — layout, tiles, collision, sprites, audio, economy.