Game design document wiki: keep a living GDD your team actually reads
For designers, writers and leads who own the game design document. You will learn how to split a GDD into a page tree that stays current, how to control who can read or change each page, and how the Gameheim wiki handles versions, AI writing help and Markdown export.
Why game design documents go out of date
Most studios start with one long game design document. It is complete for about two weeks. Then the combat designer changes the stamina rules in a meeting, the writer renames a faction, and the level designer cuts a biome. Nobody updates the big file, because finding the right paragraph in a 90-page document is slow and nobody knows who else is editing it.
A living GDD solves this by being small pieces instead of one big piece. Each system, character, level and rule set gets its own page, owned by the person who works on it. The pieces are connected by a clear hierarchy, so anyone can find the page they need in a few clicks. This is why so many teams move their game design document into a wiki.
A wiki alone is not enough, though. The failures we see most often are these:
- Nobody knows what changed. A page was rewritten last week and the old rule is gone, with no way to compare or roll back.
- Everyone can see everything. Story spoilers, unannounced features and partner contracts sit next to public mechanics, so leads keep sensitive pages somewhere else and the wiki stops being the single source.
- Half-finished edits look final. A designer is halfway through a rewrite and a programmer implements the draft.
- The document is far from the work. The page describes a hero mesh or a level map, but the file lives in version control and the link between the two is in someone's head.
- Writing is the bottleneck. Leads know what they want but do not have time to turn bullet points into readable pages.
General-purpose tools that were never built for game production can hold the text, but they do not know your version control, your roles or your project. Below: how to structure a GDD wiki in any tool, and how Gameheim handles each problem.
How Gameheim keeps a living game design document
Every Gameheim project has its own Wiki, in the Creative section of the sidebar. It is built around four ideas: a page tree, a publish step that creates versions, per-page permissions, and tools that connect pages to the rest of the project.
A page tree instead of one long file
Pages live in a hierarchy on the left. Any page can have child pages, and branches can be collapsed. You might have a top-level Combat page with children for Stamina, Weapons and Enemy AI. Selecting a page opens it in a clean reading view; people with write access switch to the editor with Edit.
Drafts, publishing and version history
Editing has two separate actions. Save draft stores your work without creating a version. Publish makes the text the current content of the page and creates a numbered version, shown on the page as a Published · v3 badge. A page that has never been published shows a Draft badge, and a small dot next to its title in the tree. A saved draft is visible only to the people who can edit the page: readers keep seeing the published version until you publish.
The History button opens the version history. You can preview any published version, Compare it with the current page to see what changed, and restore it. A restore does not erase anything: it publishes the old text as a new version on top, so the restore itself can be undone.
Publishing is also what makes a page findable. Global search and the AI assistant work on the published text, so a page is only found by others once it has been published at least once.
If two people edit the same page, the second save is refused with a message asking to reload, instead of silently overwriting the first person's work.
Per-page access control
Each page has an access mode: Public, Inherited, Read-only or Restricted. Top-level pages start as Public and child pages start as Inherited, so a whole branch follows its parent. A Restricted page is visible only to the members you grant, and it disappears from the tree, from search, from exports and from AI answers for everyone else. Page permissions can only narrow what a person's role already allows; they never give extra access.
Pages linked to Perforce assets
Under each page, Linked assets lists the Perforce files and folders the page is about. Each link shows whether the file is locked and by whom, and the latest changelist and author. Clicking a link asks the Gameheim agent on your machine to open that file or folder locally. See Install the Gameheim agent if you do not have it yet.
AI writing help and Markdown export
In edit mode, the AI button opens the AI Assistant panel with six operations: Continue, Improve, Expand, Summarize, Translate and Write. Write, Expand and Continue can be grounded on the wiki and documents of the project, so the draft uses your own lore and rules instead of generic filler. You always review the result before it goes into the page. The Export button downloads a page, or a page with all its sub-pages, as a Markdown file.
How to build a game design document wiki in Gameheim
These steps take you from an empty wiki to a structured GDD with protected pages, linked assets and a first published version.
- You are a member of the project, and the project is selected in the sidebar.
- Your role includes the Wiki read and write permissions. Deleting pages and changing page permissions also need the Wiki manage permission.
- For the AI Assistant: a plan that includes AI and the AI permission in your role.
- For linked assets: a Perforce project and the Gameheim agent running on your machine.
Open the Wiki
In the sidebar, under Creative, click Wiki. The page tree is on the left. An empty wiki shows No pages yet.
Create the top-level pages
Click New page, type a Title (for example
Game Overview) and click Create. Repeat for each main area of the game: overview, core loop, systems, world, characters, levels, UI, audio. Titles can be up to 300 characters.Add child pages
Hover a page in the tree and click the + button (New child page). The new page is created under it. Use children for the detail: under Systems, one page for each system.
Write and format the page
Select a page and click Edit. The toolbar offers Bold, Italic, Strikethrough, Inline code, Heading 1 to Heading 3, Bullet list, Numbered list, Quote, Code block, Undo and Redo. Typing
#at the start of a line also creates a heading, and-starts a bullet list.Save a draft or publish
Click Save draft to store your work without creating a version. When the page is ready, click Publish. The badge changes to Published · v1, and the page becomes findable in search and by the AI assistant. The Unsaved changes label reminds you when there is work you have not saved.
Important:If you switch to another page with unsaved changes, Gameheim asks you to confirm before discarding them. Save first if you want to keep the text.Protect sensitive pages
Open the page and click Permissions. Under Access mode, pick Restricted for spoilers or unannounced content, then use User grants to add members with Read or Write and click Grant. Pick Read-only for rules that everyone should see but only the page owner and wiki managers should change.
Link the assets the page describes
In edit mode, under Linked assets, click Link asset. Enter the Perforce path (for example
/Game/Characters/Hero/Hero.uasset), choose File or Directory as the Type, add an optional Label and confirm. Readers can then open the asset on their own machine from the page.Draft faster with the AI Assistant
In edit mode, click AI. Select text in the editor and choose Improve, Expand, Continue, Summarize or Translate (enter the language in Translate into). For Write, type an instruction in the text box first, for example
Draft the stamina rules for dodging and sprinting. Keep Use project knowledge ticked so the draft is based on your wiki and documents; the result shows the pages it used under Based on:. Then click Insert at cursor, Replace selection, Copy or Discard.Review changes and export
Click History to open Version history. Select a version to preview it, click Compare to see the differences from the current page, or Restore v2 to bring it back as a new version. Click Export to download This page only or This page and its sub-pages as Markdown.
How to structure a game design document wiki
A good structure matters more than the tool. These rules work for most teams, from a three-person indie to a studio of fifty.
- One page, one topic, one owner. A page about the parry system is owned by the combat designer. If a page needs two owners, it is probably two pages.
- Start with a one-page overview. The top of the tree is a short page with the pitch, the pillars and links to every main area. New hires read this first.
- Put the current rule first, history later. Readers want to know how stamina works today. Keep the reasons for past changes in a design decision log instead of in the page body. See Game design decision log.
- Use the same template for similar pages. Every system page can follow the same headings: goal, rules, numbers, edge cases, open questions. Readers learn where to look.
- Keep numbers in one place. If damage values live in a data table in the engine, the page should explain the intent and link the asset, not copy the numbers.
- Publish small, publish often. A published page with a short edit is more useful than a perfect draft nobody can find.
A typical tree for an action game might look like this:
Example GDD page treeGame Overview
Core Loop
Systems
Combat
Stamina
Weapons
Progression
Economy
World
Factions
Locations
Characters
Hero
Antagonist (Restricted)
Levels
Level 01: Harbor
UI and UX
Audio DirectionWiki page permission modes
Page permissions work on top of the Wiki permissions in each person's role. They can take access away, never add it.
| Mode | Who can read | Who can edit |
|---|---|---|
| Public | Anyone with wiki access | Anyone with Wiki write permission |
| Inherited | Follows the nearest parent page with an explicit mode | Follows the nearest parent page |
| Read-only | Anyone with wiki access | The page owner and wiki managers |
| Restricted | Only members granted below, plus wiki managers | Members granted Write, plus wiki managers |
Explicit grants only take effect while the effective mode is Restricted. A top-level page left on Inherited behaves as Public. Wiki managers are the people whose role has the Wiki manage permission; they can always see and edit every page.
What the wiki editor supports
- Text formatting: bold, italic, strikethrough and inline code.
- Structure: three heading levels, bullet and numbered lists, quotes and code blocks.
- Export to Markdown, for one page or a page with its sub-pages. Pages you cannot read are left out of the export.
Wiki pages are structured text. Keep concept art and reference images in Moodboards, and spreadsheets, PDFs and contracts in Documents, then refer to them from the page.
Troubleshooting the wiki
| What you see | What it means |
|---|---|
| Page was modified by someone else; reload before saving | Someone saved the page after you opened it. Copy your text, reload the page, and apply your change again. |
| No Edit or New page button | Your role does not include the Wiki write permission, or the page is Read-only or Restricted for you. |
| No Permissions button | Only people with the Wiki manage permission can change page access. |
| No AI button | The button appears in edit mode only, for roles with the AI permission, on a plan that includes AI. |
| Select some text in the editor first. | Every AI operation except Write works on selected text. Summarize uses the whole page when nothing is selected. |
| No matching project knowledge was found | The draft is not based on any wiki page or document. Publish the relevant pages, or check that the documents are included in search indexing. |
Frequently asked questions
What is a living game design document?
A living game design document is a GDD that is updated as the game changes, instead of being written once at the start. It is usually split into many small pages, one per system, character or level, each with a clear owner. Small pages are easier to update, easier to find and easier to review, so the document stays close to what is actually in the build.
Is a wiki better than a single document for a GDD?
For most teams, yes. A single document works for a pitch or a vertical slice, but it becomes hard to edit and hard to search as the game grows. A wiki lets each designer own a page, lets readers jump straight to the system they need, and keeps a history per page. In Gameheim each page also has its own access mode, so sensitive pages can live in the same tree.
Can I see who changed a wiki page and restore an old version?
Yes. Every time a page is published, Gameheim creates a numbered version with the editor and the date. Open History on the page to preview any version, compare it with the current text, or restore it. A restore creates a new version on top of the history, so nothing is lost and the restore itself can be undone.
How do I hide story spoilers from part of the team?
Open the page, click Permissions and set the Access mode to Restricted. Then grant Read or Write to the members who should see it. Everyone else will not find the page in the tree, in search, in Markdown exports or in AI answers. Child pages set to Inherited follow the same restriction automatically.
Can AI write my game design document?
AI can speed up the writing, but a designer should still decide the content. In Gameheim the AI Assistant can draft a section from an instruction, expand or continue text, improve wording, summarize or translate. Grounded operations use your own wiki and documents as sources. You review every result and choose whether to insert it, so the page still says what your team decided.