Manifest Rail - Game Design Document¶

Concept¶

Title: Manifest Rail Genre: Railroad Management Simulation Influences: Deep management sims — Out of the Park Baseball, Football Manager, Motorsport Manager (data-first presentation; "advance time to the next decision" pacing; manage-or-delegate depth control). Grand Tactician: The Civil War for the vintage hand-drawn map aesthetic — now an on-demand view rather than the primary surface. Classic railroad business sims for the underlying domain.

Manifest Rail is a deep railroad management simulation. The player runs a railroad company — and, over time, may hold stakes in others — growing a network from a single headquarters into a regional and then inter-regional system, while managing reputation, executing construction projects through subordinate staff, and structuring the financial and contractual deals that fund and feed the network.

The game is played through menus and data — ledgers, tables, entity profile pages, an inbox — in the lineage of Out of the Park and Football Manager. The hand-drawn map is a view the player calls up on demand to read the network's shape, not the screen they live in. Time advances a day at a time: the player ends the current day, or lets the simulation run forward until a stop point they care about. The game does not test reflexes — it tests judgment, and lets the player choose how much detail to handle personally versus delegate to staff.

Presentation and Interaction Style¶

Manifest Rail is a data-first management sim. The player's primary surfaces are menus, tables, and entity profile pages — the operator's office rendered as paper and ink, not a live map. The hand-drawn map is a powerful secondary view, called up on demand.

Primary surface — menus and data. The player lives in a shell of navigable screens: a persistent top status bar (date, treasury, the advance-time control), a small set of top-level sections (Network, Fleet, Contracts, Finances, Staff, Goodwill, Rivals, Portfolio…), and a content area of tables and profile pages. Every named thing — a region, a line, a contract, a rival, a staff member, a company — is a clickable entity with its own profile page; the player browses the world by following links between them. See UIArchitecture.md.
Secondary surface — the map, on demand. A vintage, hand-drawn-style map of the scenario region, in the visual tradition of period railroad maps (reference: Grand Tactician: The Civil War). The map is vector-based — regions, borders, stations, and rail lines drawn as ink on paper — and the player opens it to read the spatial shape of the network: ownership, throughput, commodity flows. It is a view, not the home screen. See MapAndRegions.md.
Stations and infrastructure live on settlements. A station carries a capacity tier (Halt / Depot / Terminal) that gates which contracts its settlement can serve; building one either connects an existing town or creates a new settlement from open country. The player reads this as data in tables and settlement/county profiles, and sees it rendered on the map. See MapAndRegions.md.
Pacing — a day at a time. The simulation ticks daily. The player advances one day, or sets the sim running forward until a stop point: a date the player names ("sim to the first of next month"), a scheduled obligation (a project completes, a contract-signing window closes, a service-level deadline looms), or a surprise event surfaced through play (subject to information lag — it may even arrive past its deadline, leaving only the fallout). The player configures which kinds of thing stop the sim and which are logged silently. Whatever accumulates while the sim runs collects in an inbox the player reviews when it stops. Financial summaries aggregate from the daily base to weekly, monthly, and quarterly cadences.
Depth is the player's to set. As in Out of the Park and Football Manager, the player chooses how much to manage personally. Operational layers — fleet allocation, maintenance, routine procurement, even the running of an entire company — can be delegated to hired staff, who act according to their own competence and priorities. The player can run one railroad down to the last contract while a second runs on its managers, or oversee a portfolio at arm's length.

The Map and Regions¶

The world is a three-tier model: counties (the area layer), settlements within them (the rail-graph nodes), and stations built on settlements. A region / county is classified rural or industrial and carries a rural population, terrain, and a set of named settlements (city, town, village, fort, camp…), each with its own population and map position. The player's company starts with a headquarters at a settlement, which anchors where the network grows from.

