Design Document for a Game: Free Template and Example

Every design document game developers write, from a one-page jam plan to a full studio bible, answers the same question: what exactly are we building, and what are we not building? This guide covers what belongs in a game design document, how long it should be, a free template you can paste into Word or Google Docs, a worked example, and the mistakes that make most design docs useless by week three.

What is a game design document?

A game design document, usually shortened to GDD, is the written plan for a video game. It describes the game’s concept, gameplay, mechanics, story, art, audio, interface and scope in enough detail that the people building it can work from it without guessing. Wikipedia describes it as a living software design document that is revised throughout development rather than written once and filed away.

Two facts about GDDs matter more than any template:

• There is no industry standard format. Studios keep them as word processor files, online collaboration tools or wikis. Your GDD can be a Google Doc, a Notion page or a Markdown file in your repo.
• It changes constantly. A GDD often starts as a rough concept during pre-production, the planning phase before full production begins in the video game development cycle, and grows as decisions get made. On active teams it can be edited daily.

The GDD is a cousin of the software design description used in general software engineering. Both exist so that a team shares one understanding of the product. The difference is that a game also has to describe feel, pacing and fun, which are harder to pin down than a database schema. That is why good GDDs lean on examples, sketches and concrete numbers rather than adjectives.

If you are solo, the GDD’s main job is protecting you from yourself: from scope creep, from forgetting why you made a decision, and from restarting every time a shinier idea appears.

What goes in a GDD: the core sections

Most GDDs cover the same ground. Here are the sections in rough priority order. Write the top three before anything else, because they decide what the rest should say.

1. Concept

One or two sentences that describe the game, plus genre, platform and target audience. If you cannot write the concept in two sentences, you do not have one yet. Example: “A short 2D platformer where a moth carries a dying lantern through a cave. Light is your health and your map.”

2. Core loop

The core loop is the small cycle of actions the player repeats for most of the game: explore, find fuel, survive, unlock the next area. Write it as three to five verbs joined by arrows. Every feature you add later should feed this loop or be cut.

3. Mechanics and rules

The specific systems: movement, combat, resources, win and lose conditions. Use numbers wherever you can (jump height, damage, timer length). Numbers turn arguments about “feel” into something you can test and tweak.

4. Content

Lists of levels, enemies, items, characters and story beats. Keep each entry short: name, one-line purpose, and any special rule.

5. Art and audio direction

Style, resolution, palette, camera view and mood, ideally with reference images. For audio, note the music mood and the sound effects each mechanic needs. A list of required assets here saves a lot of time later.

6. UI and controls

The HUD (heads-up display: the health bar, score and other on-screen info), menus and a control map for each input device. Include accessibility notes such as remappable keys or colourblind-safe indicators.

7. Scope and timeline

What ships in version one, what is a stretch goal, and what is explicitly out. Add milestones: first playable, content complete, polish, release. If you need help estimating, our guide to how long it takes to make a video game breaks timelines down by game size.

Larger projects add monetization, marketing and technical sections (engine choice, target hardware, save system), often as separate supplemental documents linked from the main GDD.

The one-page design document game jam teams can use

For a game jam, a prototype or your first solo project, one page is enough. A one-page GDD forces you to make decisions instead of describing possibilities. Copy this template into Word, Google Docs or a text file. In Word, set each line ending in a colon as a Heading 2 style and the navigation pane gives you a clickable outline for free.

# [Game Title] - One-Page GDD (v0.1, [date])

## Concept
One or two sentences. Genre. Platform. Who it is for.

## Core loop
verb -> verb -> verb -> (repeat)

## Player goal
How you win. How you lose.

## Mechanics (with numbers)
- Movement:
- Main action:
- Resource / health:
- Fail state:

## Content for v1
- Levels:
- Enemies / obstacles:
- Items / pickups:

## Art and audio
- Style, resolution, camera:
- Asset list (sprites, tiles, music, SFX):

## Controls
Keyboard: ...   Gamepad: ...   Touch: ...

## Scope
- IN for v1:
- STRETCH:
- OUT (do not build):

## Milestones
1. First playable:
2. Content complete:
3. Polish and release:

