Files
settled-reach/docs/workshops/world-generation/gestalt-sw1r3.md
T
jpmschweitzerandClaude Opus 4.6 252e3d380a docs(workshops): complete world generation architecture workshop
3 rounds of SW1 (endgame feature vision) with 5 agents + Qatux.
Produced endgame-feature-vision.md (692 lines) covering the full
galaxy-to-ground generation pipeline, cultural cascade, replayability
architecture, and player experience beats.

Workshop was cut short when PO redirected to a 6-phase development
cascade (wiki content → economics → planetary maps → player control →
world gen → detail coloring). v0.2 target dropped. Heritage roots
(D-104/D-105/D-101/D-107) flagged for supersession — real-world
cultural corridors replace abstract roots.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
2026-03-24 17:12:09 +01:00

19 KiB
Raw Blame History

title, agent, workshop, round, type, created
title agent workshop round type created
SW1-R3: Gestalt — Endgame Feature Vision, Systems Design gestalt world-generation 3 endgame-vision 2026-03-24

SW1-R3: Gestalt — Endgame Feature Vision

Angle: Systems design. How the generator produces information; how the simulation propagates it; how the player reads and exploits it.

Format: Declarative endgame vision. "The system does X." Not proposals.


1. The Information Cascade: System Profile to Room Interior

The generator is a reader-and-filler. It reads rich authored inputs at the top of the cascade and produces specific spatial expression of that data at the bottom. At every level, economic context flows downward as constraints that determine what the level below can produce.

The cascade chain

Galaxy (systems.db)
  ↓ economic profile: supply dependencies, distribution_index, faction roles,
    bulk import/export lists, industrial corridor overlay
Location profile (wiki)
  ↓ population, economic role, founding age, settlement pattern,
    cultural corridor, settlement trajectory
Authored topography (heightmap PNG + metadata JSON)
  ↓ hard constraints: coastlines → port districts, rivers → district boundaries,
    mountains → blocked movement corridors
Settlement placement
  ↓ district count and type distribution derived from location economic profile
    + topographic placement constraints
District skeleton (Phase 1)
  ↓ ZoningType, ZonePalette (EconomicModifier + ConditionModifier + cultural corridor
    identity), access tiers, density, era cause, social sites
Room fill (Phase 2)
  ↓ full simulation primitives: monthly turnover, cost, employee count, staff, visitors
    painted with current simulation pressure state

The cascade rule

Every economic axis in the system profile produces at least one visible attribute at district level, which produces at least one visible attribute at room level. If an axis doesn't cascade visibly, it isn't a generator input — it's database weight.

A concrete cascade: Extractive economy

Level Extractive economy signal
System distribution_index: Extractive (value leaves, workers stay)
Location High population, low average prosperity, corporate faction dominant
District EconomicModifier: Extractive — worn condition, corporate security presence, limited recreational zones
Block High density, few public amenities, transit-heavy layout
Room Functional furniture (workers choose utility, not comfort), notice boards with union/corporate tension items, NPC behavioral tells of economic stress, bar monthly turnover reflects suppressed disposable income

The player who walks into that bar and reads the room is reading the system's economic structure backward from the furniture. That is the game.

Bulk import/export lists as the content bridge

Each system's bulk import/export lists serve double duty: they inform the trade flow simulation (what moves between systems, what creates dependency relationships) and they determine what's on store shelves in that system's commercial districts. A system that imports pharmaceuticals has pharmacy stock. A system that exports ore has industrial supply shops. The store content is not separately authored — it derives from the same economic data that drives the simulation. Wiki and simulation share a single source of truth.


2. Background Simulation → Generation Pipeline

Architecture

The background simulation runs in tokio async tasks, outside the bevy_ecs main loop. It operates on aggregate data — per-system and per-settlement economic health, faction balance, social tension indicators. It does not query per-entity ECS state.

