Running the Game
Two file types wire up play itself: Game Start and GM Instructions. They do different jobs, and understanding the split keeps a new project from launching flat.
Game Start: the lobby card
A Game Start file is the card players see in the lobby — name, image, a one-line description. That is all its content holds, and that is deliberate: the card is the promise, and the promise alone doesn't run anything.
The actual play configuration — the starting location, the playable characters, the opening beats — is separate metadata attached to the file, written through the game-start command rather than into the file's content. As a builder, set it up once and keep the card and the configuration in sync: if the card promises "a warm tavern and an immediate reason to act," the configuration should deliver exactly that — a starting location file, ready characters, and an opening scene that drops the party into motion.
The existing Tavern Start is a good card to build on: "Begin at a warm tavern with a few ready characters and an immediate reason to act." The next step for a real campaign is wiring it to an actual tavern location and a set of playable characters.
GM Instructions: the private brief
GM Instructions are markdown files the GM reads during live play. This is where rulings, tone, escalation, and secrets live. The example file in the project shows the shape — one directive, imperative voice:
"If the user says they are using a skill or performing an action, ask them to roll an appropriate skill check before resolving the outcome."
That is the correct density for a GM brief: a small number of strong instructions, each one actionable at the table. A good set of GM instructions covers:
- How to run the system — when to call for a Test, how to handle Glory and Wrath, how to run combat (point at the Player's Handbook chapters rather than restating them).
- How to run the world — the tone, the stakes, the factions' agendas, what should never be shown early.
- The secrets — the twist, the villain's plan, the truth under the map. This is the only place secrets belong.
The public/private split
The Player's Handbook and the Builder's Manual are public — assume every player reads every chapter. GM Instructions are the GM's private brief; they are loaded during play and are not part of the player-facing books.
The discipline this creates: never bury a twist in a handbook. If the campaign's reveal is in a Player's Handbook chapter, the players will read it before the session starts. If it belongs anywhere in the workspace, it belongs in a GM Instructions file — and the handbooks and location files should only hint at it in ways that survive being read.
Context visibility — the one thing you must do by hand
Every file resolves a context visibility that decides how much of it the GM holds:
- pinned — full content always in context. Right for mutable play state.
- partial — name and description in context, body read on demand.
- searchable — the default. Found by search when relevant. Right for bulk reference.
- hidden — invisible.
Visibility is set in the app and does not travel through the workspace. It is not a field on a file, not a field on a file type, and there is no craft command for it. Anything pushed from a checkout — including everything in this project — lands as searchable. That is correct for the 600-odd reference records, and wrong for exactly two things.
This project ships with exactly three files off the default, and you should not need to change any of them:
| File | Visibility | Why |
|---|---|---|
GM Instructions/Running the Game | pinned | The core rules brief and the index into everything else. |
Rules/Wargear Traits | partial | The GM knows it exists and opens it when a trait needs resolving. |
Rules/Threat Stat Blocks | partial | Same — how to read a stat block, on demand. |
Everything else is searchable on purpose. The pinned instruction is written as an index that points at the rest, so the GM finds a rule by name rather than carrying 600 files in context. Six pinned chapters crowding the window makes the GM worse, not better.
Do not pin a Party record, and be careful what else you pin. Pinned visibility travels with the project. Anything you pin here is pinned for every game anyone builds on this system, which is exactly wrong for campaign state — one group's warband has no business in another group's context. Party records are reached through the Game Start's party field instead, so each campaign's roster stays scoped to the campaign that owns it.
This system ships no Party record — it ships no campaign at all. Create one for your own campaign and point your own Game Start at it. Note that this caution is for you, the builder: do not put "this is only an example" into the GM's instructions or a live record's notes, because a Gamemaster told mid-session that the sheet is provisional will hesitate to write to it.
The same caution applies to any mutable tracker you add — a quest log, a faction clock, a war progress record. In a project you are actually playing and nobody clones, pin it freely. In a base system others build on, route to it from the Game Start and leave it searchable.