Narrative Design Document Template

Narrative design document, lore bible and GDD

Three documents often get mixed up:

• The game design document (GDD) covers the whole game: mechanics, systems, levels.
• The lore bible is the world: characters, places, factions, history and the rules of the world. It is the single source of truth for canon.
• The narrative design document covers how the story is told and shipped: structure, branching, dialogue systems, environmental storytelling, localisation and pipeline. It includes the lore bible or links to it.

What makes a good one

• Write it for your whole team. Lead with the overview and the decisions your team needs, not with backstory.
• It is short where things change often. Dialogue, variables and translations change daily; describe the rules here and keep the content where it is edited.
• Every place has a history. Answering "how was this place created, and what happened here?" for each location is the fastest way to make it believable. Our environmental storytelling guide has a question list for it.
• Story structure is a map, not a list. Write down what each chapter needs to know and what it changes, so branches can be checked. The Route Planner guide shows that idea on an example.
• Variables are documented. Each one has a name, a starting value and a sentence on what it means and where it changes.

The template

Copy the outline into your doc tool, delete what your game doesn't need, and fill the rest as you decide it.

# <Game title>: Narrative Design Document
Owner: <lead writer>   Last updated: <date>   Status: <draft / in review / locked>

## 1. Overview
- Logline: the story in one sentence
- Premise and themes
- Tone, with 3 to 5 references (games, films, books)
- Player fantasy: who the player is and what they want

## 2. Story structure
- Acts, chapters and scenes, each with a short id like [2a]
- The main route, the branches, and where branches meet again
- What each chapter needs to know and what it changes (variables)
- Endings, and the choices that lead to each

## 3. Characters
For each character:
- Name, role in the story, want and need
- Voice notes and two sample lines
- Relationships to other characters and factions
- Where they appear (chapters, scenes)

## 4. World (the lore bible)
- Places: how each was created, what happened there, who lives there now,
  and the challenge it faces today
- Factions and society: culture, beliefs, politics, economy
- Timeline of key events, before and during the game
- Rules: magic, technology, and what is impossible
- Glossary of names and terms

## 5. Dialogue
- Dialogue types: conversations, hubs, barks, cutscenes
- Choice style: how options are written, how many, how long
- Variables: name, starting value, meaning, who sets it, who reads it
- Line style guide: length, punctuation, naming of speakers

## 6. Environmental storytelling
For each key location:
- What happened here, in the player's words
- What the player should notice, and in which order
- Which dialogues or quests react to it

## 7. Gameplay and narrative
- Which mechanics express the story, and how
- Where story blocks and game blocks meet or overlap

## 8. Localisation and voice
- Target languages, and which ones must be complete to ship
- Key conventions for lines, character limits, things not to translate
- Voice casting notes per character

## 9. Pipeline
- Tools for writing dialogue and lore, and who edits what
- File format, engine import, and where the files live (repository, branch)
- Review: who approves story changes, and how

## 10. Open questions
- Decisions still to make, with an owner and a date

Keeping it alive

The outline works in any doc tool. The parts that change most, the world, the dialogue and the translations, are easier to keep current in a tool built for them. In LoreHub:

• The Worldbuilder is the lore bible: each character, place and faction is a document with relations to other documents, its own gallery and events on a timeline.
• The Dialogue Builder holds the dialogue itself, with variables that have a starting value and a comment saying what they mean.
• The Route Planner keeps the story structure as a map of what each part requires and produces.
• The Translate tab keeps every language next to its line, and stories are plain-text OSF files you can keep in Git or Perforce.

Then the narrative design document can stay what it should be: the decisions, the rules and the reasons. For a practical start on the dialogue part, read how to write branching dialogue for games.