The rail network is a graph of settlements: nodes are settlements (a settlement gets a station at a capacity tier — Halt, Depot, Terminal — that gates which contracts it can serve), and edges are rail lines connecting two settlements along a surveyed route (its length and grade are an output of planning — a better surveyor plans a tighter, better-graded line). Counties underneath supply geography, terrain, and population but are never themselves traversed. Building a station either connects an existing town or plants a stop in open country that can grow a settlement around it. Network growth follows a natural arc: nearby settlements brought online cheaply at Halt to feed a hub, upgraded as contracts demand volume, then long-haul trunk lines between major settlements as the network matures.

Each rail segment is also a finite throughput resource: per-tier capacity counts (Branch / Standard / Trunk) determine how much cargo can flow each day. Mid-to-late game the player invests in parallel lines, signaling tech licenses, and bypass routes to keep saturated corridors moving. Rivals may negotiate trackage rights to use player-owned segments for fees — making the network not just a thing the player builds but a competitive surface in its own right.

→ Full detail: MapAndRegions.md

The Player Character¶

The player runs the game through a player character — a named individual who heads the company and persists across scenarios. The character has a few defined properties:

Personal goodwill with each tracked stakeholder, distinct from company goodwill (per Goodwill.md).
A residence that acts as the reference point for the information-lag system. Typically the company HQ; scenario-overridable.
Personal assets — cash and stock holdings tracked separately from company assets. The character carries these through events, takeovers, and scenario transitions.
Flavor traits authored at the scenario or campaign level — backstory, personality leanings, specific connections (former senator, former labor organizer, immigrant industrialist, etc.) — that surface in event prose and unlock contextual options without directly modifying mechanical outcomes. The player still picks what to do; traits give the character texture, not overrides on agency.
No mechanical interest — the player character does not belong to a population interest group (per Populations.md). The player is free to court Labor one decade and crush them the next without their character being locked into a faction.

No Aging¶

The player character does not age. They are mechanically timeless within and across scenarios — most scenarios fit comfortably within a person's working life, and the design is not aiming for centuries-spanning campaigns where succession mechanics would matter.

If a campaign or scenario wants succession or generational play, it's authored explicitly via scripted events (the character retires, hands the company to a successor, etc.) rather than emerging from a default aging mechanic.

Cross-Scenario Continuity¶

In campaign play, the player character carries reputation and personal assets across scenarios per the rules in Goodwill — Carryover. Standalone and Free Scenario play start the character with a scenario-defined or player-chosen initial state.

A Portfolio of Companies¶

The player character is not bound to a single company. Over a scenario they may lead one railroad, sit on the board of another, and hold a passive stake in a third — building a portfolio through the equity and shareholder mechanics in BusinessDealings.md. What the player can do in any given company is gated by their authority there:

Leader — the person in executive control; the full management surface, identical to the company the player started with. The title is scenario-authored to fit the company's country, era, and form (mechanically they are all "the leader"; the label grounds the period):
1920s United States, chartered corporation → President (sometimes under a Chairman of the Board who holds controlling ownership).
1830s–1850s early American line → Superintendent or President.
Victorian / Edwardian Britain → Chairman (the controlling figure) or Managing Director, with a General Manager as operating chief.
Continental European state railway → Director-General.
Mid-20th century onward → Chief Executive (CEO).
Board member (a Director, in most eras) — exactly the levers an AI board member has: voting on board matters, privileged access to the company's books, proposing strategic direction, and influencing executive hiring and payouts — but not directly commissioning projects or signing contracts.
Passive holder — holdings, dividends, and whatever information the stake entitles them to.

Independently of authority, the player chooses their engagement with each company: act hands-on, or delegate the company to its hired staff, who then run it according to their own competence and priorities (see ProjectManagement — Staff and Labor). The player's "primary" company is simply the one they keep hands-on; there is no hard limit, only the limit of attention. Personal cash and stock holdings (above) are the capital the player deploys to build this portfolio, tracked separately from any one company's treasury.

→ Full detail: BusinessDealings.md

Core Systems¶

