Builder's Manual · Chapter 1

System Foundation

This system is a tabletop RPG about a founder, a growing settlement, and the consequences of the choices made between them. It is not a conventional combat game with a settlement minigame attached. The settlement is a second protagonist: it has resources, needs, identity, relationships, dangers, and a history that changes from day to day.

Two kinds of play

A session moves between character play and settlement play. Character play covers exploration, conversation, quests, dangerous scenes, abilities, and personal advancement. Settlement play covers resources, construction, research, population, housing, morale, safety, rank, visitors, factions, and threats.

Keep the two layers connected, but do not collapse them into one statistic. A character's level and XP are independent from settlement rank. A successful expedition may earn XP, reveal a Map Area, create a Quest, or change a Threat; it does not automatically solve every settlement problem. Likewise, a building may improve food or housing without deciding how the founder feels about the people who live there.

The source of truth

Every persistent fact has one canonical owner. The Settlement HUD owns mutable settlement state: day, season, weather, resources, population, housing, morale, safety, rank, construction, research, area states, active threats, arrivals, objectives, and settlement history. A Blueprint is only a construction template; a completed building becomes a Built Structure and is then referenced by the HUD. A Character owns personal level, XP, current HP and Mana, equipment, and learned ability references. Quests own their status and consequences. Factions own reputation. Map Areas own permanent geography, while the HUD stores what the settlement currently knows or controls about them.

References connect these records. Computed fields are read models, not alternate storage. If a value can be derived from another record, do not ask the GM or player to maintain a second copy of it. This is the central rule for extending the system: store choices and changing facts; derive summaries, totals, projections, and labels.

Agency is a mechanic

The player decides the protagonist's identity, voice, feelings, promises, and major actions. The player also chooses settlement names, identity paths, rank rewards, recruitment, diplomatic approaches, irreversible risks, and level-up ability increases. A builder should design content that presents meaningful options and consequences, not content that quietly selects for the player.

A good entry answers three questions: what is happening, what can the player change, and what will change if they do? This applies equally to a Guest, a Threat, a Blueprint, a Quest, or an Enemy.

The design test

Before adding a rule or record, ask:

  1. Does it create a meaningful choice or clarify an existing one?
  2. Is its state stored by the correct owner?
  3. Can it be resolved with the current fields and references?
  4. Does it work at the settlement's current scale and rank?
  5. Does it leave room for non-combat, failure, retreat, negotiation, and player interpretation?

If the answer to the third question is no, do not invent a parallel subsystem in prose. Extend the owning type deliberately, or redesign the content so the current system can express it.

Manual updated Aug 15, 2026.