The simulation advances on a deterministic game-minute clock. Variable CPU availability produces simulation debt, not variable world states. Slower hardware catches up; it never produces different outcomes. This satisfies D-010 (determinism).

What the simulation produces: a pressure state

For each settlement, the background simulation maintains:

Pressure dial Range What drives it
economic_health Prosperous / Stable / Faltering / Declining Trade flow balance, import/export dependency chains, corporate facility presence
faction_dominance Per-faction influence score Political pressure, economic investment, player actions at that system
social_tension Low / Elevated / High / Critical Distribution_index, economic_health trajectory, faction conflict
development_trajectory Growing / Stable / Stagnating / Declining Investment flows, population change, infrastructure state

How events propagate through the network

Any event that changes a dial on one system propagates through the trade and political network to connected systems. The network IS the propagation mechanism.

A corporate disaster at a manufacturing hub ripples outward: systems that import from that hub experience supply shortages (economic_health ↓). Systems that compete with the hub gain market share (economic_health ↑). Faction balance shifts in both directions as the corporate power player weakens. Portal closings redirect trade flows. Political shifts change faction influence scores across connected systems.

The propagation strength decays with network distance. Adjacent systems feel the full ripple. Systems three hops away feel an attenuated version. The Reach's wormhole topology shapes what events propagate where — gate topology is not just travel infrastructure, it is the information and economic nervous system of the world.

Equilibrium is signal, not failure

When a simulation reaches a stable state, that stability is legible information for the player. A system in equilibrium tells the player: nothing is disrupting this place right now. The player can then read that as opportunity (exploit the stable situation) or as context (understand why this place is as it is). A player who returns to a system that was faltering and finds it stable knows something changed — and can investigate what.

The propagation network ensures that stability in one place is almost always instability somewhere else. There is no global equilibrium, only local ones.

Painting the canonical state with pressure state

The generator produces the canonical starting state from authored inputs. The background simulation produces the current pressure state. On player arrival at a location, the generation pipeline paints the canonical structure with current pressure state modifiers.

Concretely: the commercial bar's canonical state (layout, furniture, room grammar) is derived from the district's cultural corridor identity and founding biography. The current state of that bar's simulation primitives (monthly turnover, staff count, visitor density) is derived from the current economic_health and faction_dominance pressure dials for that settlement.

A canonical Commonwealth bar in a faltering settlement has the same spatial grammar as one in a prosperous settlement — the sightlines, the privacy configuration, the gathering orientation are culturally stable — but its economic primitives and NPC behavioral tells differ. The culture is archaeology; the economics are current events.

NPC-driven and news-driven generation hooks

Two events can trigger generation outside of player movement:

NPC-driven: When the player's relationship with an NPC crosses a depth threshold (determined by interaction frequency and quality), the NPC's home neighborhood generates at their stated location. The NPC's address becomes a real visitable place. The neighborhood generates using the cultural corridor and settlement biography of that location, then applies the current pressure state. The generator is called by the social simulation layer, not by player proximity.

News-driven: When the storyteller fires a Reach-wide news event that names a location (gas main explosion in a Tau Ceti settlement district), a generation existence claim is registered for that location. When the player travels to that system and district, the generator resolves the existence claim before the player arrives. The event's physical consequence (rubble, memorial, burn marks) exists in the world because the simulation produced the event, not because the generator fabricated decoration.

Both hooks require a consistency buffer: a data structure that records unresolved existence claims and resolves them on the generation trigger. The simulation fires the claim; the generator resolves it; the player finds the evidence.


3. NPC Universality: Minimum Data Bundle

Every NPC generated at Phase 2 carries the following minimum data bundle:

