A lore bible is the single authoritative record of what is true in your world: who exists, what happened, how things work, and what is never allowed to happen. The mistake that kills most of them is treating the bible as a writing project, because a hundred pages of beautiful prose answers questions slowly, drifts out of date quietly, and cannot be handed to a quest designer, a localization team, or a game engine. The bibles that survive production are structured like data: typed entries, explicit relationships, and stated rules, kept in one versioned place that everyone treats as canon.
This guide walks through building one from scratch or from the notes you already have. It applies whether the destination is a game, a campaign, or a novel series, though the later steps lean toward games.
The steps
- Decide what the bible is for and who reads it. A solo writer's memory aid, a team's shared canon, and a machine-readable source for AI tooling want different levels of rigor. Name the audience first, because every later choice (depth, format, tooling) follows from it.
- Inventory what already exists. Most projects do not start from zero; they start from scattered documents, chat logs, old drafts, and maps. Gather everything into one folder before organizing anything, so the bible describes the world you actually have rather than the one you remember having.
- Break the world into typed entries. Give every character, faction, location, item, and event its own entry with a consistent set of fields: a one-line summary, status, allegiances, and the facts other entries depend on. One entry per thing is the rule that makes the bible queryable; an essay that mentions ten characters answers questions about none of them.
- Make relationships explicit. "Mara distrusts the Concord because of the harbor massacre" should exist as a stated link between three entries, with the cause named, since relationships carried only in prose are the first thing a new team member misses and the first thing an AI tool hallucinates around. Who serves whom, who knows what, and what happened where are the load-bearing facts of any world.
- Write the rules and the hard limits. Beyond facts, a bible needs constraints: how the magic or technology works, what it costs, and a short list of things that must never happen (the dead stay dead, the empire never uses the old tongue, nothing crosses the Veil). This section does the most work per word, because it is what keeps future content, human or AI-generated, inside canon.
- Fix the timeline. Order the events that entries reference, with at least relative dates, and resolve contradictions now; every long-running project accumulates them, and they are cheap to fix in a timeline and expensive to fix after a quest ships depending on the wrong order.
- Version it and appoint an owner. Canon changes, so the bible needs a change history and one person with the authority to accept changes, even on a team of two. A bible nobody owns forks into private copies within months.
- Make it game-ready. If the destination is a game, the final step is converting entries into data an engine or a runtime can consume: engine-ready entities and relationships rather than documents. Our guide to turning lore into game-ready data covers this stage in detail.
What tools should you use?
Plain files in a versioned folder (Markdown in a git repository, or a linked vault in a tool like Obsidian) are a genuinely fine answer, and their portability is easy to underestimate. Worldbuilding wikis such as World Anvil add structure, templates, and sharing on top, which suits worldbuilders who publish to readers and GMs; we compare that category in tools like World Anvil. The step most tools leave manual is the third through fifth above, extracting typed entries, relationships, and rules from the prose you already have, which is the specific job Architect does: it is free, it ingests existing documents, PDFs, images, and notes, and it produces structured entities and mapped relationships you review and correct rather than type from scratch, exportable to Unreal, Unity, Godot, or JSON.
How much detail is enough?
Depth should follow use, and the honest test is whether anyone will read the entry to make a decision. A tavern keeper who appears once needs three lines; a faction driving the main plot needs its goals, methods, internal tensions, and history, because quest design will interrogate all of them. Writing depth nobody consumes is the second most common way bibles die, right after not being updated, so start shallow and deepen entries when work actually touches them.
Which should you choose?
- Solo writer or GM keeping a world straight: linked plain files or a wiki, with steps 3 to 5 applied ruthlessly even at small scale.
- Worldbuilder publishing for readers or a table: a wiki platform like World Anvil, which is built for presentation and sharing.
- A team shipping a game: a versioned, owned bible with typed entries, then the game-ready conversion step; Architect (free) automates the extraction and structuring.
- A game with AI-driven narrative at runtime: everything above, plus the rules section treated as machine-enforceable constraints, which is what Director (in beta) validates its decisions against.
FAQ
What is a lore bible? A lore bible is the single authoritative reference for a fictional world: its characters, factions, places, events, rules, and timeline. Teams use it so that everyone, and every tool, works from the same canon.
What should a lore bible include? Typed entries for characters, factions, locations, items, and events; explicit relationships between them; the world's rules and hard limits; and a timeline. A change history and a named owner keep it trustworthy over time.
What is the difference between a lore bible and a story bible? Usage varies by studio, but a story bible usually covers one work (its plot, cast, and tone), while a lore bible covers the world underneath, which many works can draw on. The structure in this guide serves both.
How long should a lore bible be? As short as it can be while answering the questions people actually ask of it. Depth per entry should follow use: three lines for a minor NPC, full treatment for whatever drives the plot.
Can AI write my lore bible for me? AI is better used to structure than to invent: a tool like Architect extracts entities, relationships, and structure from the material you already wrote, with you reviewing every result. Canon you did not author and did not review is not canon; it is unvetted content wearing canon's authority.
The short version
A lore bible survives when it is structured, owned, and versioned: typed entries, explicit relationships, stated rules, and a timeline, at whatever depth production actually consumes. Write the rules section as if a machine will enforce it, because increasingly one will. Architect is free and does the extraction and structuring from your existing material, and if your game runs AI narrative at runtime, Director, in beta, is what enforces that canon while the game is played.