On this page
- Game Design Docs in 60 Seconds
- What a GDD Is and Who on a Game Team Reads It
- GDD vs. Pitch, Concept Document and Technical Spec
- Game Design Document Format: Sections and Length
- Game Design Document Template You Can Copy
- A Filled-in GDD Example for a Small Game
- How a GDD Changes During Game Development
- Writing a GDD Your Game Team Will Read
- GDDs in a Game Design Degree
- Using a GDD in Your Game Design Portfolio
- Which Game Jobs Write GDDs, and What They Pay
- Frequently Asked Questions
- Related Pages
- Sources
Game Design Docs in 60 Seconds
- A GDD is the plan the whole team builds from. It covers what the player does, the rules, the levels, the look and sound, and who builds what by when. A UC Irvine game course calls it a living document that commercial teams keep updating as the game is made. What a GDD Is ›
- A pitch sells the game, a GDD builds it. Cornell's game course writes its concept document for a publisher, at 2 to 3 pages. The GDD is for the team, and the technical document for programmers is a separate file the GDD links to. GDD vs. Other Documents ›
- One page on top, as long as needed below. Keep the overview to one page and put it first. A UC Irvine course asked teams for a 5 to 10 page draft and a finished document of 20 to 30 pages, and a small solo game needs far less. Format and Length ›
- Copy the free template or download it. The template has 10 sections, from the one-page overview to a change log, each with a copy button. It also downloads as a Word or Markdown file, and a filled-in example shows a finished overview. Free Template ›
- A GDD nobody updates describes a game nobody is making. Cornell moved its gameplay document out of a course wiki because no one updated it as the game changed. A dated change log, with the reason for each change, keeps the document and the build in step. Keeping It Current ›
- Designers write most of it, and everyone reads it. O*NET lists design documentation among video game designers' tasks. Game designers are counted with web and digital interface designers, whose national median pay appears in the jobs table with the other roles that write parts of a GDD. Jobs and Pay ›
Heads up The two degree courses named here that assign design documents are both electives, not required courses.
What a GDD Is and Who on a Game Team Reads It
A game design document describes a game before and while it is built. It says what the player does, what the rules are, what the levels contain, how the game should look and sound, and who is responsible for each part. Programmers build systems from it, artists make assets from it, and producers schedule from it. A good one lets someone who joins the team in month six find out what was decided and why.
It is a working file, not a pitch you write once. A computer game development course at UC Irvine tells its students that on commercial games the design document is often written over many months and treated as a "living" document, updated as the game is developed. You can read the full assignment on the UC Irvine course page. The same page says that someone who reads only the overview should be able to form an accurate picture of the game, which is the test every first page should pass.
Different readers want different parts. A producer or publisher reads the overview and the scope. A programmer reads the rules and the tuning values. An artist reads the art direction and the asset list. That is why a GDD is organized by section, so each reader can jump to the part they need, and why the overview carries the whole game on one page for anyone who reads nothing else.
The work is part of the job description. O*NET, the federal occupation database, lists among the tasks of video game designers to "document all aspects of formal game design, using mock-up screenshots, sample menu layouts, gameplay flowcharts, and other graphical devices." In other words, writing the document is design work, not paperwork that sits beside it.
ComparisonGDD vs. Pitch, Concept Document and Technical Spec
The word "design document" gets used for several different files. They differ mostly in who reads them and how long they are, and mixing them up is how a GDD turns into a sales pitch or a programming manual. Course pages from two universities draw the lines clearly.
| Document | Who reads it | What it covers |
|---|---|---|
| Pitch | A class, a publisher or a team lead | The idea in a few minutes, to win approval |
| Concept document | A publisher deciding whether to fund the game | The high concept, the player and what makes the game different |
| Game design document | The whole team | Rules, mechanics, levels, art and audio, interface, scope and schedule |
| Technical design document | Programmers | Classes, modules, program flow, engine and tools |
The pitch and the concept document sell the idea. Cornell's game architecture course says the audience for its concept document is a publisher who reads many of them and wants to get through each one fast, so it asks for a short, punchy document with the most important information first. Its concept document assignment sets a length of two to three pages.
The GDD is for the people building the game. Cornell's gameplay specification assignment states plainly that its audience is your team, and it covers objectives, mechanics and challenges in more detail than the concept document could.
The technical document is a different file with a different reader. Cornell's architecture specification focuses on software elements such as classes and program flow, while the gameplay document focuses on mechanics and challenges. The UC Irvine page notes that in commercial production the technical specifications run to hundreds of pages. A GDD should point to the technical document and name its owner, not try to contain it.
FormatGame Design Document Format: Sections and Length
There is no official game design document format, and studios, courses and solo developers all organize theirs differently. Most cover the same ground, though. The UC Irvine course page groups everything into four major parts: the overview, the game specification, the technical specification and the schedule. It describes the game specification as a rule book for the game. Our template keeps that order and splits the game specification into the sections people most often need to find on their own.
| Section | What it answers |
|---|---|
| One-page overview | Anyone who reads only this page should be able to picture the game. |
| Design pillars and non-goals | The three ideas every decision is tested against, and what you will not build. |
| Gameplay and mechanics | The rule book. A programmer should be able to build from it without guessing. |
| World, story and characters | Only as much as the game needs. A puzzle game may need a paragraph. |
| Levels and content | The list of everything the player will see, and one level described in full. |
| Art and audio direction | The look and sound in words and references, before anyone makes an asset. |
| Interface and player feedback | How the player learns what is happening without reading a manual. |
| Technical notes | Enough for the programmers to start. The full plan belongs in a separate technical document. |
| Scope, schedule and team | Who does what, by when, and what gets cut first if time runs short. |
| Open questions and change log | What is still undecided, and a record of what changed and why. |
Length follows the game. In a first-year games course at UC Irvine, teams turned in a draft of 5 to 10 pages that touched every section, then a finished document of 20 to 30 pages with a full overview, game specifications, technical specifications and a schedule. The assignment is archived by the University of Texas at Austin. A two-person weekend project may need three pages. A team project for a semester sits in that course range. The overview stays at one page however long the rest grows: the UC Irvine page sets that as a rule, and puts the overview first.
On file format, the same course page asks for one web document in a universally readable format such as HTML, PDF or Google Docs, not split into separate pages, and asks teams not to outline more than three levels deep. In practice that means a shared document or a wiki with clear headings, one page or file that people can search, and sketches, maps and flowcharts placed next to the rules they explain.
Game Design Document Template You Can Copy
This free game design document template has 10 sections. Each one opens with a line on what it is for, then the prompts to fill in. Copy one section at a time, copy the whole template, or download it as a Word or Markdown file to edit offline. Replace everything in brackets, and when a section doesn't apply to your game, keep its heading with one line saying why, so readers know it wasn't forgotten.
Replace every line in brackets. Keep the overview to one page, and delete any section your game does not need, with one line saying why.
1. One-Page Overview
Anyone who reads only this page should be able to picture the game.
- Working title: [name]
- Team and contact: [names, roles, email]
- Version and date: [v0.1, Month Day, Year]
- One-sentence pitch: [who the player is, what they do, and why it is fun]
- Genre and influences: [genre, plus two or three games it borrows from and what it borrows]
- Platform and controls: [PC, console, phone, browser] with [keyboard and mouse, controller, touch]
- Target player: [who this is for, and how long a session lasts]
- Core loop: [the actions the player repeats, in order, in one line]
- Goal and ending: [what the player is trying to do, how they win, how they lose]
- What makes it different: [one or two sentences]
2. Design Pillars and Non-Goals
The three ideas every decision is tested against, and what you will not build.
- Pillar 1: [short phrase] because [why it matters to the player]
- Pillar 2: [short phrase] because [why it matters to the player]
- Pillar 3: [short phrase] because [why it matters to the player]
- Non-goals: [features you have decided not to build, so nobody starts them]
3. Gameplay and Mechanics
The rule book. A programmer should be able to build from it without guessing.
- Core mechanic: [the actions, the interactions and the rules that together let the player beat a challenge]
- How the mechanic fails: [what happens when the player gets it wrong]
- Controls: [input] does [action], for each input
- Rules: [the full list, including how the game ends]
- Progression: [what changes as the player advances: new mechanics, harder challenges, unlocks]
- Economy and resources: [what the player collects or spends, and where it comes from]
- Tuning values: [name], starting value [number], why [reason], for each value you expect to change
4. World, Story and Characters
Only as much as the game needs. A puzzle game may need a paragraph.
- Setting: [where and when, in two or three sentences]
- Story outline: [beginning, middle, end, in a few lines]
- Player character: [who they are and what they want]
- Other characters: [name, role in play, how they behave], for each
- Tone: [three words, and one sentence on what the game never does]
5. Levels and Content
The list of everything the player will see, and one level described in full.
- Level list: [name, what it teaches or tests, rough length], for each
- Featured level: [goal, layout sketch or map, what is new here, the hardest moment, how it ends]
- Content count: [levels, enemies, items, lines of dialogue], with a target for each
6. Art and Audio Direction
The look and sound in words and references, before anyone makes an asset.
- Look and feel: [three or four adjectives, color palette, camera view]
- Visual references: [image or game], and what to take from it, for each
- Key sound effects: [event] makes [sound], for the sounds that carry information
- Music: [style, where it plays, how it changes with play]
7. Interface and Player Feedback
How the player learns what is happening without reading a manual.
- Screens and menu flow: [title, settings, play, pause, results], with how each one is reached
- On-screen information: [what the player always sees, and what appears only when needed]
- Feedback: [how the game shows success, damage, progress and danger]
- Accessibility: [text size, remapping, color choices, subtitles]
8. Technical Notes
Enough for the programmers to start. The full plan belongs in a separate technical document.
- Engine and version: [engine], [version]
- Target hardware: [minimum device or specification]
- Saving: [what is saved, and when]
- Risks: [the parts nobody on the team has built before]
- Technical document: [link], owned by [name]
9. Scope, Schedule and Team
Who does what, by when, and what gets cut first if time runs short.
- Milestones: [prototype, vertical slice, alpha, beta, release], with a date for each
- Owners: [name] is responsible for [area], for each person
- Asset list: [art, sound and code you must make or license]
- Cut list: [features in the order you would drop them]
10. Open Questions and Change Log
What is still undecided, and a record of what changed and why.
- Open question: [question], owner [name], decide by [date]
- Change: [date], [what changed], because [playtest result or reason], by [name]
Fill in the overview and the pillars first, before anything else. They take an hour, and every later section gets easier once you can test it against three pillars. Leave the tuning values blank until you have a prototype, then write down the numbers you actually tested. A value with a reason next to it is worth more than a page of description, because it tells the next person what to change and what to leave alone.
ExampleA Filled-in GDD Example for a Small Game
Here is the one-page overview from the template, filled in for Lamplight Ferry, a small game invented for this guide. It is a class-sized prototype, so the overview carries most of the design, and a real document would add the level list, the art direction and a schedule behind it. Notice how specific it is: every rule has a number, and the open question at the bottom names what will settle it.
Lamplight Ferry: one-page overview
- Working title
- Lamplight Ferry
- Version and date
- v0.3, a one-page overview for a class prototype
- One-sentence pitch
- You pilot a small night ferry across a foggy river, choosing which riverside stops to light and visit before your lamp oil runs out, so every trip is a short route-planning puzzle.
- Genre and influences
- A 2D top-down puzzle game. It borrows the route planning of delivery games and the resource timer of survival games.
- Platform and controls
- PC and browser. Mouse only: click a dock to set the next stop, click the lamp to trim it.
- Target player
- Puzzle players who like short sessions. One river takes five to eight minutes.
- Core loop
- Read the waiting passengers, plan a route, spend oil to light a dock, carry passengers, earn oil back as fares, repeat until dawn.
- Goal and ending
- Deliver as many passengers as possible before dawn. The night ends early if the lamp goes out, and the boat drifts back to the start.
- Design pillars
- Every choice costs light. A trip is readable at a glance. Failure is quick and teaches something.
- Non-goals
- No combat, no character upgrades, no story told in dialogue.
- Core mechanic
- Lighting a dock costs one unit of oil and reveals the passengers waiting there. Carrying a passenger to the stop they want pays back two units. The challenge is the fog: unlit docks show only a silhouette, so the player must decide which stops are worth the oil.
- Tuning values
- Starting oil 6, fare 2, dock cost 1, boat capacity 3. Capacity is the first value to test, because it decides how far ahead a player can plan.
- Scope
- One river with 9 docks for the prototype. Milestone one is a paper version played with coins as oil, before any code.
- Open question
- Should a passenger wait forever or leave after a few turns? Decide after the first playtest.
Three things make this overview work. The core loop is a single line, so anyone can repeat it after one read. The pillars rule things out: "every choice costs light" is why there are no free actions, and the non-goals stop anyone from starting a combat system. And the tuning values come with a reason, which turns the first playtest into a test of one number instead of a vague question about whether the game is fun.
It also follows the advice in Cornell's initial proposal assignment, which asks teams to describe only their most important mechanic, in the context of a single challenge. That course defines a mechanic as a combination of actions, interactions and rules that produce an effect, and the ferry's oil rule names all three: clicking a dock, the fog that hides passengers, and the cost and payback that make the choice matter.
Over timeHow a GDD Changes During Game Development
A GDD written once and never touched again describes a game nobody is making. The first playtest changes the rules, the schedule changes the scope, and the document has to follow. Cornell's gameplay specification assignment tells students to expect their mechanics to change over the semester, and says the final game may look very little like the first draft.
The same course explains why it moved that document out of a shared wiki. In earlier years, it says, no one updated the wiki even as the gameplay changed, because changes were agreed informally in meetings or email. That is the most common way a GDD fails, and it has nothing to do with the tool. A change log fixes it: one line per change with the date, what changed, the reason and who decided. Our template ends with one for that reason.
Documents also multiply as a project grows. Cornell's assignment list for the course runs from an initial proposal and a concept document through a gameplay specification, an architecture specification and a visual design specification, with a document revision assignment during the alpha push and a final document portfolio at the end. A studio project grows the same way. The overview stays short, and the detail moves into linked pages for each system or level.
Plan for revision from the start. Put a version number and date on the first page, keep old decisions in the change log instead of deleting them, and review the document at each milestone. When the GDD and the build disagree, the build is usually right, so update the document the same week.
Writing a GDD Your Game Team Will Read
The complaint about design documents is always the same: nobody reads them. A career center blog at Worcester Polytechnic Institute warns game students against the habit of writing massive design documents nobody reads. The fixes are mostly about making the document useful to the person who opens it with one question.
- Lead with one page. The UC Irvine course page wants the overview first and no longer than a page, so a reader who stops there still has the game in their head.
- Write rules, not hopes. "The boat holds three passengers" can be built. "The boat should feel crowded" cannot. Turn every feeling you want into a rule or a number someone can test.
- Make tasks specific. The same course page compares task lists: "Clean up" is unacceptable, "Work on AI" is not much better, and "Complete AI for enemy minions" is what it wants. Apply that to every line of the schedule.
- Put the core first in the schedule. UC Irvine asks teams to order deliverables so that the core art and gameplay come before extra features, levels and characters. A cut list in the scope section makes that order explicit.
- Show it. Sketches, maps, flowcharts and mock-up screens explain layout and flow faster than paragraphs. O*NET's task list for designers names exactly those tools.
- Write for the reader of each section. Cornell's assignments restate the same core vision for a publisher and then for the team, at different lengths. Your gameplay sections can assume the reader knows the game, and your overview can't.
Then test the document the way you test the game. Hand the overview to someone outside the project and ask them to describe the game back to you. Where their version differs from yours, the page is unclear, not the reader.
In schoolGDDs in a Game Design Degree
Game design programs teach design documentation through team projects, and some course descriptions say so outright. Two clear examples come from the catalogs our game design classes guide reads, and both are courses you choose rather than courses every student takes.
- UC Irvine, GDIM 161 Multiplayer Game Project. The course description has students design and build a multiplayer game with a focus on team development, writing design documents, playtesting and post-mortems. In the Game Design and Interactive Media, B.S., it is one of 6 upper-division courses, of which students take three.
- RIT, IGME-580 IGM Production Studio. Students on the studio's team projects complete design documents, progress reports and assessments of themselves and their teammates, according to the course description. In RIT's Game Design and Development BS, it is one of 35 advanced electives, of which students take four.
Outside those catalogs, university game courses show how much of the grade the documents carry. In UC Irvine's first-year games course, the draft counted for 20% of the design document grade and the final version for 80%, and the finished document was due on May 8, a month before the completed game on June 8. The course prompt lays out the whole schedule. Cornell's game architecture course assigns a concept document, three specifications and a final document portfolio alongside its prototypes and releases, and the version in the final document portfolio is the one graded.
If you are comparing programs, look for a capstone or studio course where teams ship a game together, since that is where design documentation gets practiced under real conditions. The classes guide lists each program's capstone, and the best game design schools ranking compares the programs on completion and cost. Programs differ in how much writing they ask for, so read the descriptions of the team project courses before you choose.
PortfolioUsing a GDD in Your Game Design Portfolio
A design document is one of the clearest ways to show how you think, as long as it sits next to something playable. Some admissions reviewers say outright that documentation is what they score. DigiPen's game design portfolio, for example, is reviewed on the documentation of the work and the process behind it, not on the quality of the work itself. Our game design portfolio guide covers what each school asks for.
For a portfolio, cut the document down. Reviewers won't read 30 pages, so show the one-page overview, one system or level written in full, and a short note on what playtesting changed. Put the change log to work here: two or three entries that say "we changed this because players did that" show iteration better than any finished page. The WPI post linked above, written for game students building portfolios, is worth reading before you apply for internships.
Pair every document with the build it describes. A GDD for a game that doesn't exist shows less than a small game that does, so link the playable version, a short video, or at least screenshots, at the top of the page.
Which Game Jobs Write GDDs, and What They Pay
Designers write most of a GDD, but most of a team writes some of it, and everyone reads it. The roles below are the ones whose work shows up in the document. Pay is the national median from the Bureau of Labor Statistics for the federal occupation each job is counted under, since BLS doesn't count game jobs on their own.
| Job | Their part of the GDD | National median pay |
|---|---|---|
| Video game designer | Writes most of the GDD: the overview, pillars, rules, systems and tuning values, and keeps it current. | $104,000 |
| Level designer | Writes the level sections: a brief, a map and the challenges for each level. | $104,000 |
| Narrative designer | Writes the story, character and dialogue sections, and the lore that keeps them consistent. | $76,910 |
| Game producer | Works with designers on the schedule, scope and cut list, and keeps documentation current. | $90,360 |
| Game developer | Reads the gameplay sections closely and writes the separate technical document. | $135,980 |
The writing is most central for designers. O*NET's task list for video game designers includes the job to "develop and maintain design level documentation, including mechanics, guidelines, and mission outlines," and to "create and manage documentation, production schedules, prototyping goals, and communication plans in collaboration with production staff." That second task is where designers and producers share the document. Level designers are counted in the same federal occupation as game designers, at a $104,000 national median. Game programmers are counted with software developers, at $135,980, and they work from the gameplay sections while writing their own technical documents.
For pay by state and experience, see the video game designer salary page. If documentation is the part of the job you enjoy most, the level designer and narrative designer guides describe two roles that spend much of their week writing for other people to build from.
Frequently Asked Questions
What Is a Game Design Document?
A game design document, or GDD, is the written plan for a game: what the player does, the rules, the levels, the look and sound, and who builds what by when. The whole team works from it. A UC Irvine game course calls it a "living" document that commercial teams build over many months and keep updating as the game is made. A short version with an overview, the rules and a schedule is enough to start. See what a GDD is.
What Should a Game Design Document Include?
A game design document should include a one-page overview, the design pillars, the gameplay rules and mechanics, the world and characters, the levels, the art and audio direction, the interface, technical notes, and the scope and schedule. The UC Irvine course page cited here groups that into four parts: overview, game specification, technical specification and schedule. Our free template splits it into 10 sections, and you can delete any section your game doesn't need. See the sections.
How Long Should a Game Design Document Be?
As long as the game needs and no longer. Start with a one-page overview and grow it as you decide things. For comparison, a UC Irvine course asked teams for a draft of 5 to 10 pages and a final game design document of 20 to 30 pages, and Cornell's game course asks for a concept document of 2 to 3 pages. A small solo project can live on a few pages. See typical lengths.
Is There a Free Game Design Document Template?
Yes. This page has a free game design document template with 10 sections, each with a copy button, and a button that copies the whole thing. You can also download it as a Word file or a Markdown file, with no sign-up and no branding beyond a one-line credit you can delete. A filled-in one-page example for a small invented game shows what a finished overview looks like. Get the template.
What Format Should a Game Design Document Be In?
Use any format the whole team can open, search and edit: a shared document, a wiki or a set of linked pages. The UC Irvine course page asks for a single web document in a universally readable format, not separate pages. Keep the overview on the first page, use headings so people can jump to their section, and add sketches and diagrams. Cornell's game course warns that a wiki nobody updates goes stale. See the format.
Do Game Studios Still Use Design Documents?
Yes, in some form. O*NET's profile of video game designers lists developing and maintaining design documentation, and documenting game design with mock-ups, menu layouts and flowcharts, among the job's tasks. What has changed is the shape: shorter documents and pages updated as the game changes, rather than one huge file written up front. A career center at WPI warns students against writing massive design documents nobody reads. See who writes them.
Do I Need a GDD for a School or Solo Project?
You need less of one, but writing the short version still helps. A one-page overview, a core mechanic and a cut list keep a solo project from growing past what you can finish, and team courses grade the documents as well as the game. Cornell's game course has teams turn in a proposal, a concept document and gameplay and architecture specifications on the way to a finished game. See GDDs in a degree.
Sources
- 1 UC Irvine, CS 113 / Informatics 125 Computer Game Development: design document structure The living-document description, the four-part outline, the one-page overview rule, task wording and deliverable order. Accessed .
- 2 UC Irvine, US 12C Computer Games as Art, Culture, and Technology: game project and design document prompt (archived by the University of Texas at Austin) Draft and final lengths, the three-minute pitch and the grade weights. Accessed .
- 3 Cornell University, CIS 3152 assignments, spring 2023 The sequence of design documents in a semester game project. Accessed .
- 4 Cornell University, CIS 3152 initial proposal assignment One core mechanic, and the definition of a mechanic. Accessed .
- 5 Cornell University, CIS 3152 concept document assignment The concept document's audience and length. Accessed .
- 6 Cornell University, CIS 3152 gameplay specification assignment The gameplay document's audience, expected change, and the wiki that went stale. Accessed .
- 7 Cornell University, CIS 3152 architecture specification assignment How the technical document differs from the gameplay document. Accessed .
- 8 Cornell University, CIS 3152 document revisions assignment Revising design documents at alpha. Accessed .
- 9 Worcester Polytechnic Institute career development center, building an IMGD portfolio The warning against long design documents nobody reads. Accessed .
- 10 UC Irvine General Catalogue, GDIM courses GDIM 161 Multiplayer Game Project course description. Accessed .
- 11 Rochester Institute of Technology academic catalog, IGME courses IGME-580 IGM Production Studio course description. Accessed .
- 12 University of California-Irvine, Game Design and Interactive Media, B.S.: degree requirements Where GDIM 161 sits in the major's requirements. Accessed .
- 13 Rochester Institute of Technology, Game Design and Development BS: degree requirements Where IGME-580 sits in the major's requirements. Accessed .
- 14 DigiPen Institute of Technology, undergraduate admissions requirements How the BA in Game Design portfolio is reviewed. Accessed .
- 15 O*NET OnLine, 15-1255.01 Video Game Designers The documentation tasks quoted on this page. Accessed .
- 16 BLS, Occupational Employment and Wage Statistics, May 2025 National median wages for the occupations each game job is counted under. Accessed .