The principal interconnected systems are Goodwill, Construction, and Business Dealings. Each is its own design area, but they all feed into and constrain each other. They sit alongside several supporting systems — Populations, Events, and Information & Communication — detailed in their own deep-dive docs.

Goodwill (Reputation)¶

Reputation is tracked per entity — every named actor in the world has its own reputation, scored independently across each relevant stakeholder. The two most prominent for the player's day-to-day interaction:

Player Goodwill — the player character's personal reputation.
Company Goodwill — the railroad company's reputation as an institution.

Beyond these, owned subsidiaries (construction firms, manufacturers, refineries) and named individuals (key staff) each carry their own reputations as well, evolving with their actions and persisting beyond their employment.

Player choices affect multiple tracks at once, sometimes in the same direction and sometimes in opposite directions (e.g., a ruthless cost-cutting decision might preserve the company's financial standing while damaging the player's personal reputation). Reputation on each track gates and modifies outcomes in the other systems.

→ Full detail: Goodwill.md

Construction and Project Management¶

The player does not place track tile by tile. Instead, the player commissions projects — high-level orders such as "Establish a rail connection from this urban region to a neighboring rural region, and bring its infrastructure online at Halt tier." Company staff handle the planning; the planning step is abstracted away from the player.

What is not abstracted is the financial transparency. Every project displays its line items with both projected and actual costs as the work is carried out. Overruns, savings, and surprises are visible and consequential. Projects produce or modify regions' infrastructure tiers and the rail lines connecting them.

→ Full detail: ProjectManagement.md

Business Dealings¶

The financial machinery that funds the network and turns it into a business:

Bonds — debt instruments the company issues to finance projects (or other obligations).
Equity — ownership stakes in other businesses: producers, refineries, and new businesses the player commissions as projects. Stake size depends on the target — a small farm is a full buyout, a major factory is typically a partial stake.
Contracts — revenue agreements with shippers and passengers. Contracts vary in scale and favorability: small producers get standard rates at the local warehouse; large industrial customers may get sweetheart deals to win them away from competing networks; government contracts trade low rates for guaranteed high volume (freight or mail).

→ Full detail: BusinessDealings.md

How These Systems Interconnect¶

These systems are deliberately load-bearing on each other. A single decision usually moves more than one of them.

flowchart TD
    Map[Map and Regions]
    Pop[Populations]
    Econ[Economy]
    Good[Goodwill]
    Proj[Construction / Projects]
    Ops[Operations]
    BD[Business Dealings]
    Proc[Procurement]
    Info[Information & Comm]
    Events[Events]

    Map --> Pop
    Map --> Econ
    Pop --> Good
    Econ --> Pop
    Econ --> BD
    Good --> Proj
    Good --> BD
    Good --> Proc
    Proj --> Ops
    Proj --> BD
    BD --> Proj
    BD --> Proc
    Proc --> Proj
    Info -.-> Events
    Info -.-> Good
    Info -.-> Econ
    Events -.-> Good
    Events -.-> Proj
    Events -.-> BD
    Events -.-> Pop
    Events -.-> Econ

