Start Here — The Builder’s Mental Model
LIMBO is built from a small number of file types. A good addition is not merely interesting prose: it is a complete piece of data that the GM can find, place in a scene, and use without guessing what the author meant.
The basic rule
Edit content files to add or tune world material. Edit file-type schemas only when the project needs a new kind of information. Edit layouts only when the information exists but is difficult to see or use. Edit GM instruction files when the behavior of play needs a procedure. These are different jobs; changing one to compensate for another is a common way to break the game.
The main living data types are:
| Type | Purpose | What it drives |
|---|
| Character | Player characters and NPCs | Stats, survival, memories, encounters, tactical display |
| Creature | Reusable hostile or neutral creature definitions | Spawn selection, threat data, attacks, loot |
| Location | Places and their environmental identity | Travel, encounter matching, danger, resources, scavenge and vehicle spawn tables |
| Establishment | A trade post, clinic, or service site with a named operator | Trade scenes, currencies, stock, trust-gated inventory |
| Item | Objects that can be carried, found, traded, or consumed | Inventory, condition, weight, effects |
| Recipe | A craftable result and its requirements | Crafting checks, time, ingredients, tools |
| Vehicle | Drivable machines, from dirt bikes to mobile bases | Fuel, cargo, parts, storage nodes, faction fleets |
| Faction | Organizations — colour, territory, allies, standing | Map token colours, reputation tiers, presence at locations |
| Game Start | A playable opening state | Starting character, date, location, threats, map |
| GM Instructions | Searchable procedures for the GM | Combat, survival, travel, crafting, response |
| Lore | Found documents and world knowledge | The discoverable paper trail: history, science, explanations |
| Rules | Player-facing system rules | Character creation, combat, crafting, survival, vehicles |
The pinned turn loop is not a type of its own — it lives in <@turn-workflow.gm-instructions>, a GM Instructions file that stays open during play.
Before you edit
- Decide whether you are adding a fact, a reusable rule, a display, or a procedure.
- Read the relevant file type’s schema and one or two finished examples.
- Check references by using the existing file’s exact name/slug; do not invent a target.
- Keep required fields present, especially
name.
- After editing, inspect the file as it will be used: can a GM find it, can a player understand it, and does it match the surrounding vocabulary?
What can break
The most dangerous errors are often silent. A creature with no matching habitat may never spawn. An NPC with no encounter tags may never be selected. A recipe that names ingredients inconsistently may look complete but be impossible to resolve. A character with missing tactical fields opens with a blank Tactical tab. A new schema field can invalidate hundreds of existing files if it is made required.
Prefer small, reversible content edits. Do not “fix” a missing behavior by adding duplicate fields, hand-entered totals, or a second naming convention. One canonical field is easier for the GM, the layout, and future builders to trust.
The division of responsibility
The schema says what shape is legal. The file supplies the world’s facts. The layout decides what a reader sees. The GM instructions say when the GM uses those facts. The checklist protects the turn loop. If a value is calculated from other values, keep its source data authoritative and let the existing computed field or procedure derive the result; never hand-maintain a second copy just because it is convenient to read.
When in doubt, preserve the project’s existing conventions. Consistency is a mechanic here: search and matching depend on shared tags, names, and references.
Faction identity and color
A faction’s color field is its canonical visual identifier. Store the color once in the faction file as a hex value, then let layouts, map markers, tokens, and other interface elements use that field. Do not copy faction colors into NPC files, locations, lore, or manuals; duplicated hex values drift when a faction’s palette changes.
Faction color is an organizational aid first, not automatically an in-world uniform or banner color. Describe clothing, tags, symbols, and other diegetic visual markers in the faction’s lore only when the fiction supports them. Never rely on color alone: keep names, labels, and file references visible for readability and accessibility, including for players who cannot distinguish the palette.
When placing faction members on a map, use the faction’s stored color consistently for their markers or tokens when the interface supports it. If a character belongs to no faction, or the faction is uncertain or concealed, use a neutral marker rather than guessing. A faction’s color should help someone read the map at a glance without replacing the character’s identity or link.