Flexible layer
Natural language, scene narration, conversational interpretation, ordinary role-play, and contextual description.
TECHNICAL OVERVIEW
A living world with a hard state boundary.
The player communicates naturally, but the game does not treat generated prose as authoritative state. Canonical context constrains resolution, supported changes are validated, and persistent results are committed into revisioned campaign state.
The shortest complete model
natural player action
↓
authenticated turn request
↓
canonical server context
↓
bounded narrative reasoning + proposed supported operations
↓
server validation
↓
authoritative commit
↓
revisioned campaign state + event history + player-visible narration
The current browser client submits a character identifier, a unique turn identifier, the revision the player believes is current, and the player's free-form action. The server verifies access and state before a turn can become authoritative.
What “authoritative” means here
Authoritative does not mean every aspect of the game is deterministic. It means persistent facts have an owner. A narrative response can describe uncertainty, conversation, observation, and immediate consequences, but it cannot silently create unsupported inventory, money, injuries, legal status, prizes, quest completion, or other lasting state merely because the prose says so.
Hard boundary
Persistent campaign state, revision control, validated operations, event records, and committed save state.
The world is data, not just prompt text
Fortune & Gallows maintains structured historical and gameplay registries for locations, points of interest, historical people, factions, ships, items and services, story content, economic rules, historical events, and weather evidence. The runtime can use these records to constrain what exists, when it exists, and what can plausibly be known or encountered.
The registry is not a claim that every researched doctrine is already implemented as a full gameplay mechanic. Public documentation distinguishes verified runtime behavior from design contracts and development-only work.
History and agency occupy different layers
The player has broad agency over their character's choices, methods, loyalties, risks, relationships, work, crimes, travel, and survival. Fixed historical anchors are not rewards to be unlocked or branches waiting to be rewritten. The historical-event system stages the player's relationship to an event—before it, during it, and after it—without requiring history itself to become player-authored.
Agency is not the same as historical authorship.The intended question is not “Can the player rewrite the event?” but “What can this character realistically do, learn, lose, gain, witness, avoid, or misunderstand while history continues?”
Saves are revisioned campaign state
A successfully committed turn advances the authoritative save revision. Current save structures retain build and schema versions, world date and time, revision identifiers, event associations, state data, and state hashes. Separate event records capture the expected and applied revisions so stale or repeated requests can be detected instead of silently overwriting reality.
Each player character has an independent campaign state. Switching characters changes which voyage is active rather than sharing one mutable world save across all characters.
Current-version wording
The audited player runtime lineage is Alpha 0.8.0-player.1. Development work may exist beyond that runtime without constituting a new public release. These docs therefore avoid turning development milestones into fictional version promotions.