## Open questions
- ...

Two sections in this template are easy to skip and should not be. The OUT list is where you park every good idea that is not for this version, so it stops nagging you. The open questions list makes uncertainty visible, so you can answer it with a quick prototype instead of a long debate.

Worked example: a one-page GDD for a small platformer

Here is the template filled in for a tiny game called Lantern Moth. It is the sort of plan a solo developer could finish in a few weekends.

• Concept: A short 2D side-view platformer for the browser. You are a moth carrying a lantern through a dark cave. The lantern’s light is your health, your map and your timer. For casual players who like short, atmospheric games.
• Core loop: explore → find oil → refill the lantern → reach the next exit before the light dies.
• Player goal: Reach the cave mouth at the end of level 5. You lose when the lantern hits zero.
• Mechanics: Run speed 200 pixels per second, jump velocity 380, gravity 900. Lantern starts at 100, drains 4 per second, each oil pickup refills 35. Light radius shrinks as the lantern drains.
• Content for v1: 5 levels, 2 obstacle types (dripping water that drains light, bats that knock you back), 1 pickup (oil).
• Art and audio: 32×32 pixel art, dark blue palette with warm orange light. Assets: moth with idle, run and jump animations, cave tileset, bat, oil flask. One ambient music loop; SFX for jump, pickup, hit and lantern flicker.
• Controls: Arrow keys or WASD to move, Space or Up to jump. Gamepad later.
• Scope: IN: 5 levels, title screen, restart. STRETCH: speedrun timer. OUT: story cutscenes, upgrade shop, level editor.
• Open questions: Does a shrinking light radius feel fair or frustrating? Prototype level 1 and test before building the rest.

Notice what the example does. Every mechanic has a number. The asset list is complete enough to hand to an artist or an AI tool. The OUT list kills three features before they eat a month. And the biggest risk (is the core idea fun?) is flagged as something to test first.

One page, full GDD or wiki: which format should you use?

The right size depends on team size and project length. A bloated GDD for a jam game wastes time; a one-pager for a year-long team project leaves too much unsaid.

Format	Best for	Strengths	Weaknesses
One-page GDD	Game jams, prototypes, solo first games	Fast to write, easy to keep current, forces decisions	Too thin for large content or multiple teams
Full GDD (Word or Google Docs)	Small teams on multi-month projects, pitching to partners	One file to share, works offline, familiar headings and comments	Long documents go stale; hard to find things past a few dozen pages
Wiki or linked pages	Larger teams and long projects	Each section has an owner, easy cross-linking, change history	Needs discipline; can sprawl into pages nobody visits
Markdown in the repo	Programmer-heavy teams, AI-assisted builds	Versioned alongside code, readable by coding agents	Less friendly for artists and non-technical collaborators

A practical path: start with a one-page GDD. When a single section outgrows its space (say, your enemy list hits twenty entries), move it to its own document and link it from the one-pager. The one page stays the front door; the detail lives behind it.

Turning your GDD into a playable build with WizardGenie

A GDD only matters if it turns into a game, and this is where many first-time developers stall: the plan is clear, but getting from document to playable prototype feels huge. If you build with AI, a well-written GDD is also the best prompt you can give a coding model, because it already contains the concept, rules, numbers and scope that a vague one-line prompt leaves out. That is the core idea behind vibe coding: you describe what you want and let the AI write the code, which works far better when the description is precise.

WizardGenie is the AI game engine at the heart of Sorceress. You describe the game you want and WizardGenie writes, runs and iterates on it. It runs on the web at /wizard-genie/app with nothing to install, and as a Windows desktop app with an auto-updater that adds native file access and longer agent sessions. It works with the leading AI coding models, and you can switch models with your own API key.

A workflow that suits a GDD:

1. Paste the one-pager as your first message. Ask WizardGenie to build only the first milestone (“first playable: level 1 with movement, the lantern drain and oil pickups”). Point it at the IN list and tell it to ignore STRETCH and OUT.
2. Play, then edit the GDD before the prompt. When jumping feels floaty, change the number in the document first, then ask for the change. The GDD stays the source of truth and your prompts stay consistent.
3. Ask for tuning values in one place. Request that every number from the Mechanics section lives in a single config object, so the code mirrors your document.