Field Source Purpose
npc_stable_id Deterministic hash of (district_id, spawn_index) Stable cross-session identity
cultural_corridor Settlement corridor identity Room grammar behavioral tokens: stranger_distance, group_size_prior, noise_level_prior
founding_culture Settlement founding biography Object palette selection at Layer 3 (intra-corridor specificity)
economic_role Zone function + economic_health What they do here, what economic pressure they're under
prosperity_tier Inherited from district pressure state Wealth signal, stress indicators, behavioral tells
relationship_seeds Compact graph: (workplace, ±2 family, ±3 social affiliations) Expandable into full relationship graph when player threshold triggers
tell_config TellCategory + culture_id (D-138 voice pipeline) Voice re-voicing, animation behavioral tells
biography_stub Founding corridor + settlement trajectory tag Enough to generate coherent history on demand
triangle_capacity Boolean + prerequisite conditions Whether this NPC can enter a triangle; what conditions activate it

The ambient/narrative distinction collapses in the data

The distinction between "ambient" and "narrative" NPCs is not a data distinction — it is a simulation fidelity distinction. Ambient NPCs run on background tier (game-minute tick). Narrative NPCs run on active tier (10tps tick). The minimum bundle is the same for both.

What differs is simulation depth: ambient NPCs' relationship graphs are not expanded. Narrative NPCs have full relationship graphs, full biographical histories, triangle assignments, and possibly neighborhood generation at their home location.

The expansion is triggered by player attention, not by generator designation. Any NPC the player takes sufficient interest in becomes a narrative NPC. The generator never decides this in advance.

On-demand expansion

When the player's interaction with an NPC crosses the depth threshold:

  1. Relationship graph expands: the compact seed generates a full relationship graph (family, colleagues, social affiliations, faction memberships)
  2. Biographical history generates: the biography_stub produces a coherent life history consistent with the settlement founding biography and current pressure state
  3. Triangle capacity activates: if triangle_capacity conditions are met, the NPC enters the simulation as a potential triangle participant
  4. Neighborhood generates (if distant): if the NPC's stated home is in a different settlement, the NPC-driven generation hook fires

The expansion is invisible to the player. From the player's perspective, they paid attention to someone who turned out to be real.


4. The LOD Principle: Depth Scales with Player Engagement

Four simulation depth tiers

Tier Trigger What exists
Unvisited Location exists in systems.db or wiki System-level aggregate data: economic tier, faction, cultural corridor, GTTR entry
Scouted Player arrives (GTTR insert window opens) Location profile + Phase 1 district skeletons. System stats + planetary screenshot.
Visited Player enters a district Full Phase 2 room fill. NPCs generated with minimum bundle. Simulation primitive baseline (monthly turnover, cost, employee count) from current pressure state.
Engaged Player establishes NPC relationship / recurring economic transaction Full NPC profile expansion. Triangle formation. NPC-driven neighborhood generation if applicable.
Invested Player owns or operates a business in this location Full business simulation: staff scheduling, supply chain, competitor pressure, regional prosperity coupling. Player's choices directly affect the location's economic_health dial.

LOD transition rules

Transitions upward (Unvisited → Invested) are triggered by player engagement. They are permanent — once a location is Visited, it remains Visited across all future sessions.

Transitions downward do not reduce the data — they reduce the simulation fidelity. When the player leaves a district, Phase 2 chunk data persists. NPC relationship graphs persist. Business simulation primitives persist and continue to be driven by background simulation at reduced fidelity.

When the player sells a business, the business demotes from Invested to Visited: a state snapshot is captured, the location continues to exist as an L2 simulation primitive, and the ex-owner's relationship with the location (former owner, local reputation) continues to be tracked.

Business simulation depth at Invested tier

A player-owned bar at Invested tier tracks:

Primitive Driven by
Monthly turnover Regional economic_health × location foot traffic × player's pricing decisions
Operating cost Staff count × local wage levels × supply costs from import lists
Employee roster Named NPCs (generated with full bundle) on schedules
Visitor roster Zone-baseline foot traffic + relationship-driven visits (NPC friends come to the bar the player owns)
Competitor pressure Adjacent commercial social sites' economic health affects foot traffic share
Supplier relationships Import/export lists drive supply availability and cost