Solid arrows show direct mechanical dependencies (one system reads or writes the other's state); dotted arrows show cross-cutting effects from supporting systems (Information & Communication and Events) that touch multiple core systems.

Goodwill ↔ Construction. Project execution affects goodwill: a project that finishes on time and under budget builds company goodwill; cost overruns, accidents, or eminent-domain disputes can damage either or both reputations. Conversely, low company goodwill raises construction costs (suppliers and labor demand a premium) and low player goodwill makes it harder to obtain permits and right-of-way.
Goodwill ↔ Business Dealings. Bond pricing reflects company goodwill — a reputable company borrows cheaply, a tarnished one pays a high coupon or can't issue at all. Contract terms reflect both: a sweetheart deal with a factory may demand high player goodwill with that owner; a government mail contract may require company goodwill above a threshold. Equity acquisitions can move goodwill either way depending on whether the target was acquired cleanly or hostilely.
Construction ↔ Business Dealings. Projects are funded by cash, by bonds, or by partnering with equity holders. New construction creates new nodes that enable new contracts — and a newly-connected settlement generates its own recurring freight demand that partially funds the next build, so expansion is a reinvestment loop rather than a war-chest drawdown (see Connection-Driven Demand). Conversely, signed contracts justify (or demand) new construction, and equity in a producer guarantees a captive shipper at the end of the line.

A typical play loop:

A scripted or emergent event surfaces in the inbox — an opportunity or a pressure.
The player evaluates it against current goodwill, cash, and network state.
The player commits to a project, a financial deal, or a contract — usually some combination.
Staff execute. Costs and outcomes resolve over in-game time. Goodwill shifts.
The new network state and new financial state shape what becomes possible next — a new rail connection generates its own freight demand that reinvests toward the following build (see Connection-Driven Demand).

A scenario may set an end condition on this loop — a scripted horizon date, a one-metric win goal, and a solvency floor (see End Conditions) — so a run has a defined finish; scenarios with no authored objectives run endlessly.

Information and Communication¶

Layered underneath the core systems is a cross-cutting information system. The player's access to remote data — commodity prices, public sentiment, distant events, goodwill standings — is filtered by the era's dominant communication technology (post → telegraph → telephone) and the distance from the player character's location. Information eventually arrives in fully transparent form — every line item visible once it reaches the player — but its as-of date matters: a postal-era player making a decision based on three-week-old Chicago prices is making a different bet than a telegraph-era player reading same-morning quotes.

→ Full detail: InformationAndCommunication.md

Setting and Scenarios¶

The game ships scenarios scoped to specific regions and eras, played in one of three game modes:

Campaign — a scripted storyline of scenarios played in sequence. Outcomes from earlier scenarios feed scripted buffs and penalties into later ones, allowing campaign authors to express narrative continuity. Carryover is always explicit and authored, never an automatic copy of prior state.
Standalone — a single self-contained scenario played in isolation. Starting state is scripted by the scenario; no state carries in from anywhere else.
Free Scenario — single-scenario open-ended play with player-chosen starting parameters. No goals, no win condition, ends when the player decides. The mode is named to clearly communicate "this is play without scripted objectives — just play."

Scenario concepts and historical hooks are tracked separately. The high-level GDD is intentionally agnostic about which specific scenario is being played — the core systems and the map are the engine; scenarios are the content.

Scenarios may include AI competitor companies, modeled as dynamic actors with their own networks, goodwill, finances, projects, and contracts. Competitors react to game state and player moves; scenarios can script their high-level focus (e.g., "this competitor pursues western expansion") but within that focus the AI behaves dynamically — distinct from purely scripted antagonists. Mechanically, each competitor is a full company runtime identical to a player-held one, driven by the delegation engine under an AI head; the player can buy into one and, with enough authority, take it over (see Rivals as Full Companies).

Player Setup at Start¶

When a scenario begins, the player goes through a setup step that determines initial state. Some elements are scenario-locked; others are player-chosen.

For Campaign and Standalone scenarios, the scenario typically authors most of the setup — the historical character, starting region, era, and assets are locked to fit the scenario's premise. Where authors leave a choice open, the player picks within scenario-defined limits.

For Free Scenario, the player chooses everything within game-defined ranges:

Player character name — free text.
Starting traits — selected from a list. These setup traits define starting reputation as well as in-play effects: some powerful traits grant strong bonuses at the cost of starting reputation deficits with specific stakeholders (an ambitious-but-distrusted operator might gain a Logistics Expert trait but start with negative goodwill among Industrial Barons), while modest traits offer smaller benefits with no penalties. Trait selection is the main expression of "what kind of operator is the player?" (This is a mechanical trait layer — distinct from the character's authored flavor traits, which give texture without overriding outcomes. A setup trait's payload is a starting-reputation delta plus any authored in-play modifier; the two layers coexist.)
HQ region — limited to urban regions on the chosen map. The player picks where the company is headquartered.
Map — any game map flagged for Free Scenario eligibility (see Map Availability below).
Starting era — selected from the eras the chosen map supports.
Starting cash and personal assets — modest default, enough to begin a small network and issue some bonds. Sufficient to grow into the game through normal play; not lavish enough to skip the early-game decisions.

Scenarios can override any of these ranges or defaults. A scenario set in 1849 California might lock the era and HQ region to the Bay Area; a Civil War scenario might restrict trait choices or pre-set the player character.

Free-Scenario Setup Maps onto the Shipped Founding Flow¶

The Free-Scenario setup screen is not a net-new starting-state system — each field drives an already-shipped mechanic. The screen is a front-end that assembles the inputs the company-founding flow and the player-character seed already consume. Field-by-field:

Setup field	Drives which shipped mechanism
Player character name	The player-character entity's display name — free text, no mechanical coupling.
Starting traits	A starting-reputation seed on the player-character's per-region / per-stakeholder standing (the deficit-for-bonus trade-off) plus any authored in-play modifier. The reputation-delta half is exactly the seed the founding flow reads as the player's regional standing (`S_player`) when computing underwriter quotes — a distrusted-among-financiers trait lowers founding-region standing and so worsens quote terms, at no new machinery. The concrete trait catalog, standing-delta magnitudes, and the setup-field ranges are pinned in PlayerSetupTraits.md.
HQ region	The company headquarters settlement (the network anchor, per The Map and Regions) and the founding flow's home-region context. Restricted to `majorUrban` regions — the same region flag that gates which regions can host an underwriter quote, so an HQ in a real financial center yields founding quotes and a frontier HQ does not.
Starting era	Selects the founding date the flow keys on (underwriters are filtered to firms active on that date via `activeFrom`/`activeUntil`), and gates which eras/maps are offered. Bounded by the eras the chosen map authored.
Starting cash and personal assets	The player's personal cash pool from which the founding contribution C ∈ [0, min(personal cash, K)] is drawn, against the scenario-authored capital target K (`targetCapitalization`). The "modest default" is a personal-cash figure sized so C funds a small founder's stake and the underwriter covers `need = K − C` — i.e. the setup screen sets C's ceiling; the founding screen itself resolves the cash/equity mix and underwriter quote.

So the Free-Scenario flow is setup screen → founding flow → GameSession: setup fixes name, HQ, era, personal cash, and the trait-driven reputation seed; the player then runs the same Railroad-Tycoon-2-style founding screen (pick the cash/equity mix, pick an underwriter, accept the quote) that a founding scenario already uses; the resolved cap table and treasury boot the session. Standalone skips the setup screen entirely and (where the scenario is a founding scenario) may still present the founding screen with scenario-locked inputs, or boot a pre-established company with no founding step.

Tutorial (Front-Door Placeholder, M18)¶

At M18 the Tutorial front-door entry is a reserved, disabled placeholder — its real estate is held so the eventual M21 rebuild slots into a settled layout, but it launches nothing. It reads as clearly non-interactive and "coming soon": dimmed/inactive styling that fails the eye's "this is clickable" test, a "coming soon" label, and — critically for the co-primary input rule — it is skipped by the controller focus chain and the mouse cannot activate it (a disabled control that still took focus or click would be a co-primary defect). It is present so players see the mode is planned, absent from the set of things that can actually start a game.

Map Availability¶

Maps authored for Campaign or Standalone scenarios can be made available for Free Scenario play. Two approaches work, both fine:

Per-mode flag in the map definition — a single authored map carries a flag indicating whether it supports Free Scenario play.
Separate Free Scenario copies — when scenarios are authored, the map is copied into a Free Scenario collection and edited as needed (typically removing scripted goal hooks and character-specific lock-ins).

The end result is the same: any game map the design supports can be loaded in Free Scenario.

End Conditions¶

Campaign and Standalone scenarios end when scripted goals succeed, fail, or expire.
Free Scenario has no scripted end. The player decides when to stop. There are no failure conditions; if the player's company collapses badly, they may end up soft-locked (no path to recovery without resetting). In that case the player exits and starts over, or loads an earlier save. The mode is intentionally permissive — its purpose is open exploration, not goal-driven challenge.

The Objective Shape (POC form, M19_B)¶

A scripted scenario's end conditions are authored in an optional sibling data file (data/scenarios/<id>/objectives.json → ScenarioObjectivesDef), read at boot; a scenario with no such file is endless (the Free-Scenario default). The POC objective shape — deliberately minimal, one honest completable arc, not the full authored-goal system a mature campaign will grow into — carries three parts:

End-date terminal — a scripted calendar date at which the run halts (reusing the Sim-to stop machinery). At the terminal, the win goal is evaluated once and the verdict shown. The end date is the scenario's horizon, not a failure in itself.
Win goal — one metric at-or-above a threshold, drawn from a small closed set the services already compute daily: treasury (TreasuryAtOrAbove), settlements connected (SettlementsConnectedAtOrAbove), or active contracts (ContractsActiveAtOrAbove). One metric, one threshold: the stranger's whole charge is legible in a sentence. The goal is calibrated to the scenario's empirically measured achievable arc — reachable by a competent player, not by doing nothing.
Receivership early-loss — a solvency floor plus a consecutive grace-day count. If the treasury sits at or below the floor for N consecutive days, the run ends early in Receivership. Grace-days (not the floor level alone) are the discriminator between a thin-but-solvent company and one that has genuinely collapsed: a failing road is pinned at the floor for hundreds of days, while a competent one at most grazes it. The floor is authored to catch real insolvency with zero false-trigger on a competent player.

The terminal presents a Class-5 modal verdict — one of Goal Met (green), Not Met (amber), or Receivership (red) — a word paired with a color, plus ~5 explainable finish numbers (no composite score; every number is one the sim already shows in-session). Two exits: Return to Title and Keep Playing (dismisses the terminal and continues the session endlessly, per Pillar 6 — a delegating player who fell short is never forced to stop). The concrete calibrated values for michigan_1920s (goal metric/threshold, horizon date, solvency floor/grace) are scenario-authored data and re-tuned as the economy is tuned — most recently by M20, which raised the connected-settlements goal so the win requires at least one full connect → payback → reinvest cycle.

Design position (pinned): the POC win goal is active-play-winnable, delegation never punished — a fully-delegating player legibly falls short (Not Met, neutral, not a loss) but is never forced to stop and never trips Receivership. Pillar 5 (the goal must demonstrate the manage-or-fail arc) is the tie-breaker over a naive Pillar 6 read; Pillar 6 is honored by the non-punishing exit.

The mature system (post-POC) generalizes this shape — multiple goals, authored buffs/penalties keyed on outcome, expiry vs. failure distinctions — but the POC ships the minimal honest form: one goal, one floor, one horizon.

The Front Door — Title Screen and Mode Selection¶

The game opens on a title screen (the session-boundary surface — see UIArchitecture — The Surfaces), which surfaces five top-level entries. The three canonical game modes are surfaced directly — Standalone and Free Scenario are not collapsed under a "Scenarios" umbrella, because they are mechanically distinct (Free Scenario carries a full player-setup flow; Standalone locks it):

Campaign — the Campaign list. Scaffold-only at M18: the campaign machinery (schema, unlock/progression, progress persistence) exists, but no campaign content is authored yet (only two playable seeds exist and there is no scripted sequence). The list honestly renders "No campaigns available yet." This is deliberate scaffold-now-fill-later, not a fake progression.
Standalone — pick one scripted scenario from the scenario catalog and boot it with the scenario's authored starting state (no player setup — the scenario locks it).
Free Scenario — the full player-setup flow (name / traits / HQ / era / cash), then boot. Consumes the same catalog metadata as Standalone, filtered to Free-eligible maps.
Tutorial — a reserved placeholder entry at M18. The button occupies its front-door real estate but is disabled and reads "coming soon," clearly non-interactive (see Tutorial button state). The tutorial's real rebuild is its own milestone (M21) on the settled data-first shell; M18 does not rebuild it.
Options — the settings surface: audio, accessibility, and per-device control rebinding (the Controls panel is the only sanctioned home for control hints), plus a fullscreen toggle. Per-category stop rules are a gameplay-scoped Settings section, deferred out of the front-door Options at M18.

Alongside the five entries, the title screen offers Load and Continue (resume the most recent save) into the existing save/load model.

The title screen also carries the game's visual cover: it lives in the full hand-drawn map register (parchment, ink, period serif, cartographic furniture), not the legibility-first office register the in-session data UI uses — it is the one surface the player meets before any office exists (per UIArchitecture).

Campaign Structure¶

A campaign is an ordered, unlock-gated sequence of scenarios with authored carryover — the data layer that lets a campaign author express narrative continuity across multiple sittings. The design pins the shape so the machinery can ship (and honestly show no content) ahead of any authored campaign:

A campaign is a named, authored entity (a manifest — see scenario metadata for the sibling per-scenario shape). It carries: a display name, description, and an ordered list of stages.
A stage references a scenario (by catalog id) plus its unlock rule and its carryover contract:
Unlock rule — what gates the stage. The default is linear (stage N unlocks when stage N−1 is completed); the schema also allows explicit prerequisites (a stage unlocks when a named set of earlier stages is completed) so an author can branch. The first stage is always unlocked.
Carryover contract — the explicit, authored state that flows from earlier stages into this one, per Goodwill — Carryover Across Scenarios: the player character's reputation and personal assets carry per those rules; anything beyond that (scripted buffs/penalties keyed on an earlier stage's outcome) is authored on the stage, never an automatic copy of prior company state. A stage declares which outcomes of which prior stages it reads.
Progression / unlock model — the campaign is a state machine over its stages: each stage is Locked → Unlocked → InProgress → Completed (with a distinct Failed/Expired terminal where the scenario's end conditions allow it and the author gates on it). Completing a stage re-evaluates every locked stage's unlock rule.
Progress persistence — a campaign's progress is a save-adjacent record keyed by campaign id: which stages are in each state, and the carryover payload captured at each completed stage (the player-character reputation/assets snapshot the next stage consumes). This is distinct from an in-scenario save (which restores a single GameSession); the campaign record is what the Campaign list reads to render "continue campaign / next stage available / N of M complete," and what a stage boot consumes to seed carryover. With no authored campaigns, the record set is empty and the list shows the placeholder.

This is a schema + progression + persistence pin, not content. Content authoring (an actual scripted Michigan sequence) is a separate, later effort.

Scenario Catalog and Display Metadata¶

Both Standalone (the picker) and Free Scenario (the setup screen's map choice) consume a scenario catalog — an enumeration of the shipped scenarios plus per-scenario display metadata. The metadata is net-new (the scenario data files today carry no display name, description, or difficulty); it is authored in JSON per the data-in-JSON rule, one manifest per scenario (or a single catalog file). The design pins the shape each consumer reads:

id — the scenario id (the existing data/scenarios/<id> key that boots a GameSession).
displayName — player-facing title (distinct from the internal id).
description — a short framing paragraph (the historian grounds the copy).
difficulty — an authored difficulty framing (e.g. an ordinal band the picker renders; not a computed number).
modeEligibility — which modes may launch this scenario: Standalone (has authored scripted starting state / goals), Free (map is flagged for Free Scenario play — player setup replaces the scripted start), or both. This is the per-scenario expression of the Map Availability flag, at catalog granularity: the Standalone picker lists Standalone-eligible entries; the Free-Scenario map list lists Free-eligible entries.
preview (optional) — a preview affordance (a map thumbnail or key-facts block) the picker may render; absence renders a graceful fallback.

Campaign stages reference catalog entries by id; a scenario appearing in a campaign does not need to be independently Standalone-eligible (a campaign-only scenario is legitimate). The catalog is also the enumeration that does not exist in the codebase today — nothing currently lists data/scenarios/.

Implementation Stack¶

Engine: Godot. Open-source, MIT-licensed (no royalties or revenue share), well-suited to 2D vector-heavy strategy games. Mature 4.x release with a strong indie ecosystem (notable Steam-published titles include Brotato, Cassette Beasts, Dome Keeper, Cruelty Squad, Halls of Torment).
Language: C#. Fully supported in Godot 4 through the .NET integration. Strong fit for the simulation-heavy backend logic and editor integration; can interop with GDScript for engine-facing scripting where useful.
Target Platforms: PC and Steam Deck, both treated as primary from day one. PC means Windows / Mac / Linux desktop; Steam Deck runs on Linux and is reached through Godot's native Linux export. Web export is possible but not a priority for initial release.
Controller support: required and first-class. The game ships with full controller support on day one. Every interaction surface — hover tooltips, drag-and-drop fleet allocation, tabular commodity browsers, drilldown panels — has a controller-mapped equivalent. Mouse-and-keyboard remains supported on PC but is not assumed by the design. The "summary at a glance, detail on demand" UI pattern documented across the deep-dive docs maps cleanly to a controller-driven flow once button-press detail toggles, list-based selection, and highlight-and-confirm interactions are authored as the controller equivalents of mouseover/drag patterns.
Steam Deck compliance: targeting Steam Deck Verified. Requirements include full controller support (no required mouse interactions), UI legibility at the Deck's 7" 1280×800 screen, default text and color choices that meet small-screen accessibility, and compatibility with the Steam Deck Linux runtime (Godot's native Linux export handles this). Steam Deck Playable is the fallback if Verified proves out of reach for first release.
Distribution: Steam as the primary store. Godot games publish on Steam without engine-level barriers; Steamworks integration (achievements, cloud saves, leaderboards, Workshop) goes through GodotSteam or equivalent C# binding.
Authoring tools (map procedural generation, scenario scripting, commodity and industry templates, etc.) are separate authoring-time tools, not shipped in the runtime. Same architectural pattern documented for map authoring — content is built externally and loaded by the engine.

Document Map¶

All design docs live in this docs/ folder.

index.md — One-page elevator pitch for the game (the site home page).
Pillars.md — Seven core design principles that guide every decision.
GDD.md (this file) — High-level overview and how the core systems connect.
MapAndRegions.md — Map aesthetic, region types, capitals and infrastructure tiers, the rail line cost model, network growth.
Populations.md — Regional populations, interest groups, and the gameplay effects they produce.
Economy.md — Commodity, pricing, and population-dynamics engine. Per-region per-commodity prices; consumer/industry staples and luxuries; industry production chains.
Goodwill.md — Player and company reputation systems.
PlayerSetupTraits.md — Free-Scenario setup-trait catalog + setup-field ranges; the trait-driven founding-standing seed.
ProjectManagement.md — Project commissioning, staff execution, line-item costs.
Operations.md — Ongoing per-region operations and maintenance: regional cost computation, suspension levers, stacking debuffs, self-heal.
BusinessDealings.md — Bonds, company stock, equity in others, contracts.
Procurement.md — Sourcing locomotives, rolling stock, materials, technology licenses, and skilled labor. Tiers, market structure, named/generic suppliers, fleet capacity, contract triage.
InformationAndCommunication.md — Cross-cutting information-lag system (post / telegraph / telephone).
Events.md — Pause-time event system: lifecycle, default choices, time pressure, and how lag interacts with option availability.

Open Questions¶

All major design questions are currently resolved across the doc set. The remaining work is implementation, content authoring (specific commodity prices, industry production rates, scenario-specific content), and playtesting to tune the dozens of scenario-tunable values noted across the deep-dive docs.