Here is what that looks like in practice: a small, complete Phaser 3 scene where the Lantern Moth numbers sit in one TUNING object copied from the GDD.

// Numbers copied from the GDD "Mechanics" section.
const TUNING = {
  player: { runSpeed: 200, jumpVelocity: -380 },
  lantern: { max: 100, drainPerSecond: 4, refillAmount: 35 },
  world: { gravityY: 900 }
};

class Level1 extends Phaser.Scene {
  create() {
    const moth = this.add.rectangle(100, 300, 24, 24, 0xffb347);
    this.physics.add.existing(moth);
    moth.body.setCollideWorldBounds(true);
    this.player = moth;

    this.light = TUNING.lantern.max;
    this.lightText = this.add.text(16, 16, '', { color: '#ffffff' });
    this.cursors = this.input.keyboard.createCursorKeys();
  }

  update(time, delta) {
    const body = this.player.body;

    if (this.cursors.left.isDown) body.setVelocityX(-TUNING.player.runSpeed);
    else if (this.cursors.right.isDown) body.setVelocityX(TUNING.player.runSpeed);
    else body.setVelocityX(0);

    if (this.cursors.up.isDown && body.blocked.down) {
      body.setVelocityY(TUNING.player.jumpVelocity);
    }

    this.light = Math.max(0, this.light - TUNING.lantern.drainPerSecond * delta / 1000);
    this.lightText.setText('Light: ' + Math.ceil(this.light));

    if (this.light === 0) this.scene.restart();
  }
}

new Phaser.Game({
  type: Phaser.AUTO,
  width: 800,
  height: 450,
  backgroundColor: '#0b1530',
  physics: { default: 'arcade', arcade: { gravity: { y: TUNING.world.gravityY } } },
  scene: Level1
});

When the GDD says the lantern drains too fast, you change one number in the document and one number in the code. No hunting through files.

Your GDD’s asset list also maps straight onto other Sorceress tools. The moth and bat animations are a job for Auto-Sprite v2 (Pro), which turns a generated character into game-ready 2D sprites. The cave tiles fit Tileset Forge (Pro), which turns AI art into game-ready tilesets. Music and effects come from Sound Studio, which covers AI music, SFX and voice. The tools guide shows where every tool fits, and for the wider build process see how to make a PC video game.

Common mistakes when writing a GDD

• Writing a novel before a prototype. Pages of lore and twenty planned levels mean nothing if the core loop is not fun. Write one page, build the smallest playable version, then expand the document.
• Adjectives instead of numbers. “Fast, responsive movement” cannot be built or tested. “Run speed 200, jump 380, coyote time 0.1 seconds” can.
• No OUT list. Without one, every idea sits in an implied backlog and scope grows silently. Writing “no crafting system” is a design decision as real as adding one.
• Letting it go stale. A GDD that disagrees with the build is worse than none, because people trust it. Update the document when you change the game, and put a version number and date at the top.
• Describing features without the loop. A list of mechanics is not a game. Every feature should say which part of the core loop it supports.
• Hiding it. If teammates cannot find the GDD in ten seconds, they will not use it. Pin the link in your chat, repo readme or project board.
• Copying a giant studio template. Templates built for large teams include monetization, marketing and certification sections a jam game does not need. Delete what does not apply instead of filling it with filler.

The workflow at a glance

1. Write the concept in two sentences and the core loop as a chain of verbs.
2. Fill in the one-page template, with numbers for every mechanic and a clear OUT list.
3. Flag the riskiest open question and plan a prototype to answer it.
4. Build the first milestone, using the GDD as your brief or as the prompt for WizardGenie.
5. Play, adjust the document, then adjust the game, in that order.
6. Split sections into their own documents only when they outgrow the page.
7. Keep the GDD dated and current until the game ships.

A GDD is not paperwork. It is a thinking tool that turns a fuzzy idea into a list of decisions. Keep it short, keep it honest about scope, and keep it in sync with the build, and it will save you more time than any other document in your project.