The player's bar is not isolated from the simulation. Its profitability is coupled to the regional pressure state. A system in economic decline sees the bar's turnover drop. A corporate disaster that disrupts the supply chain raises the bar's operating costs. The player's business is a participant in the simulation, not a sandbox separate from it.


5. Remaining Open Questions

Three questions remain unresolved after the R2 follow-up interview. All three need answers before the relevant pipeline components can be specified.

Q1: What is the minimum NPC data bundle — specifically, what must be generated at Phase 2 vs expanded on demand?

The minimum bundle described in Section 3 is a design target. What needs engineering confirmation: which fields can be generated lazily (on first access) vs which must be generated eagerly at Phase 2 fill time?

The voice pipeline (D-138) requires tell_config at generation time — that much is confirmed. The relationship_seeds compact graph needs to be present before the player can see NPC behavior in the room. But does biography_stub need to be generated at Phase 2, or can it generate on first player interaction?

The answer determines Phase 2 generation cost per NPC and save file size per district.

Q2: Does NPC-driven generation produce canonical or seeded neighborhoods?

When the player befriends Kael from Tau Ceti and Kael's neighborhood generates — is every player who befriends a Tau Ceti resident routed to the same canonical neighborhood (consistent with the wiki-authored district structure), or is Kael's specific address procedurally unique per run?

Canonical: Same neighborhood for all players who reach that depth with a Tau Ceti contact. Creates shared reference points: "I know the Docklands district in detail." Consistent with the wiki-authored world.

Seeded per run: This specific Kael's neighborhood is unique. Different players' versions of "Kael's neighborhood" differ. Creates personal per-run content.

The design consequence: canonical is consistent with the "reader-and-filler" architecture (generator reads authored inputs, produces the same output for the same inputs). Seeded is a divergence from that architecture — it requires the generator to produce per-run variation at neighborhood level even though the top-level world is canonical.

The product owner's answer here determines whether NPC-driven generation creates shared player reference points or unique personal worlds.

Q3: What is the pre-play simulation strategy?

Before the player's first move, how much background simulation has run? The options range from pristine canonical state (no pre-play sim) to fast-forward sim to pre-authored canonical events seeded into the starting state.

This is load-bearing for environmental archaeology: if the simulation hasn't run before the player starts, the world has no physical traces of events. Every location is in its founding state. A new player's first location is pristine in a way that feels thin.

The background simulation design workshop is the right venue for this, but the answer should inform the workshop brief as a constraint: the workshop must produce a starting state seeding strategy, not just a steady-state propagation model.


Systems Summary

The generator does:

  • Reads systems.db, wiki location profiles, authored heightmaps, and GTTR entries
  • Produces Phase 1 district skeletons from authored inputs + cultural corridor data
  • Produces Phase 2 room fill from Phase 1 skeletons + current pressure state
  • Generates every NPC with a universal minimum data bundle
  • Paints canonical structure with current simulation pressure state on player arrival
  • Resolves NPC-driven and news-driven existence claims before player arrival

The simulation does:

  • Runs economic + social + political pressure models in tokio background tasks
  • Propagates events through the trade/political network (the propagation IS the variety)
  • Produces settlement-level pressure dials that the generator reads as painting instructions
  • Drives all simulation primitive values (turnover, cost, staff, visitors) for Visited+ locations
  • Runs at lower fidelity for unvisited locations; increases fidelity as player engagement increases
  • Uses deterministic game-minute clock (D-010 compliant — no wall-clock non-determinism)

The player does:

  • Reads the world backward from the room to the system: furniture → district economics → system power structure
  • Exploits asymmetric information: what they know that other characters don't, what they can see that tells them more than the NPC admits
  • Chooses which NPCs to pay attention to (converting ambient to narrative through attention)
  • Acts in ways that propagate through the simulation network: buying a bar, disrupting a supply chain, changing faction balance
  • Returns to places to find them changed by the simulation, and reads why