Space Explorer is a campaign engine, not a document collection. Everything the game
needs at the table lives in typed data files with cross-references between them, and
every rule file assumes the others will be read fresh rather than remembered. If you
clone this project to extend it, the one habit that keeps it intact is this: every
fact lives in exactly one file, and every other file points at it.
The two layers
The project separates canon data from play rules:
- Data folders —
Characters/, Classes/, Enemies/, Ranged Weapons/,
Melee Weapons/, Grenades/, Armours/, Gear/, Tools/, Vehicles/,
Space Ships/, Space Ship Guns/, Locations/, Planets/, Star Systems/,
Nations/, Species/, Talents/, Abilities/, Specialities/,
proficiencies, and the roster folders. Each folder is one file type with a
schema; each file is one entity with real numbers.
GM Instructions/ — the rules backbone: how combat resolves, how the campaign
loop runs, how each case type plays. Files there are either pinned (always in
the GM's context — canon, combat core, difficulty ladder, tone) or partial
(loaded when their subject comes up — a case run, space combat, downtime).
The player-facing Player's Handbook teaches the same rules in prose; it never
contradicts the GM files, and where a rule is deep (space combat, military
operations) the handbook teaches the shape and defers the detail.
Single source of truth
The project's cardinal rule, enforced everywhere in prose: read the file, never
your memory. An enemy's stats live solely in its enemy file. A boss battle's
composition and tactics live solely in its roster. A weapon's damage figures live
solely in the weapon file. Roster text says things like "read fresh from linked
files" because stat drift starts the moment someone restates a number in a second
place. When you add content, ask: which file owns this number? If the answer is
"this one and two others," you are building drift.
Two exceptions are deliberate:
- Roster-owned tactics. Team tactics (duty splits, formation rules, deploy
zones) are mission-specific and live in the roster — the enemy files deliberately
do not restate them.
- Deference lines. Where a roster needs a rule that lives elsewhere (morale,
cover discipline, weapon fear effects), it carries a one-line pointer, not a
pasted copy.
Cross-references
Prose files (GM instructions, descriptions, notes) reference entities with
<@slug.file-type> mention links; JSON schema fields use plain slugs
("equippedRanged": "lasgun"). Both resolve to the live file, so renames survive.
A reference to a slug that does not exist is a bug — check the target folder before
writing a new mention.
The campaign loop in the data
The state machines that make this a game, not a sandbox, live in the data too:
- One case at a time — the Canon Registry's case shell and the
caseBurns flags on star-system files record what has already happened.
- Reputation bars — four counters (Survey, Science, Security, Diplomacy) on the
Player Memory, spent as currency at the Performance Review every 84 days.
- Systems Evolution — fully surveyed systems gain map labels and mature into
colony cases; the sector changes shape as you play.
When you add a new case type or mechanic, wire it into that loop — a case that
cannot burn a flag, pay reputation, or advance a clock is decoration, not content.
