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>
This commit is contained in:
Claude Opus 4.6
@@ -2,7 +2,7 @@
|
||||
title: "World Generation Architecture Workshop"
|
||||
description: "Design the procedural world generation pipeline — from Rust server layout generation to Godot client rendering. Covers urban, rural, wilderness, and station interior zones."
|
||||
type: workshop
|
||||
status: draft
|
||||
status: complete
|
||||
agents: "TYRE, GESTALT, NIGEL, MIRI, OZZIE"
|
||||
---
|
||||
|
||||
@@ -48,6 +48,7 @@ These are Godot plugins studied for patterns — the generation itself happens i
|
||||
| [PathMesh3D](https://github.com/iiMidknightii/PathMesh3D) | Extrude 2D profiles along paths (pipes, cables, corridors) | Station interior detail |
|
||||
| [DeformableMesh](https://github.com/cloudofoz/godot-deformablemesh) | Runtime mesh deformation for variety from shared assets | Environmental variation |
|
||||
| [Poly Haven](https://polyhaven.com) | CC0 3D models, textures, HDRIs | Environment asset sourcing |
|
||||
| [SunshineClouds](https://github.com/Bonkahe/SunshineClouds) | Cloud shadow dappling on ground surfaces | Exterior zone atmosphere (borrow the ground shadow shader, skip the sky) |
|
||||
|
||||
## Questions to resolve
|
||||
|
||||
|
||||
@@ -0,0 +1,692 @@
|
||||
---
|
||||
title: "Endgame Feature Vision — World Generation"
|
||||
author: qatux (compiled from SW1-R3 agent outputs)
|
||||
workshop: world-generation
|
||||
date: 2026-03-24
|
||||
status: complete — pending PO review
|
||||
sources:
|
||||
- gestalt-sw1r3.md
|
||||
- nigel-sw1r3.md
|
||||
- ozzie-sw1r3.md
|
||||
- miri-sw1r3.md
|
||||
- tyre-sw1r3.md
|
||||
- sw1-interview-answers.md (including R2 follow-up)
|
||||
---
|
||||
|
||||
# Endgame Feature Vision — World Generation
|
||||
## The Settled Reach — Sub-Workshop 1 Synthesis
|
||||
|
||||
---
|
||||
|
||||
## 1. Vision Statement
|
||||
|
||||
The Settled Reach generates a galaxy of 300 canonical, authored systems and simulates it forward
|
||||
continuously. The world is real before the player arrives. Every room in every district of every
|
||||
settlement is a spatial expression of economic, cultural, and historical forces that the player
|
||||
can read backward from the furniture — from the bar's monthly turnover to the district's faction
|
||||
politics to the system's position in the Reach-wide trade network.
|
||||
|
||||
The economic simulation is modeled on **X4: Foundations** — station-level production chains,
|
||||
bulk commodity trade between systems, supply/demand price discovery, NPC-owned enterprises
|
||||
competing for resources and markets. Adapted to our 300-system scale, running on spare CPU
|
||||
cores as background tokio tasks. The simulation propagates events through the interconnected
|
||||
trade and political network so that when the player arrives anywhere, they find a situation,
|
||||
not a tableau.
|
||||
|
||||
Replayability comes from who the player is, where they go, who they know, and what they do —
|
||||
the background simulation amplifies and responds to player action, it doesn't replace it.
|
||||
The world was already there. The player shows up and finds it.
|
||||
|
||||
---
|
||||
|
||||
## 2. The Pipeline — 8 Layers
|
||||
|
||||
### Layer Status Overview
|
||||
|
||||
```
|
||||
Layer 1: Galaxy (300 systems) ██████████ BUILT — systems.db + wiki + star map
|
||||
Layer 2: Location profiles ░░░░░░░░░░ AUTHORED — wiki pipeline, not generated
|
||||
Layer 3: Planetary topography ░░░░░░░░░░ AUTHORED — annotated heightmaps + metadata
|
||||
Layer 4: Inbound gateways ████░░░░░░ DESIGNED — D-093/D-095, template stamped
|
||||
Layer 5: Content spidering ████░░░░░░ ARCH BUILT — D-026 tiers + chunk streaming
|
||||
Layer 6: Settlement generation ░░░░░░░░░░ NOT BUILT — placement on authored terrain
|
||||
Layer 7: District → building ███░░░░░░░ DATA MODEL — generator.rs, no algorithms
|
||||
Layer 8: 2D → 3D rendering ███░░░░░░░ MIGRATING — D-148/D-149 in progress
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### Layer 1 — Galaxy (systems.db)
|
||||
|
||||
**300+1 canonical systems.** Same wormhole topology every run. Earth is border-locked. The galaxy
|
||||
does not regenerate; it is a place with a permanent geography that players learn over multiple
|
||||
runs and retain as durable knowledge.
|
||||
|
||||
Each system carries: economic profile (supply dependencies, distribution_index, faction roles,
|
||||
bulk import/export lists), industrial corridor overlay (MVG / Gate Corp / DSMC / Prometheus /
|
||||
Agricultural Syndic presence), cultural corridor identity (Commonwealth North, Iberian/LatAm South,
|
||||
East Asian East, Germanic/Scandinavian West), and a GTTR narrative entry.
|
||||
|
||||
**Bulk import/export lists** serve double duty: they drive the trade flow simulation (what moves
|
||||
between systems, what creates dependency relationships) and they determine what's on store shelves
|
||||
in every commercial district of that system. Wiki and simulation share a single source of truth.
|
||||
A system that imports pharmaceuticals has pharmacy stock. A system that exports ore has industrial
|
||||
supply shops.
|
||||
|
||||
The galaxy map is visible in full from minute one. Every dot is a named, storied system. The player
|
||||
is not discovering an unknown space — they are navigating a place that people have been living in
|
||||
for generations, and the guide entries prove it.
|
||||
|
||||
---
|
||||
|
||||
### Layer 2 — Location Profiles (wiki)
|
||||
|
||||
**Every planet, moon, and station in all 300 systems has an authored wiki profile.** The generator
|
||||
reads this data; it does not generate it. The wiki is the world's canonical record.
|
||||
|
||||
Profile fields include: population, economic role, founding age, settlement pattern, cultural
|
||||
corridor, settlement trajectory, and the GTTR narrative entry (authoritative voice + statistics +
|
||||
art). The planetary shader generates visual screenshots (earthlike, jungle, desert, mars-like,
|
||||
ocean, etc.) that appear in both wiki pages and the diegetic GTTR arrival window.
|
||||
|
||||
```
|
||||
LocationProfile
|
||||
├─ location_type: Planet | Station | Moon | Orbital | AsteroidBase
|
||||
├─ physical: gravity, atmosphere, biome_summary, terrain_reference (→ Layer 3 heightmap)
|
||||
├─ settlement: population, economic_role[], founding_age, founding_culture
|
||||
├─ cultural: cultural_corridor (from systems.db), heritage_persistence, industrial_corridor
|
||||
├─ infrastructure: spaceport_class, transit_connections, district_count
|
||||
├─ economy: industries[], power_players[], trade_imports[], trade_exports[]
|
||||
└─ narrative: gttr_entry_path, planetary_screenshot_path, arrival_type_default
|
||||
```
|
||||
|
||||
This layer is the authored backbone of the cascade. Everything below derives from it.
|
||||
|
||||
**Engineering cost:** 1-2 weeks (wiki markdown → LocationProfile parser + validator). For
|
||||
stations and orbitals: no heightmap — module topology is authored as structured JSON.
|
||||
|
||||
---
|
||||
|
||||
### Layer 3 — Topography (authored heightmaps)
|
||||
|
||||
**Every planet and moon has an authored world map:**
|
||||
|
||||
```
|
||||
heightmaps/
|
||||
GJ-699/
|
||||
proxima-b/
|
||||
heightmap.png # Grayscale 16-bit PNG. Elevation data.
|
||||
metadata.json # Scale, origin, resolution, sea_level, units
|
||||
rivers.png # Binary overlay: river channels
|
||||
coastlines.png # Binary overlay: coastline boundaries
|
||||
biome_zones.json # Named polygon regions + biome type per region
|
||||
settlements.json # Settlement center points + approximate radius
|
||||
screenshot.png # Planetary shader screenshot for GTTR/wiki
|
||||
```
|
||||
|
||||
Topography is a **hard constraint** on generation. Mountains block corridors. Rivers create district
|
||||
boundaries. Coastlines produce port districts. Geography creates the spatial reasoning the player
|
||||
can exploit — the river that bisects the commercial district always bisects it. Players learn
|
||||
these constraints once and apply them across runs.
|
||||
|
||||
The heightmap feeds district placement constraints directly. Cultural geography layers on top:
|
||||
first-wave settlers take their preferred terrain; later settlement waves adapt. The result is
|
||||
a settlement pattern that is spatially and culturally legible from orbital view — a Commonwealth
|
||||
world's settlements cluster around institutional centers; an Iberian/LatAm world's settlements
|
||||
follow water and extended-family sprawl.
|
||||
|
||||
**Engineering cost:** 2-3 weeks (heightmap ingestion + constraint extraction + caching, ~50-200KB
|
||||
per planet in MessagePack).
|
||||
|
||||
---
|
||||
|
||||
### Layer 4 — Arrival / Gateway
|
||||
|
||||
**Arrival is contextual by transit method and diegetically rich.**
|
||||
|
||||
| Transit method | First impression |
|
||||
|---------------|-----------------|
|
||||
| Charter flight | Port arrival — infrastructure, scale, the world's public face |
|
||||
| Gate transit | Station interior — institutional, Commission inspection, rules before character |
|
||||
| Smuggler route | Low orbit in the dark — overview before intimacy, geography as first fact |
|
||||
|
||||
On every arrival, the player's insert opens an GTTR context window automatically: system stats,
|
||||
a planetary screenshot (from the authored heightmap + shader), and the GTTR narrative entry.
|
||||
The guide entry sets expectations. The world then has to cash the cheque.
|
||||
|
||||
Information asymmetry begins at the insert window. The player knows what the guide says. They
|
||||
don't yet know whether the guide's description is still true — the simulation may have moved the
|
||||
world significantly since the entry was written.
|
||||
|
||||
---
|
||||
|
||||
### Layer 5 — Content Spidering / LOD / Simulation Tiers
|
||||
|
||||
**The world generates on demand, in response to three kinds of triggers: player movement,
|
||||
social depth, and narrative events.**
|
||||
|
||||
| LOD tier | Trigger | What exists |
|
||||
|----------|---------|-------------|
|
||||
| Unvisited | In systems.db or wiki | System-level aggregate data: economic tier, faction, cultural corridor, GTTR entry |
|
||||
| Scouted | Player arrives (GTTR insert opens) | Location profile + Phase 1 district skeletons; planetary screenshot in insert |
|
||||
| Visited | Player enters a district | Full Phase 2 room fill; all NPCs generated with minimum bundle; simulation primitive baseline from current pressure state |
|
||||
| Engaged | Player forms NPC relationship / recurring transaction | Full NPC profile expansion; triangle formation; NPC-driven neighborhood generation if applicable |
|
||||
| Invested | Player owns or operates a business | Full business simulation: staff scheduling, supply chain, competitor pressure, regional prosperity coupling |
|
||||
|
||||
**Progressive generation trigger sequence:**
|
||||
|
||||
| Player Action | Generation Triggered | Latency Budget |
|
||||
|---|---|---|
|
||||
| Starts new game | Load systems.db. LocationProfiles for home system. Phase 1 + Phase 2 for starting district. | 2-5 seconds (acceptable) |
|
||||
| Enters transit to new system | LocationProfiles for destination. Phase 1 skeletons for destination + neighbors. | Hidden behind 5-30 second transit scene |
|
||||
| Arrives at destination | Phase 2 chunk fill for destination district. Activate NPCs. | <500ms total (BSP fills a chunk in <5ms; 8-chunk radius = ~40ms) |
|
||||
| Walks toward district boundary | Phase 2 for adjacent chunks, 2 chunks ahead. | Hidden behind walking time |
|
||||
| Enters building | LOD 0 → LOD 1: BusinessStats derived. Staff/patron NPCs spawned if first visit. | <50ms |
|
||||
|
||||
**The player never sees a "generating..." screen after new-game startup.** All subsequent
|
||||
generation runs during diegetic transitions that are already part of the game's pacing.
|
||||
|
||||
**NPC-driven generation hook:** When the player's relationship with an NPC crosses a depth
|
||||
threshold, that NPC's home neighborhood generates at their stated location. The address becomes
|
||||
a real visitable place. The generation is invisible to the player — the place just exists,
|
||||
with the character that NPC's cultural and economic background would produce.
|
||||
|
||||
**News-driven generation hook:** When the Reach-wide storyteller fires a news event naming a
|
||||
location ("gas main explosion in a Tau Ceti settlement district"), a generation existence claim
|
||||
is registered. When the player travels there, the generator resolves the claim before arrival.
|
||||
The physical consequence (rubble, memorial, burn marks) exists because the simulation produced
|
||||
the event, not because the generator fabricated atmosphere.
|
||||
|
||||
Both hooks require a **consistency buffer** — a data structure recording unresolved existence
|
||||
claims that the generator resolves on the appropriate trigger. The simulation fires the claim;
|
||||
the generator resolves it; the player finds the evidence.
|
||||
|
||||
Transitions upward in LOD are permanent. Once a location is Visited, it remains Visited. Chunks,
|
||||
NPC relationship graphs, and business simulation primitives persist and continue advancing at
|
||||
reduced fidelity during player absence.
|
||||
|
||||
---
|
||||
|
||||
### Layer 6 — Settlement Placement
|
||||
|
||||
**Settlement placement is constraint-solving against authored topography + wiki economics.**
|
||||
The district count and type distribution derive from the location's economic role and topographic
|
||||
placement constraints from the heightmap overlay data. Where settlements can plausibly go is
|
||||
determined by geography; what settlements look like is determined by economic profile.
|
||||
|
||||
Cultural geography layers the settlement pattern: early settlement waves take preferred terrain.
|
||||
Later waves adapt. The wave history visible in the settlement pattern is readable from above —
|
||||
it is not random.
|
||||
|
||||
---
|
||||
|
||||
### Layer 7 — District Skeleton (Phase 1) and Room Fill (Phase 2)
|
||||
|
||||
**Phase 1 (skeleton)** produces the district's block assignment, zoning types, social sites,
|
||||
era cause distribution, and guarantee audit. The Phase 1 structure is shared across all zone
|
||||
type families (Interior, Urban, Natural) — same 4×4 block grid logic, same guarantee tiers.
|
||||
|
||||
**Phase 2 (fill)** diverges per zone type family. Each block fills its chunks with tile-level
|
||||
content: rooms, corridors, objects. Every room is a full simulation primitive with LOD. A
|
||||
visited commercial bar carries: monthly turnover, cost, employee count, current staff and
|
||||
visitors. These are not static values — they derive from the current pressure state of the
|
||||
settlement.
|
||||
|
||||
**The cascade rule (Gestalt):** 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.
|
||||
|
||||
**The canonical Commonwealth bar in a faltering settlement** has the same spatial grammar as
|
||||
one in a prosperous settlement (culturally stable sightlines, privacy configuration, gathering
|
||||
orientation) but different economic primitives and NPC behavioral tells. Culture is archaeology;
|
||||
economics are current events.
|
||||
|
||||
---
|
||||
|
||||
### Layer 8 — NPC Population
|
||||
|
||||
**Every NPC generated at Phase 2 carries a universal minimum data bundle.** There is no separate
|
||||
category of "filler" NPC — every NPC is sufficient to become a narrative character if the player
|
||||
chooses to pay attention.
|
||||
|
||||
Minimum bundle fields:
|
||||
|
||||
| Field | Source | Purpose |
|
||||
|-------|--------|---------|
|
||||
| `npc_stable_id` | Deterministic hash of (district_id, spawn_index) | Stable cross-session identity |
|
||||
| `cultural_corridor` | Settlement corridor identity | Spatial grammar behavioral tokens |
|
||||
| `founding_culture` | Settlement founding biography | Object palette selection (Layer 3 intra-corridor specificity) |
|
||||
| `economic_role` | Zone function + economic_health | What they do, what 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 on depth threshold |
|
||||
| `tell_config` | TellCategory + culture_id | Voice re-voicing, animation behavioral tells (D-138 voice pipeline) |
|
||||
| `biography_stub` | Founding corridor + settlement trajectory tag | Coherent history generatable on demand |
|
||||
| `triangle_capacity` | Boolean + prerequisite conditions | Whether and how this NPC can enter a social triangle |
|
||||
|
||||
The ambient/narrative distinction is a simulation fidelity distinction, not a data distinction.
|
||||
Ambient NPCs run on background tier (game-minute tick). Narrative NPCs run on active tier (10tps).
|
||||
Both carry the same minimum bundle. Expansion is triggered by player attention, not by generator
|
||||
designation.
|
||||
|
||||
---
|
||||
|
||||
### Data Flow
|
||||
|
||||
```
|
||||
┌─────────────────────────────────────────────────────────────────────┐
|
||||
│ AUTHORED CONTENT │
|
||||
│ wiki/star-systems/ ──→ systems.db (300 systems, 7 tables) │
|
||||
│ wiki/locations/ ──→ LocationProfile[] (per planet/station) │
|
||||
│ heightmaps/ ──→ Terrain constraint cache (per planet) │
|
||||
│ wiki/gttr/ ──→ GTTR entries (per system) │
|
||||
└────────────────┬────────────────────────────────────────────────────┘
|
||||
│ loaded at game start
|
||||
▼
|
||||
┌─────────────────────────────────────────────────────────────────────┐
|
||||
│ RUST SERVER (bevy_ecs) │
|
||||
│ ┌──────────────────┐ ┌──────────────────────────────────┐ │
|
||||
│ │ Galaxy Graph │ │ Background Pressure Sim (tokio) │ │
|
||||
│ │ 300 system nodes │◄──►│ X4-style: trade flows, industry │ │
|
||||
│ │ gate topology │ │ Social: satisfaction, tension │ │
|
||||
│ └────────┬─────────┘ │ Updates every game-minute │ │
|
||||
│ │ └──────────────┬───────────────────┘ │
|
||||
│ ▼ ▼ │
|
||||
│ ┌──────────────────────────────────────────────────────────┐ │
|
||||
│ │ GENERATOR PIPELINE │ │
|
||||
│ │ LocationProfile + TerrainConstraints + PressureState │ │
|
||||
│ │ ├─→ Settlement placement (Layer 6) │ │
|
||||
│ │ ├─→ DistrictSkeleton (Phase 1) │ │
|
||||
│ │ └─→ Chunk tile data (Phase 2) │ │
|
||||
│ └────────────────────┬──────────────────────────────────────┘ │
|
||||
│ ┌────────────────────┼──────────────────────────────────────┐ │
|
||||
│ │ ENTITY SIMULATION (D-026 tiers) │ │
|
||||
│ │ Active (80 NPCs) ◄── tile data + NPC spawns │ │
|
||||
│ │ Background (2K) ◄── state machine updates from pressure │ │
|
||||
│ │ State-saved (10K+)◄── skeleton data only │ │
|
||||
│ └────────────────────┼──────────────────────────────────────┘ │
|
||||
│ │ ObserverSnapshot (MessagePack) │
|
||||
└─────────────────────────────────────────────────────────────────────┘
|
||||
│ IPC (MessagePack, D-020)
|
||||
▼
|
||||
┌─────────────────────────────────────────────────────────────────────┐
|
||||
│ GODOT CLIENT │
|
||||
│ ObserverSnapshot ──→ WorldRenderer ──→ GridMap (3D tiles) │
|
||||
│ ──→ EntityRenderer ──→ CharacterCompositor (3D) │
|
||||
│ ──→ FogRenderer ──→ Fog shader │
|
||||
│ ──→ UIRenderer ──→ Insert HUD, galaxy map, GTTR │
|
||||
└─────────────────────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 3. Cultural Cascade
|
||||
|
||||
*(From Miri — SW1-R3. Full specification in `miri-sw1r3.md`.)*
|
||||
|
||||
The 7 abstract heritage roots (Frost/Stone/Tide/Vine/Dust/Iron/Salt) are **superseded — clean
|
||||
break.** The real-world cultural corridor system is canonical:
|
||||
|
||||
- **North Reach:** Commonwealth (British/Australian/Canadian/South African/Indian/Nigerian)
|
||||
- **South Reach:** Iberian/Latin American + Southern African
|
||||
- **East Reach:** East Asian + South/Southeast Asian
|
||||
- **West Reach:** Northern/Central European + Central/Eastern European
|
||||
|
||||
Cultural data is authored per-system in `systems.db` (`system_culture` table: `cultural_corridor`,
|
||||
`founding_culture`, `heritage_persistence`, `ambient_anxiety`, `silence_threshold`).
|
||||
|
||||
### The 7-level cascade
|
||||
|
||||
| Level | Input | Output |
|
||||
|-------|-------|--------|
|
||||
| Galaxy | 4 cultural corridors + 5 industrial corridors | Corridor probability weights per region |
|
||||
| System | `cultural_corridor`, `founding_culture`, `heritage_persistence`, `industrial_corridor`, `exception_archetype` | System cultural identity |
|
||||
| Settlement | Corridor × preferred terrain bias | Settlement placement pattern readable from orbit |
|
||||
| District (Phase 1) | 3 numeric targets per corridor: `open_space_ratio_target`, `building_proximity_weight`, `gathering_infrastructure_weight` | District skeleton with cultural spatial character |
|
||||
| Room (Phase 2) | Three-layer token system (see below) | Culturally differentiated room fill |
|
||||
| Heritage attenuation | Hop distance × `heritage_persistence` | Living (≤4 hops) / Structural (5-7) / Archaeological (8+) |
|
||||
| Exception archetypes | 6 types: Early Arrival, Corporate Reset, Refugee Colony, Idealist Exception, Gate Silence Survivor, Perpetual Founder Stamp | Override room grammar with exception-specific character |
|
||||
|
||||
### Room grammar: three token layers
|
||||
|
||||
**Layer 1 — Spatial grammar tokens** (zero asset cost, derived from corridor identity):
|
||||
`privacy_default`, `gathering_orientation`, `threshold_character`, `sightline_character`
|
||||
|
||||
**Layer 2 — Social pattern tokens** (zero asset cost, drives NPC behavior):
|
||||
`stranger_distance`, `group_size_prior`, `noise_level_prior`, `eye_contact_norm` × attenuation tier
|
||||
|
||||
**Layer 3 — Object selection** (asset cost, 4 categories):
|
||||
1. Identity markers (cultural corridor, always present)
|
||||
2. Social infrastructure (cultural × prosperity)
|
||||
3. Material vocabulary (cultural × prosperity)
|
||||
4. Commodity objects (import/export lists × zone type × simulation state — derived from economic data, not heritage)
|
||||
|
||||
Industrial corridor overlay (MVG, Gate Corp, DSMC, Prometheus, Agricultural Syndic) modifies
|
||||
all three layers — a west_reach Germanic bar with MVG contract labor dynamics reads differently
|
||||
from one without.
|
||||
|
||||
Layers 1+2 together cost nothing and deliver the essential cultural read. A player who walks
|
||||
into a Commonwealth bar should feel the procedural formality before they see a single object.
|
||||
Layer 3 adds richness progressively per corridor as authoring bandwidth allows.
|
||||
|
||||
---
|
||||
|
||||
## 4. Replayability Architecture
|
||||
|
||||
*(From Nigel — SW1-R3)*
|
||||
|
||||
Replayability operates at three tiers. They are not interchangeable.
|
||||
|
||||
### Tier 1 — Player Agency (primary)
|
||||
|
||||
Two runs diverge primarily because two players made different decisions.
|
||||
|
||||
**The axes of agency:**
|
||||
- **Character creation.** Who you are determines starting position, starting knowledge, starting
|
||||
access. A dock logistics worker and a Commission field officer begin in the same canonical galaxy
|
||||
with completely different social maps.
|
||||
- **Where you go.** 300+ systems. No optimal route. Exploration sequence is a durable creative
|
||||
choice. Every sequence produces different first impressions, different economic states on arrival,
|
||||
different relationships formed.
|
||||
- **Who you know.** Social connections are the content selector. Every meaningful relationship
|
||||
determines what part of the world gets generated in detail. The player's social map writes
|
||||
the world.
|
||||
- **What you do economically.** Buying a business, building trade relationships, triggering
|
||||
corporate or political pressure — all tweak core dials that propagate through the network.
|
||||
The player participates in the economy; they don't observe it.
|
||||
|
||||
### Tier 2 — Simulation Trajectory (secondary)
|
||||
|
||||
The background simulation runs independently. Economic pressures build, trade flows shift,
|
||||
political balances tip. The simulation produces a different state at every location every time
|
||||
the player arrives — not because the world was seeded differently, but because time has passed
|
||||
and things have happened.
|
||||
|
||||
**Equilibrium is signal.** Stability tells the player something: nothing significant has happened
|
||||
here, or the pressures have balanced, or this system is controlled tightly enough to absorb shocks.
|
||||
A stable system is information, not dead air.
|
||||
|
||||
**Events are entropy injection.** Corporate disasters. Portal closings. Political shifts. Development
|
||||
successes. Each tweaks core dials on one or more systems and propagates through the trade/political
|
||||
network.
|
||||
|
||||
**The player as perturbation.** Player actions introduce the same perturbations through the same
|
||||
propagation model. The player who builds a successful logistics business changes the system's
|
||||
economic dial. They are an event source among many — with the unique property that they can observe
|
||||
what they caused.
|
||||
|
||||
> **X4 attractor note (Nigel):** X4-style production chain economics with stable attractor
|
||||
> states will tend to produce similar faction outcomes regardless of player action if left
|
||||
> unchecked. The background sim workshop must explicitly address disruption injection
|
||||
> mechanisms — the storyteller's event injection is the primary defense against convergence.
|
||||
> Invariants (topology, cultural geography) vs variables (economic health, faction control)
|
||||
> must be separated in the design spec. Without that separation, the simulation cannot be
|
||||
> tuned for meaningful replayability across runs.
|
||||
|
||||
### Tier 3 — Generation Hooks (tertiary)
|
||||
|
||||
**NPC-driven generation** and **news-driven generation** create world content unique per run because
|
||||
it is responsive to what the player specifically did. The player's social map, the simulation's
|
||||
event history, and the storyteller's news system together determine which parts of the world exist
|
||||
in detail in any given playthrough.
|
||||
|
||||
### What stays fixed vs what varies
|
||||
|
||||
| Fixed (invariants — learnable) | Varies (driven by simulation and player) |
|
||||
|-------------------------------|----------------------------------------|
|
||||
| Galaxy topology — 300+1 systems, wormhole routes | Economic health per system and settlement |
|
||||
| Authored topography — world maps, geographic features | Faction territorial control |
|
||||
| Cultural geography — corridor identities per system | NPC relationship states |
|
||||
| GTTR entries — authored narrative per system | District condition and era character |
|
||||
| Canonical starting state — faction standings and economic structure | Which neighborhoods exist in detail |
|
||||
| | Which locations have recent notable history |
|
||||
| | State of player-owned assets |
|
||||
|
||||
The fixed layer is learnable — a feature. A player on their fifth run navigates with earned
|
||||
geographic and cultural competence. Their knowledge doesn't tell them what's happening right now.
|
||||
|
||||
---
|
||||
|
||||
## 5. Player Experience Beats
|
||||
|
||||
*(From Ozzie — SW1-R3)*
|
||||
|
||||
| Beat | What happens | What the player feels |
|
||||
|------|-------------|----------------------|
|
||||
| **Galaxy map** | 300 named, storied dots — full info, every dot pre-loaded with heard names, rumors, GTTR data | Anticipation — a universe worth exploring because it's already been told about |
|
||||
| **GTTR arrival** | Warm arrival through scouting window + contextual landing by transit method | Expectation formed, then walked into reality |
|
||||
| **GTTR-as-contract** | Guide was true then; simulation has moved since the entry was written | History — the gap between the guide and the present is legible archaeology |
|
||||
| **Environmental archaeology** | Real simulation traces — event (rubble, memorial, construction) and social (bartender's history with the woman in the corner) | This world is real. Someone was actually here. |
|
||||
| **NPC-driven generation** | Visiting where your person is from; their neighborhood generated from their data | Wonder — the simulation knew them before you did; the place fits them |
|
||||
| **Return visits** | NPC drift + consequence echo; the world ran while you were gone; your actions propagated proportionally | Time passed. The world ran without me. My choices mattered. |
|
||||
| **Scale drop** | Physical (vantage point) + social (someone mentions a week's travel) + navigational (galaxy map zoom out) — all three registers ideally at once | One person. An enormous place. Worth exploring because it extends in every direction, lived-in by people with their own reasons. |
|
||||
|
||||
**The GTTR cashes its check at Stage 3 of the arrival cascade:** the first three seconds on the
|
||||
ground. The guide said this place has collective labor culture. You step out and the first thing
|
||||
you notice is either: the lack of branding, workers moving in groups — or: corporate signage,
|
||||
security checkpoints, workers with heads down. Either way, you already have a story.
|
||||
|
||||
**The test (Ozzie):** At a place where simulation has produced significant drift from the guide's
|
||||
description, the player should be able to identify the cause from observation alone — without
|
||||
asking an NPC, without reading a newspaper. The space should tell the story. Spatial legibility
|
||||
is the gold standard.
|
||||
|
||||
> **X4 production chain note (Ozzie):** X4-style production chains are natural trace-generators
|
||||
> for environmental archaeology. When a supply chain disrupts, physical evidence accumulates
|
||||
> automatically: half-empty shelves, mothballed machinery, logistics workers reassigned to
|
||||
> different zones. The economic model produces the archaeology without authored events. This
|
||||
> is the X4 adaptation earning its keep at room level.
|
||||
|
||||
---
|
||||
|
||||
## 6. Background Simulation Design Brief
|
||||
|
||||
The background simulation is not a nice-have — it is the mechanism by which every other system
|
||||
in this document works. Without it: replayability collapses to player agency only; environmental
|
||||
archaeology has no events to record; the GTTR has no gap to compare against; NPC-driven generation
|
||||
has no simulation state to paint neighborhoods with.
|
||||
|
||||
### Economic Model
|
||||
|
||||
**X4: Foundations, adapted to 300-system scale.** Station-level production chains, bulk commodity
|
||||
trade between systems, supply/demand price discovery, NPC-owned enterprises competing for resources
|
||||
and markets. Running on spare CPU cores as background tokio tasks.
|
||||
|
||||
The X4 model maps naturally to the architecture decisions already in place: systems.db bulk
|
||||
import/export lists are the commodity flow graph; corporate facility presence drives production
|
||||
chain anchors; faction influence drives market access; the wormhole topology constrains trade routes.
|
||||
|
||||
> **Tyre note:** The detailed X4 production chain → Settled Reach data mapping (what maps to
|
||||
> what in our systems.db schema, Rust data structures, how the economic tick computes one
|
||||
> game-minute of production chain activity) is explicitly deferred to the background sim
|
||||
> workshop. The architecture decisions below are confirmed. The production chain implementation
|
||||
> spec requires its own design session.
|
||||
|
||||
### Two-Layer Architecture
|
||||
|
||||
The simulation runs on two independent layers:
|
||||
|
||||
| Layer | Scope | Data Model | Execution | Clock |
|
||||
|---|---|---|---|---|
|
||||
| **Entity Simulation** | Per-NPC: movement, perception, dialogue, routines | bevy_ecs World (Components on Entities) | Main tick thread, 10 tps | SimulationTime (tick counter) |
|
||||
| **Pressure Simulation** | Per-system, per-settlement: economics, faction balance, social tension, trade flows | Standalone structs (not ECS) | tokio thread pool, capped | Game-minute clock (deterministic) |
|
||||
|
||||
An ECS is the wrong tool for system-level economic modeling. The two layers share a channel
|
||||
interface: the main sim reads pressure snapshots; the pressure sim applies player-action deltas.
|
||||
|
||||
### Conceptual Rust Architecture
|
||||
|
||||
```rust
|
||||
// Conceptual structure — not final API
|
||||
|
||||
struct PressureSimRuntime {
|
||||
runtime: tokio::runtime::Runtime, // Capped: N = available_cores - 2
|
||||
state: Arc<RwLock<PressureState>>,
|
||||
result_rx: crossbeam::channel::Receiver<PressureDelta>,
|
||||
snapshot_tx: crossbeam::channel::Sender<PressureSnapshot>,
|
||||
}
|
||||
|
||||
struct PressureState {
|
||||
systems: BTreeMap<SystemId, SystemPressure>,
|
||||
trade_flows: BTreeMap<(SystemId, SystemId), TradeFlow>,
|
||||
faction_influence: BTreeMap<(FactionId, SystemId), f64>,
|
||||
// All collections BTreeMap for D-010 determinism
|
||||
}
|
||||
|
||||
struct SystemPressure {
|
||||
economic_health: ProsperityLevel, // Prosperous/Growing/Stable/Faltering/Declining
|
||||
industries: BTreeMap<IndustryId, IndustryHealth>,
|
||||
social_satisfaction: f64,
|
||||
political_stability: f64,
|
||||
trade_imports: Vec<TradeGood>,
|
||||
trade_exports: Vec<TradeGood>,
|
||||
recent_events: Vec<PressureEvent>,
|
||||
}
|
||||
```
|
||||
|
||||
### Game-Minute Clock — Determinism Guarantee
|
||||
|
||||
```
|
||||
Main sim tick (100ms real-time at 10 tps)
|
||||
├─ Every 10 ticks (= 1 game-minute):
|
||||
│ ├─ Snapshot PressureState → PressureSnapshot → send to tokio
|
||||
│ └─ Collect completed PressureDelta from previous minute
|
||||
│ └─ Apply deltas in fixed order (system_id ascending)
|
||||
│
|
||||
tokio runtime:
|
||||
├─ Trade flow propagation (bulk imports/exports between connected systems)
|
||||
├─ Industry health updates (supply availability, demand, corporate events)
|
||||
├─ Social pressure calculation (from economic health + political stability)
|
||||
├─ Faction influence shifts (leverage, events, player actions)
|
||||
└─ Event injection (storyteller: corporate disasters, portal closings, political shifts)
|
||||
```
|
||||
|
||||
**Determinism:** Each task is internally deterministic (BTreeMap iteration, seeded where needed).
|
||||
Deltas applied in fixed order at game-minute boundary. Slower machines accrue sim debt but
|
||||
produce identical outcomes. D-010 compliant.
|
||||
|
||||
### Generation Mandate Queue
|
||||
|
||||
Both NPC-driven and news-driven hooks feed into a unified mandate queue:
|
||||
|
||||
```
|
||||
┌─────────────────────────────────────────────────────────┐
|
||||
│ GENERATION MANDATE QUEUE │
|
||||
│ Sources: │
|
||||
│ ├─ Player exploration (progressive generation) │
|
||||
│ ├─ NPC-driven hook (deep interaction with distant NPC) │
|
||||
│ ├─ News-driven hook (simulation event at a location) │
|
||||
│ └─ Storyteller (narrative-paced world expansion) │
|
||||
│ Consumer: Generator pipeline (background tokio tasks) │
|
||||
└─────────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
**NPC-driven:** Player forms deep relationship → GenerationMandate created with constraints
|
||||
derived from NPC's cultural/economic presentation → background processing → NPC's home exists
|
||||
when player arrives. Phase 1 + Phase 2 for one district < 1 second even worst-case.
|
||||
|
||||
**News-driven:** Pressure simulation produces event at a specific location → ChunkMutation
|
||||
(damage overlay) applied to Phase 1 skeleton if it exists, or pre-baked into new mandate →
|
||||
news ticker reports event → player travels to find physical evidence.
|
||||
|
||||
### Architecture Decision
|
||||
|
||||
Background simulation runs as **tokio async tasks** outside the bevy_ecs main loop. It operates
|
||||
on aggregate data — per-system and per-settlement pressure dials. It does not query per-entity
|
||||
ECS state. An ECS is the wrong tool for system-level economic modeling.
|
||||
|
||||
**Deterministic game-minute clock.** Simulation advances in discrete game-minute steps regardless
|
||||
of CPU availability. Variable CPU speed produces simulation debt (slower machines fall behind)
|
||||
not variable world states (slower machines don't produce different outcomes). D-010 compliant.
|
||||
|
||||
### The pressure state model
|
||||
|
||||
For each settlement, the background simulation maintains four core dials:
|
||||
|
||||
| Dial | Range | Driven by |
|
||||
|------|-------|-----------|
|
||||
| `economic_health` | Prosperous / Stable / Faltering / Declining | Trade flow balance, import/export dependencies, corporate facility presence |
|
||||
| `faction_dominance` | Per-faction influence score | Political pressure, economic investment, player actions |
|
||||
| `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 |
|
||||
|
||||
### Event propagation cascade
|
||||
|
||||
```
|
||||
Event fires in System A (corporate disaster, portal closure, political shift, development success)
|
||||
→ System A's core dials shift
|
||||
→ Trade network rebalances (adjacent systems: supply/demand shifts, prices adjust)
|
||||
→ Faction influence adjusts across connected systems
|
||||
→ Settlement economic health shifts
|
||||
→ District character updates (condition degrades/improves, faction signage, construction)
|
||||
→ Room simulation primitives update (turnover, staff count, stock quality)
|
||||
→ Environmental evidence accumulates (closed shops, repurposed storefronts, memorials)
|
||||
```
|
||||
|
||||
Propagation strength decays with network distance. The Reach's wormhole topology is not just
|
||||
travel infrastructure — it is the economic and information nervous system of the world. Gate
|
||||
topology shapes what events propagate where.
|
||||
|
||||
### Mandatory agenda items for the dedicated background sim design workshop
|
||||
|
||||
| Item | Why mandatory |
|
||||
|------|--------------|
|
||||
| **X4 production chain mapping** — how X4 station-level economics adapt to 300-system scale; bulk import/export lists as commodity flow graph; corporate facility presence as production chain anchors; what each X4 concept maps to in systems.db | The economic model is confirmed X4-style. The workshop must produce an implementation spec, not a conceptual outline. |
|
||||
| **Invariants vs variables** — which aspects are designed to be stable reference points and which resist equilibrium; disruption injection mechanisms to prevent X4-style attractor convergence | Without separating these, the simulation cannot be tuned for meaningful replayability. These require different implementation approaches. |
|
||||
| **Propagation network architecture** — how do events that tweak core dials propagate through the trade/political network? Bulk import/export lists per system must feed both simulation (trade flows) and content (store shelves). | "Set up propagation properly and emergence follows naturally." The central engineering challenge. |
|
||||
| **Consistency buffer for generation hooks** — how do existence claims (NPC-driven, news-driven) get registered and resolved before player arrival? | NPC and news hooks are callable from social and narrative layers — not just player movement. The buffer is a new pipeline component. |
|
||||
| **Pre-play simulation strategy** — what state is the world in at the player's first move? | Load-bearing for environmental archaeology. Options: pristine canonical, fast-forward, pre-authored canonical events, or hybrid. |
|
||||
| **Exception community resilience** — refugee colonies, Perpetual Founder Stamp systems, Gate Silence survivors must be resilient against simulated normalization. | These settlement histories are what give room grammar its distinctiveness. Must be a design constraint, not an emergent property. |
|
||||
|
||||
---
|
||||
|
||||
## 7. Open Questions
|
||||
|
||||
Three questions remain unresolved after the R2 follow-up interview:
|
||||
|
||||
| # | Question | Why load-bearing |
|
||||
|---|---------|-----------------|
|
||||
| **Q1** | What must be generated at Phase 2 (eager) vs expanded on demand (lazy) in the NPC minimum data bundle? `tell_config` must be eager (required by D-138 voice pipeline). What else? | Determines Phase 2 generation cost per NPC and save file size per district. |
|
||||
| **Q2** | Does NPC-driven generation produce canonical neighborhoods (same for all players who reach that depth with a contact from that system) or seeded-per-run neighborhoods? | Canonical = consistent with reader-and-filler architecture + shared player reference points. Seeded = unique personal worlds per run but architectural divergence. |
|
||||
| **Q3** | What is the pre-play simulation strategy — how much background sim has run before the player's first move? | Load-bearing for environmental archaeology at game start. Must be answered in background sim workshop brief. |
|
||||
| **Q4 (D2 — Miri)** | Does the industrial corridor overlay modify room physical character AND NPC composition, or NPC composition only? | Changes authoring scope significantly. Miri has asserted "both" (full spec in `miri-sw1r3.md`). PO confirmation required before room grammar authoring begins. |
|
||||
|
||||
---
|
||||
|
||||
## 8. Stale D-Records to Supersede
|
||||
|
||||
| D-record | Status | Action required |
|
||||
|----------|--------|----------------|
|
||||
| **D-104** | Superseded — heritage root grammar overlays | File supersession D-record. Replace with corridor-to-room-grammar mapping D-record (pending Miri wiki cross-check). |
|
||||
| **D-105** | Superseded — heritage root grammar overlays | File supersession D-record (same new record as D-104 replacement). |
|
||||
| **D-101** | Superseded — ZonePalette modifier axis A = `HeritageRoot` | File supersession D-record. `PaletteModifier` axis A remaps to cultural_corridor + founding_culture. |
|
||||
| **D-107** | Superseded — references heritage roots | Audit and file supersession. |
|
||||
|
||||
All four supersessions confirmed by PO in R1 and R2 follow-up interview answers ("clean break —
|
||||
the 7 abstract roots are retired"). New D-records required from Miri's R3 (to be filed after
|
||||
Miri's wiki cross-check with Paula/Mellanie):
|
||||
|
||||
- **D-NNN: Four-Corridor Cultural Framework** — canonical cultural inputs replacing the 7 abstract roots
|
||||
- **D-NNN: Room Grammar Three-Layer System** — spatial tokens (L1), social pattern tokens (L2), object selection tokens (L3), each parameterised per corridor
|
||||
- **D-NNN: Heritage Attenuation Tiers** — Living/Structural/Archaeological with hop × persistence thresholds
|
||||
- **D-NNN: Six Exception Archetypes** — room grammar consequences per archetype
|
||||
|
||||
---
|
||||
|
||||
## 9. Future Workshop Topics
|
||||
|
||||
| Workshop | Scope | Priority |
|
||||
|----------|-------|---------|
|
||||
| **Background Simulation Design** | X4-style pressure model spec: production chain architecture (X4 adapted to 300-system scale), bulk trade flows, corporate facility dependencies, political pressure, disaster injection, propagation network. Must separate invariants from variables. Must address X4 attractor convergence prevention. Design brief on file. | **CRITICAL — blocks replayability, archaeology, NPC evolution, and pressure-painted generation** |
|
||||
| **Sub-Workshop 2: Zone Types** | Phase 2 fill specification per zone type family (Interior / Urban / Natural). Implementation detail deferred from SW1. | High — gates full generation capability |
|
||||
| **Sub-Workshop 3: NPC Generation Depth** | Full NPC expansion pipeline: relationship graph generation, biographical history, triangle assignment, on-demand expansion protocol. | High — gates NPC-driven generation hook |
|
||||
| **Cultural Cascade Authoring** | Corridor-to-room-grammar mapping document (Miri's R2 draft + wiki cross-check with Paula/Mellanie). Attenuation tier parameterisation. Industrial corridor overlay modifier specification. | Medium — gates culturally differentiated room fill |
|
||||
| **Authored Content Pipeline** | Heightmap authoring tooling, wiki location profile expansion (300+ planets/moons), GTTR enhancement with stats and art, planetary shader for screenshots. | Medium — gates layers 2-3 of the cascade |
|
||||
|
||||
---
|
||||
|
||||
*Document status: complete. All 5 R3 outputs incorporated. Full Miri cascade spec (with all
|
||||
corridor parameters, exception archetypes, and attenuation tiers) in `miri-sw1r3.md`. Full
|
||||
Tyre pipeline spec (with LOD economic primitives, detailed cost estimates, critical path) in
|
||||
`tyre-sw1r3.md`. Q4 (industrial corridor physical vs NPC-only) pending PO confirmation.*
|
||||
|
||||
*— Qatux, 2026-03-24*
|
||||
@@ -0,0 +1,207 @@
|
||||
---
|
||||
title: "SW1-R1: Gestalt — Product Questions on Generation Systems"
|
||||
agent: gestalt
|
||||
workshop: world-generation
|
||||
round: 1
|
||||
type: product-questions
|
||||
created: 2026-03-24
|
||||
---
|
||||
|
||||
# SW1-R1: Gestalt — Product Questions on Generation Systems
|
||||
|
||||
**Angle:** Systems design and fun factor. How do generated spaces create interesting player
|
||||
decisions, support the tycoon/life-sim loop, and interact with NPC behaviour and economy?
|
||||
|
||||
---
|
||||
|
||||
## Context I read before writing these
|
||||
|
||||
- **D-114** (v0.2 proof-of-life = generator producing usable output, not hand-built slice)
|
||||
- **D-117** (tycoon bookmark — small business owner in Van Maanen's Star, zero investigation content)
|
||||
- **D-118** (starts as existing small business owner, not mogul — bar, logistics contract, storage franchise)
|
||||
- **D-097** (guarantee tier system — generator makes spatial contracts it keeps)
|
||||
- **D-096** (Grid and Organic layout modes)
|
||||
- The full `DistrictSkeleton` data model in `server/src/simulation/generator.rs`
|
||||
- Generator architecture workshop outcomes (the prior spatial hierarchy and two-phase model are settled)
|
||||
|
||||
What is NOT settled: how generated spaces plug into the economy, what "functional" vs "cosmetic"
|
||||
rooms mean, how NPCs populate zones, what v0.2 scope looks like, and whether the player
|
||||
ever modifies generated space.
|
||||
|
||||
---
|
||||
|
||||
## Q1: What does a "functional" room need to provide for the tycoon loop?
|
||||
|
||||
**The question:** When the generator creates a commercial zone (bar, market stall, warehouse),
|
||||
does it also produce the economic hook that makes it a place the player can *do business*?
|
||||
Or is the simulation layer bolted on separately?
|
||||
|
||||
**Why it matters:** The tycoon starts with a small bar. If bars are cosmetic — they look like
|
||||
bars but have no economic wiring — then running a business is entirely abstract (pure insert
|
||||
interaction, no spatial reality). If bars are functional — they have customer demand, a supply
|
||||
chain hook, a rent mechanic — then the generator is responsible for producing the simulation
|
||||
preconditions, not just the tiles.
|
||||
|
||||
**Options:**
|
||||
|
||||
| Option | What it means |
|
||||
|--------|---------------|
|
||||
| A. Cosmetic | Generator produces correct tile aesthetics. All economic logic is layered on manually by game systems. |
|
||||
| B. Function-tagged | Rooms carry a `DistrictType`/`ZoningType` tag that unlocks interaction types (buy, sell, employ, rent). Simulation is sparse but spatially grounded. |
|
||||
| C. Fully simulated | Generator produces demand curves, foot traffic weights, supply route stubs. Economy is intrinsic to generated space. |
|
||||
|
||||
**Recommendation: B (function-tagged).**
|
||||
|
||||
Option A breaks the tycoon loop — you can't run a bar if bars are decoration.
|
||||
Option C is v0.5+ scope — we don't even have an economic simulation implemented.
|
||||
Option B gives us the minimum: the generator tags commercial zones, and the
|
||||
economic layer treats tags as permission flags. The player's bar is real because
|
||||
the generator says "this zone accepts commercial transactions" — the rest is
|
||||
simulation-layer work on top of a tag.
|
||||
|
||||
---
|
||||
|
||||
## Q2: How does the tycoon's starting business relate to generated space?
|
||||
|
||||
**The question:** Does the generator produce a district and the tycoon picks a business
|
||||
from what's there? Or does generation know in advance that a tycoon is spawning and
|
||||
guarantee a specific business type?
|
||||
|
||||
**Why it matters:** This is the first decision point in the game. If the generator doesn't
|
||||
know the tycoon is coming, the player might spawn into a district with no available
|
||||
commercial sites — or the starting business is completely decoupled from the generated world
|
||||
(pure abstraction). If generation is bookmark-aware, the generator guarantees a buyable
|
||||
commercial zone exists — but then generation is character-type-specific, which is an
|
||||
architectural coupling.
|
||||
|
||||
**Options:**
|
||||
|
||||
| Option | What it means |
|
||||
|--------|---------------|
|
||||
| A. Generator-first | Generator produces a district. Tycoon bookmark picks a starting business from whatever commercial social sites the generator placed. Generator knows nothing about character type. |
|
||||
| B. Guarantee-driven | The guarantee tier system (D-097) ensures every `ComplexityTier::Full` district contains at least one buyable commercial social site. Tycoon always has options. Generator doesn't care about character type — it just guarantees commercial availability. |
|
||||
| C. Bookmark-aware generation | Generator receives bookmark type as a constraint and builds around the tycoon's starting premise. |
|
||||
|
||||
**Recommendation: B (guarantee-driven).**
|
||||
|
||||
Option A is too loose — the tycoon might spawn in a district with no commercial sites
|
||||
(e.g., a pure `DistrictType::Residential`). Option C creates character-specific generation
|
||||
logic which is a maintenance nightmare as more bookmarks are added. Option B is the right
|
||||
architecture: the guarantee system already exists (D-097), we just add "at least one
|
||||
buyable commercial zone" as a Tier 1 guarantee for `ComplexityTier::Full` districts.
|
||||
The tycoon picks their bar from the available options — first decision is meaningful.
|
||||
|
||||
---
|
||||
|
||||
## Q3: Do NPC schedules follow zone type or triangle assignment?
|
||||
|
||||
**The question:** When NPCs populate a district, are their daily paths shaped by zone function
|
||||
(they go to commercial zones to shop, to residential zones to sleep) or by their triangle
|
||||
assignment (they go where the narrative needs them)?
|
||||
|
||||
**Why it matters for the tycoon:** The player's bar lives or dies by foot traffic. If NPCs
|
||||
only move according to triangle assignments, ambient customers are invisible unless they're
|
||||
assigned to the tycoon's triangle. If NPCs follow zone function, the bar gets ambient
|
||||
customers automatically — but narrative moments (the suspicious regular, the supplier contact)
|
||||
need special handling.
|
||||
|
||||
This is the core tension between simulation-feel and story-feel.
|
||||
|
||||
**Options:**
|
||||
|
||||
| Option | What it means |
|
||||
|--------|---------------|
|
||||
| A. Triangle-only | All NPC movement is story-driven. NPCs only appear somewhere if their triangle sends them there. Ambient foot traffic doesn't exist. |
|
||||
| B. Zone-only | NPCs follow zone-function schedules. Commercial zones attract consumer NPCs. Triangle narrative overrides are not supported. |
|
||||
| C. Hybrid (zone baseline + triangle override) | Ambient NPCs follow zone-function schedules (commercial zones get foot traffic automatically). Key NPCs with triangle assignments override their zone schedule for plot-relevant moments. |
|
||||
|
||||
**Recommendation: C (hybrid).**
|
||||
|
||||
Option A produces a ghost town except during triangle events — the tycoon's bar has
|
||||
zero customers unless someone is assigned there. Option B produces living space but
|
||||
no narrative texture — everyone behaves the same, nothing is special. Option C is the
|
||||
Rimworld principle: simple rules (zone attraction) produce ambient life; story layers
|
||||
override locally when they need to. The generator already produces both zone types AND
|
||||
social site placements — C uses both outputs at their appropriate scale.
|
||||
|
||||
---
|
||||
|
||||
## Q4: What zone types does v0.2 actually need to generate?
|
||||
|
||||
**The question:** The brief lists 5 zone types (station, urban, agricultural, maritime,
|
||||
wilderness). The tycoon lives in Van Maanen's Star. What's the minimum generation scope
|
||||
that produces a playable proof-of-life without spreading implementation across 5 zone types?
|
||||
|
||||
**Why it matters:** Each zone type is a separate generation algorithm, tile palette, NPC
|
||||
schedule model, and spatial grammar. Attempting all 5 for v0.2 is a scope risk that could
|
||||
leave us with 5 half-working zone types instead of 1 fully working one. D-114 defines
|
||||
proof-of-life as "generator producing usable output" — usable requires one zone type that
|
||||
actually works end-to-end.
|
||||
|
||||
**Options:**
|
||||
|
||||
| Option | What it means | Scope risk |
|
||||
|--------|---------------|-----------|
|
||||
| A. Station only | Van Maanen's Star is a station/port. Build the interior generator fully. | Low — one algorithm, one palette family, one NPC schedule model |
|
||||
| B. Station + Urban | Give us the station and the surrounding commercial district | Medium — two algorithms, palette transition logic needed |
|
||||
| C. All 5 from day one | Full zone type coverage immediately | High — 5 algorithms, impossible to validate all in v0.2 |
|
||||
| D. Station + one exterior zone | Station proves interior generation; one exterior zone (urban or wilderness) proves the generator can handle open space | Medium — two algorithms but deliberately different in kind |
|
||||
|
||||
**Recommendation: A (station only) with explicit deferral of everything else.**
|
||||
|
||||
Van Maanen's Star is canonically station/port-dominated (that's what makes a tycoon's
|
||||
bar viable — captive population). Station interiors are the most mechanically interesting
|
||||
for the tycoon loop (chokepoints, commercial zones, residential blocks, access tiers).
|
||||
The full DistrictSkeleton supports all 5 zone types architecturally — v0.2 just proves
|
||||
one of them works. Urban, agricultural, maritime, wilderness are all follow-on work once
|
||||
the generator pipeline is validated end-to-end.
|
||||
|
||||
---
|
||||
|
||||
## Q5: Does the player ever modify generated space?
|
||||
|
||||
**The question:** The data model has `ChunkMutations` with `MutationCause::PlayerAction`.
|
||||
The tycoon is running a bar. Can they renovate it — add a table, change the layout,
|
||||
put up a sign? Or is the physical space static and all management happens through the
|
||||
insert/device?
|
||||
|
||||
**Why it matters for systems:** If the player modifies space, the generator needs to
|
||||
produce spaces that are modifiable (correct tile types, clear floor plans, reasonable
|
||||
door placement). Generation also needs to know which spaces the player can legally
|
||||
modify. If spaces are static, none of this matters and `ChunkMutations::PlayerAction`
|
||||
is future scope.
|
||||
|
||||
**Options:**
|
||||
|
||||
| Option | What it means |
|
||||
|--------|---------------|
|
||||
| A. Static backdrops | Generated space is never modified by the player. All business management is insert-mediated. `ChunkMutations::PlayerAction` is deferred indefinitely. |
|
||||
| B. Owned-premise modification only | Player can modify furniture/layout of the space they own (their bar). Other zones are static. Generator needs to mark owned zones as player-modifiable. |
|
||||
| C. Any controlled space | Player can modify any space they own or rent. Generator produces modifiability metadata. |
|
||||
|
||||
**Recommendation: A (static) for v0.2, B as the first enhancement.**
|
||||
|
||||
The tycoon loop doesn't *require* spatial modification — you can run a successful bar
|
||||
without moving the furniture. For v0.2 proof-of-life, keeping spaces static eliminates
|
||||
an entire systems layer (construction, ownership transfer, physics, save/load for mutations)
|
||||
and focuses attention on proving generation and economic simulation work. Mark B as the
|
||||
first post-v0.2 enhancement: owned-premise modification is a high-impact feature (players
|
||||
feel ownership when they can redecorate) with bounded scope.
|
||||
|
||||
---
|
||||
|
||||
## Systems summary: what these answers connect to
|
||||
|
||||
If Jeroen answers these 5 questions, the following generator system boundaries become
|
||||
fully specified for v0.2:
|
||||
|
||||
| Question answered | System boundary clarified |
|
||||
|-------------------|--------------------------|
|
||||
| Q1 (functional rooms) | What tags the generator must produce vs what economic simulation adds later |
|
||||
| Q2 (tycoon + generated space) | Whether guarantee tier system needs a "buyable commercial zone" Tier 1 entry |
|
||||
| Q3 (NPC schedules) | Whether Phase 2 (PreparedDistrict) generates NPC manifests with zone-baseline schedules |
|
||||
| Q4 (zone type scope) | Which tile palettes, generation algorithms, and NPC schedule templates v0.2 needs |
|
||||
| Q5 (player modification) | Whether `ChunkMutations::PlayerAction` enters scope or stays stub |
|
||||
|
||||
The crux question is **Q1** — it determines whether generated spaces are an art asset or
|
||||
a simulation primitive. Everything else flows from that answer.
|
||||
@@ -0,0 +1,279 @@
|
||||
---
|
||||
title: "SW1-R1b: Gestalt — Endgame Systems Design, Galaxy-to-Ground"
|
||||
agent: gestalt
|
||||
workshop: world-generation
|
||||
round: 1
|
||||
type: product-questions
|
||||
created: 2026-03-24
|
||||
supersedes: gestalt-sw1r1.md
|
||||
---
|
||||
|
||||
# SW1-R1b: Gestalt — Endgame Systems Design, Galaxy-to-Ground
|
||||
|
||||
**Framing:** No v0.2 scoping. Design the full pipeline as if we had infinite time.
|
||||
These questions target the endgame vision — what does the fully realised generation
|
||||
pipeline look like? Scoping workshops come later.
|
||||
|
||||
**Angle:** Systems design. At each level of the galaxy-to-room cascade, what creates
|
||||
interesting player decisions? How does economic context flow from system profile all the
|
||||
way down to the room the player is standing in?
|
||||
|
||||
---
|
||||
|
||||
## The cascade I'm interrogating
|
||||
|
||||
```
|
||||
1. Galaxy — 300 systems, what exists in each
|
||||
2. System profile — wealth distribution, governance, atmosphere, biomes
|
||||
3. Topography — continental bones, station ring/module structure
|
||||
4. Arrival — inbound experience at the gateway/portal
|
||||
5. Content spider — how detail expands as the player moves
|
||||
6. Settlement — cities, towns, outposts vs topographic context
|
||||
7. District — neighborhoods shaped by settlement identity
|
||||
8. Room — shop fronts, interiors, furniture
|
||||
```
|
||||
|
||||
The big systems question across all levels: **does economic context cascade visibly?**
|
||||
Can a skilled player stand in a room and read backward from the furniture to the system's
|
||||
power structure? That's the asymmetric information game. The generator is the thing that
|
||||
produces information to be asymmetric about.
|
||||
|
||||
---
|
||||
|
||||
## Q1: What are the economic axes of a system profile, and which ones cascade to the street?
|
||||
|
||||
**The question:** When the generator builds Van Maanen's Star (or any system), it
|
||||
establishes an economic profile. How many axes does that profile carry? And critically:
|
||||
which ones produce visible differences at the district and room level?
|
||||
|
||||
**Why it matters:** The tycoon's core decisions are economic. The player needs to be
|
||||
able to read the economic landscape spatially — not just from their insert device. A
|
||||
corporate-dominated system should *look* different from a worker-cooperative system even
|
||||
if they're equally "wealthy." If the economic profile doesn't cascade to visible space,
|
||||
the world is a backdrop and the economy is pure UI.
|
||||
|
||||
This is the information asymmetry spine of the whole pipeline. System profile → district
|
||||
character → interior condition → the player can observe and reason about power from what
|
||||
they see.
|
||||
|
||||
**Options:**
|
||||
|
||||
| Option | Economic axes | What cascades visibly |
|
||||
|--------|--------------|----------------------|
|
||||
| A. Single wealth axis | Rich / Middle / Poor | Condition modifier only (pristine vs worn) |
|
||||
| B. Dual axis: aggregate wealth + wealth holder | Who is rich: individuals, corporations, government, or nobody | Zoning character, building ownership types, faction presence, NPC wealth distribution |
|
||||
| C. Full economic profile | Multiple industries, multiple power players, historical disruptions | Full district personality matrix — can produce contested zones, parallel economies, boom/bust spatial signatures |
|
||||
|
||||
**Recommendation: C (full profile) is the endgame target, B is the minimum viable.**
|
||||
|
||||
The dual axis (B) already creates rich differentiation. A corporate-rich system with
|
||||
poor individuals produces fortress-architecture commercial districts, visible security
|
||||
presence, and cramped residential zones. A people-rich system with weak corporate
|
||||
presence produces market-overflow commerce, informal extensions, and self-built
|
||||
residential texture. These are completely different games to play in, even if the
|
||||
aggregate GDP is identical. C adds historical disruption (a formerly corporate zone
|
||||
now in decay, a recently gentrified district still showing its seams) — that's what
|
||||
makes the world feel like it has a past.
|
||||
|
||||
**The cascade rule:** Each economic axis on the system profile should produce at least
|
||||
one visible attribute at district level, which in turn produces at least one visible
|
||||
attribute at room level. If an axis doesn't cascade visibly, cut it — it's just database
|
||||
weight.
|
||||
|
||||
---
|
||||
|
||||
## Q2: Does topography constrain settlement placement or decorate it?
|
||||
|
||||
**The question:** When the generator places continental bones (mountains, rivers,
|
||||
coastlines, craters, fault lines) or station ring/module topology, do those features
|
||||
*constrain* where settlements go and what they look like? Or do they provide aesthetic
|
||||
backdrop that generation ignores for placement logic?
|
||||
|
||||
**Why it matters for player decisions:** Topography is the first source of emergent
|
||||
spatial reasoning. If rivers create natural chokepoints and settlements cluster at
|
||||
crossings, the player can *predict* where commerce happens before they've walked there.
|
||||
If mountains block movement, settlements at passes hold different economic power than
|
||||
settlements in valleys. Spatial logic the player can reason about is information — and
|
||||
information is the master mechanic. Cosmetic topography produces no decisions.
|
||||
|
||||
**Options:**
|
||||
|
||||
| Option | What topography does |
|
||||
|--------|---------------------|
|
||||
| A. Cosmetic | Mountains look right but don't block roads. Rivers exist but settlements ignore them. Pure visual backdrop. |
|
||||
| B. Soft constraint | Topography influences settlement placement probability (mountains reduce likelihood, rivers increase it at crossings) but can be overridden by other factors (corporate mandate builds where it wants). |
|
||||
| C. Hard constraint + emergent structure | Mountains block ground movement corridors. Rivers create natural district boundaries. Coastlines produce port districts automatically. Station ring topology determines module function. Settlements cannot ignore terrain — they respond to it. |
|
||||
|
||||
**Recommendation: C (hard constraint).**
|
||||
|
||||
Option A produces beautiful screenshots and dead spatial reasoning. Option B is a soft
|
||||
approximation that makes things feel slightly more realistic without actually committing.
|
||||
Option C is the only option that produces emergent geography as a player tool. If the
|
||||
generator places a river that bisects a commercial district, bridge chokepoints become
|
||||
real — surveillance, ambush, customs control, economic choking all become spatially
|
||||
grounded. The player can *use* the map rather than just inhabiting it.
|
||||
|
||||
For station topology, C means ring sections have structural logic: docking rings are
|
||||
near the hull, residential is in the middle, administrative is at the axis. The station's
|
||||
form determines its social geography. A player who understands ring structure can navigate
|
||||
a station they've never visited before — spatial literacy is a skill.
|
||||
|
||||
---
|
||||
|
||||
## Q3: What does the arrival experience need to guarantee?
|
||||
|
||||
**The question:** When the player comes through a gate/portal into a new system or
|
||||
location for the first time, what does the generator guarantee they see? The arrival
|
||||
moment is the game's "establishing shot" — it determines whether the world feels real
|
||||
and legible, or random and disorienting.
|
||||
|
||||
**Why it matters:** First impressions set the player's mental model of a location.
|
||||
Arriving at a corporate logistics hub should give immediate environmental reads: security
|
||||
checkpoints, customs infrastructure, corporate insignia, the density of freight movement.
|
||||
Arriving at a frontier mining outpost should give different reads: makeshift structures,
|
||||
informal docking, no customs to speak of. If the generator can't guarantee arrival-point
|
||||
differentiation, the world feels like random tile soup from the first moment.
|
||||
|
||||
This is also a player agency question: the arrival experience is a moment of pure
|
||||
observation before commitment. It's the scouting window.
|
||||
|
||||
**Options:**
|
||||
|
||||
| Option | Arrival guarantee |
|
||||
|--------|-----------------|
|
||||
| A. Type-consistent arrival zones | Generator ensures arrivals into a `LogisticsHub` district look like logistics infrastructure. Arrivals into `Residential` districts look like residential zones. Type drives look, not economic profile. |
|
||||
| B. Profile-encoded arrival zones | Arrival zones encode the location's economic/governance profile visually. Corporate-controlled logistics hubs have different arrival aesthetics than cooperative-controlled ones even within the same district type. |
|
||||
| C. Arrival as information front-load | Arrival zones are specifically designed to give the observant player 3-5 readable signals about the location before they've spoken to anyone. Security level, wealth signal, faction presence, atmosphere condition, NPC density — all legible from the arrival point geometry and object placement. |
|
||||
|
||||
**Recommendation: C (arrival as information front-load).**
|
||||
|
||||
Option A is a floor — necessary but not interesting. Option B adds economic texture to
|
||||
the same type-consistent shell. Option C is the game's information asymmetry proposition
|
||||
expressed spatially: the skilled player reads more from the arrival environment than the
|
||||
unskilled player because they know what to look for. The tycoon who can assess a market
|
||||
opportunity from the arrival zone geometry has a real advantage. The narrative player
|
||||
who notices the faction graffiti at the arrival point has a lead on what's happening.
|
||||
|
||||
The generator needs a set of "arrival signal slots" — each slot maps to an observable
|
||||
feature (guard density, commercial sprawl into arrival area, maintenance condition, faction
|
||||
signage, crowd composition) that is set by the location's profile and legible to the
|
||||
observant player.
|
||||
|
||||
---
|
||||
|
||||
## Q4: What is the atom of settlement identity — single tag or composition?
|
||||
|
||||
**The question:** When the generator builds a settlement (city, town, outpost), it needs
|
||||
a core identity that drives district subdivision. What is that identity made of? A single
|
||||
type tag? A composition of type + power structure? A full profile with history?
|
||||
|
||||
**Why it matters for district variety:** Settlement identity directly determines how
|
||||
many distinct district personalities a settlement produces and whether those personalities
|
||||
feel *in tension* with each other. A settlement described only by type (LogisticsHub)
|
||||
produces one personality everywhere. A settlement described by type + power structure
|
||||
(LogisticsHub controlled by a single corporation vs. LogisticsHub controlled by competing
|
||||
guilds) produces districts that reflect the tension between controlling interests. Districts
|
||||
in tension create player decisions — which side do I work with?
|
||||
|
||||
**Options:**
|
||||
|
||||
| Option | Identity atom | District variety |
|
||||
|--------|--------------|-----------------|
|
||||
| A. Single type tag | LogisticsHub, Residential, Mixed... | 1 personality per settlement, coherent but monotonous |
|
||||
| B. Type + power structure | LogisticsHub × (Corporation / Guild / Government / Chaotic) | 2-4 personalities — dominant character + contested edges |
|
||||
| C. Type + power structure + era layering | B + history of control changes (formerly corp, now guild-contested) | 4-8 personalities — temporal strata visible in district character, spatial archaeology possible |
|
||||
| D. Full profile | Multiple industries, multiple factions, historical disruptions, ongoing tensions | Unlimited personality range, full emergence |
|
||||
|
||||
**Recommendation: C (type + power structure + era layering) as the endgame minimum.**
|
||||
|
||||
Option B is already a major step up from A — a corporation-controlled port and a
|
||||
guild-controlled port are genuinely different games. Option C adds what makes the world
|
||||
feel lived-in: history is spatially legible. The district that was corporate HQ ten years
|
||||
ago and is now guild-contested has scars — old corporate infrastructure repurposed with
|
||||
guild graffiti, a fancy corporate lobby now serving as a union hall, access control
|
||||
systems the guilds haven't bothered to update because the corporate branding makes them
|
||||
feel legitimate. These are the details that make replayability — a different system's
|
||||
settlement history produces different spatial archaeology.
|
||||
|
||||
Option D (full profile) is the endgame ideal — let the full economic profile cascade
|
||||
into settlement identity completely. But C is the minimum for the world to feel like
|
||||
it has a past.
|
||||
|
||||
**Key design rule:** Every era transition in a settlement's history should leave at least
|
||||
one spatially visible scar that a skilled player can identify as evidence of the transition.
|
||||
|
||||
---
|
||||
|
||||
## Q5: How deeply does economic context cascade into room interiors?
|
||||
|
||||
**The question:** At the room level — shop fronts, offices, storage rooms, living quarters —
|
||||
how much does the room's interior reflect the economic context it sits in? Does the
|
||||
generator produce rooms that are typed by function (office, shop, residential) but
|
||||
economically uniform? Or does each room's interior encode the economic position of the
|
||||
person or organisation that inhabits it?
|
||||
|
||||
**Why it matters for the tycoon and for information asymmetry:** The tycoon is reading
|
||||
the market. They should be able to walk into a competitor's shop and assess its health
|
||||
from interior signals — is the stock well-maintained? Is the counter arrangement that of
|
||||
a thriving operation or a survival mode one? Are the fixtures corporate-grade or
|
||||
secondhand? This is spatial intelligence as gameplay. The generator needs to produce this
|
||||
kind of signal density at room level, not just at district level.
|
||||
|
||||
The data model already supports this: `ZonePalette` has `PaletteModifier` with
|
||||
`EconomicModifier`, `ConditionModifier`, `FactionModifier`, and `Heritage` sub-types.
|
||||
The architecture can do this — the product question is whether we commit to using it at
|
||||
room interior level.
|
||||
|
||||
**Options:**
|
||||
|
||||
| Option | Room interior differentiation |
|
||||
|--------|-------------------------------|
|
||||
| A. Function-typed only | Office/shop/residential. All offices look like offices. No economic signal. |
|
||||
| B. Function + condition tier | Office × (Pristine / Functional / Worn / Derelict). Economic health readable from maintenance state. |
|
||||
| C. Function + condition + ownership type | Office × condition × (corporate / individual / cooperative / abandoned). Ownership type shapes layout logic, not just surface condition. A corporate office and a sole-trader office in identical condition look structurally different. |
|
||||
| D. Full cascade | Every room interior is a read on its inhabitant's economic position, faction affiliations, heritage, and operational state. Room interiors are small information puzzles that reward observation. |
|
||||
|
||||
**Recommendation: D (full cascade) as the endgame target.**
|
||||
|
||||
Option D is the game's core proposition expressed at the smallest scale. If information
|
||||
asymmetry is the master mechanic, every space should reward the observant player with
|
||||
reads that the inattentive player misses. A room that only signals function (this is an
|
||||
office) gives the player nothing — they already knew it was an office. A room that
|
||||
signals "this is a sole-trader office, the business is struggling, the operator has
|
||||
Krenn heritage, and they've recently been in contact with a faction that usually operates
|
||||
at the docks" gives the tycoon or investigator a decision: do I approach this person?
|
||||
Are they a useful contact or a liability?
|
||||
|
||||
**The test:** Every room a player enters should contain at least one observable signal
|
||||
that they couldn't have predicted from the exterior. If the room tells them nothing new,
|
||||
the generator isn't doing its job.
|
||||
|
||||
---
|
||||
|
||||
## Systems summary: the cascade chain
|
||||
|
||||
The five questions above, when answered, define the information spine of the whole
|
||||
pipeline:
|
||||
|
||||
```
|
||||
System profile (Q1: economic axes)
|
||||
↓ cascades into
|
||||
Settlement identity (Q4: type + power + era)
|
||||
↓ which requires
|
||||
Topography (Q2: hard constraint — geography creates settlement character)
|
||||
↓ first player contact via
|
||||
Arrival experience (Q3: information front-load — 3-5 legible signals)
|
||||
↓ which resolves into
|
||||
Room interiors (Q5: full cascade — every space rewards observation)
|
||||
```
|
||||
|
||||
The through-line is: **the generator produces information; the player reads it; the
|
||||
asymmetry between what skilled and unskilled players can read IS the gameplay.**
|
||||
|
||||
Every design decision at every level of the cascade should be evaluated against this
|
||||
test: does this produce information the skilled player can exploit? If the answer is
|
||||
no, the feature is set dressing, not a system.
|
||||
|
||||
**The single highest-value decision:** Q1 (economic axes). Everything else in the cascade
|
||||
is downstream of what economic data the system profile carries. Get the economic axes
|
||||
right first, then design what each axis produces at each cascade level.
|
||||
@@ -0,0 +1,449 @@
|
||||
---
|
||||
title: "SW1-R2: Gestalt — Cross-Read Synthesis, Endgame Generation Vision"
|
||||
agent: gestalt
|
||||
workshop: world-generation
|
||||
round: 2
|
||||
type: synthesis
|
||||
created: 2026-03-24
|
||||
---
|
||||
|
||||
# SW1-R2: Gestalt — Cross-Read Synthesis
|
||||
|
||||
**Files read:** gestalt-sw1r1b, miri-sw1r1b, nigel-sw1r1b, ozzie-sw1r1b, tyre-sw1r1b,
|
||||
sw1-interview-answers, cultural-migration-pressure.md
|
||||
|
||||
**Angle:** Systems design. Where do the decisions create interesting mechanics? Where do
|
||||
they create architectural load? What needs to be resolved before the pipeline can be
|
||||
built?
|
||||
|
||||
---
|
||||
|
||||
## 1. Strong Alignment Between Agents and Product Owner Decisions
|
||||
|
||||
### Economic cascade: all agents, confirmed
|
||||
|
||||
Every agent's R1b output assumed economic context should cascade visibly from system
|
||||
profile to room level. Jeroen confirmed: "full economic profile — multiple industries,
|
||||
power players, historical disruptions. Every economic axis must cascade visibly to at
|
||||
least district and room level."
|
||||
|
||||
This validates the framing from my Q1 (economic axes as the spine of the cascade),
|
||||
Nigel's Q2 (geographic cascade drives economic character), and Tyre's Q1 (full economic
|
||||
profile as the hybrid-authored approach). The cascade is confirmed.
|
||||
|
||||
**Consequence:** The generator's output must carry economic encoding at every level.
|
||||
Districts tag economic character. Blocks tag economic role. Rooms are full simulation
|
||||
primitives (Jeroen confirmed). The data model already supports this with `EconomicModifier`
|
||||
on `ZonePalette` — but the specific economic axes from the wiki (supply dependency,
|
||||
distribution_index, faction economic role) need to be formalized as cascade inputs.
|
||||
|
||||
---
|
||||
|
||||
### Topography as hard constraint: all agents, confirmed
|
||||
|
||||
My Q2, Nigel's Q2, and Tyre's Q2/Q3 all recommended hard constraint (not cosmetic
|
||||
backdrop). Jeroen confirmed: "Hard constraint. Mountains block corridors, rivers create
|
||||
district boundaries, coastlines produce port districts."
|
||||
|
||||
**However, the implementation diverged from what any agent expected.**
|
||||
|
||||
Tyre proposed procedural terrain (abstract tags → noise heightmap → full generation).
|
||||
Jeroen's answer: authored world maps for all planets and moons. The generator reads
|
||||
authored topography, not generated topography.
|
||||
|
||||
This is architecturally simpler for the generator (no terrain generation algorithm)
|
||||
but shifts the load to authoring. The cascade is correct; the authoring pipeline needs
|
||||
specifying.
|
||||
|
||||
---
|
||||
|
||||
### Hybrid NPC scheduling: confirmed and extended
|
||||
|
||||
My Q3 recommended zone-baseline scheduling with triangle override. Jeroen confirmed
|
||||
hybrid — and added a third element: **any ambient NPC can evolve into a narrative NPC
|
||||
through player interaction.** No hard line between background and story characters.
|
||||
|
||||
This is more ambitious than any agent proposed, but architecturally coherent: if every
|
||||
NPC carries enough data to be interesting, and the simulation is running them, the
|
||||
player's interaction is what "promotes" them from ambient to story. The threshold is
|
||||
player attention, not generator assignment.
|
||||
|
||||
---
|
||||
|
||||
### Arrival as diegetic information front-load: confirmed
|
||||
|
||||
Ozzie recommended contextual by travel method with orbital view as default (D/C).
|
||||
Jeroen confirmed the same and added the specific mechanism: an insert context window
|
||||
opens with system stats, planetary screenshot, and GTTR narrative entry. The information
|
||||
front-load is diegetic — the player's insert device contains this data.
|
||||
|
||||
Ozzie's concern about the galaxy map as "homework" was answered differently: full
|
||||
information from start (the insert logically contains a 300-system chart), not layered
|
||||
unlockable. The "wonder" comes from the content being interesting, not from information
|
||||
being withheld.
|
||||
|
||||
---
|
||||
|
||||
### World lives before the player arrives: confirmed
|
||||
|
||||
Nigel's Q4 asked whether the world runs before player arrival. Jeroen confirmed: "Yes.
|
||||
Full economic + social + political background simulation." Needs its own design workshop.
|
||||
|
||||
The specific mechanism is simulation drift, not seeded variation. Same canonical starting
|
||||
state every run. The simulation runs on spare CPU cores. Exploration order and timing
|
||||
determine what you find — not seed parameters.
|
||||
|
||||
---
|
||||
|
||||
## 2. Tensions and Gaps
|
||||
|
||||
### Heritage roots deprecated — significant hit to the existing architecture
|
||||
|
||||
This is the biggest architectural tension from R1b.
|
||||
|
||||
**What was built against heritage roots:**
|
||||
- Miri's entire room grammar framework (Q5) — spatial grammar tokens, social pattern
|
||||
tokens, object selection tokens — all indexed to the 7 abstract roots (Frost, Stone,
|
||||
Tide, Vine, Dust, Iron, Salt)
|
||||
- The generator.rs data model: `HeritageRoot` type, `PaletteModifier::Heritage`
|
||||
- D-104 and D-105 (heritage grammar overlays) — explicitly flagged for supersession
|
||||
|
||||
**What replaces them:**
|
||||
Real-world cultural corridors from `cultural-migration-pressure.md`:
|
||||
- North reach: Commonwealth (British/Australian/Canadian/South African/Indian/Nigerian)
|
||||
- South reach: Iberian/Latin American + Southern African (Portuguese, Brazilian, Zulu)
|
||||
- East reach: East Asian + South/Southeast Asian (Chinese, Japanese, Korean, Vietnamese)
|
||||
- West reach: Northern/Central European + Central/Eastern European (German, Scandinavian,
|
||||
Dutch, Polish)
|
||||
|
||||
**What is NOT lost:** Miri's room grammar tokens are still valid design work. The
|
||||
spatial grammar layer (privacy_default, sightline_character, gathering_orientation,
|
||||
threshold_character), the social pattern layer (stranger_distance, group_size_prior,
|
||||
noise_level_prior), and the object selection layer are all still the right framework.
|
||||
What changes is the mapping: instead of "Frost root → privacy-first spatial grammar,"
|
||||
we need "Commonwealth corridor + dense urban settlement type → specific spatial grammar
|
||||
configuration."
|
||||
|
||||
**The gap:** No one has written the corridor-to-room-grammar mapping. This is the missing
|
||||
authoring artifact between the cultural-migration-pressure.md document and the generator.
|
||||
Without it, the generator cannot produce culturally differentiated rooms.
|
||||
|
||||
---
|
||||
|
||||
### Seed-based replayability replaced by simulation drift — Nigel's framework shifts
|
||||
|
||||
Nigel's Q1-Q5 all assumed seed variation as the primary replayability mechanism.
|
||||
Jeroen's answer: no seed variation at system profile or location level — same canonical
|
||||
starting state every run. Replayability comes from simulation trajectory differences.
|
||||
|
||||
**This is a deeper design position, not a contradiction.** Nigel correctly identified
|
||||
that "two players at the same system with different seeds should have completely different
|
||||
stories." Jeroen's mechanism achieves this differently: two players at the same system
|
||||
at different in-game times, or with different exploration histories, will find different
|
||||
situations because the simulation has diverged.
|
||||
|
||||
**Architectural consequence:** The generator's job is to produce the canonical starting
|
||||
state reliably, not to produce variety. Variety is the simulation's job. This changes
|
||||
what "generation quality" means: correctness and internal consistency matter more than
|
||||
seed variety. The generator can be deterministic and stable. The simulation produces
|
||||
the variance.
|
||||
|
||||
**What Nigel's framework contributes that survives:** The settlement biography concept
|
||||
(Q5) is still valuable, but as canonical authored content rather than seeded variation.
|
||||
Every settlement has a founding biography (why it exists, what shaped it) — that's
|
||||
wiki content (Miri/Paula territory). The simulation then runs forward from that starting
|
||||
state.
|
||||
|
||||
---
|
||||
|
||||
### NPC-driven and news-driven generation hooks: new, architectural load
|
||||
|
||||
Neither of these appeared in any agent's R1b. They have significant architectural
|
||||
consequences that aren't trivial to design around:
|
||||
|
||||
**NPC-driven generation:** "Get to know someone from a distant planet → their house,
|
||||
family, friends, neighborhood generate at that location. Their address becomes a real
|
||||
visitable place."
|
||||
|
||||
This means the generator is callable from the social simulation layer, not just from
|
||||
the player's location. The trigger is relationship depth, not player movement. The
|
||||
generator must be able to produce a partial location (one neighborhood, not an entire
|
||||
district) on-demand in response to a social event.
|
||||
|
||||
**News-driven generation:** "Reach-wide news reports an event in an east_reach town.
|
||||
That location must exist when the player visits."
|
||||
|
||||
This means the storyteller's news system creates existence claims about locations. The
|
||||
generator must resolve those claims before the player arrives. There needs to be a
|
||||
consistency buffer: a record of "the storyteller said X exists" that the generator
|
||||
checks on approach.
|
||||
|
||||
Both hooks mean generation is not purely player-location-driven. It's also
|
||||
socially-triggered and narratively-triggered. This is a richer system than any agent
|
||||
proposed but it requires coordination between the generation pipeline and the narrative/
|
||||
social simulation layers that don't currently exist.
|
||||
|
||||
---
|
||||
|
||||
### Environmental archaeology constraint: stricter than proposed
|
||||
|
||||
Ozzie's primary "world feels pre-existing" mechanism was environmental archaeology —
|
||||
evidence of things that happened before the player arrived.
|
||||
|
||||
Jeroen's constraint: **only from real simulation events.** No fabricated traces. If
|
||||
there's rubble, the simulation produced the explosion. If there's a memorial, someone
|
||||
died in the simulation.
|
||||
|
||||
This is the right design position (integrity > atmosphere) but it requires the simulation
|
||||
to be rich enough to produce these traces organically. A world where no simulation event
|
||||
has happened yet (new game, player's first location) is a world with no archaeology. The
|
||||
"someone was here before me" feeling is earned by running the simulation long enough.
|
||||
|
||||
**Implication:** The pre-game simulation run (background sim from canonical start) needs
|
||||
to produce enough events before the player's first move to seed the world with readable
|
||||
history. The background simulation design workshop needs to answer: how much pre-play
|
||||
simulation time is required to make a world feel lived-in?
|
||||
|
||||
---
|
||||
|
||||
### Authored world maps: large authoring commitment, format unspecified
|
||||
|
||||
Tyre identified Layer 2 (location profiles) as the biggest structural gap. Jeroen
|
||||
answered: extend the wiki. Every planet and moon gets an authored profile. This solves
|
||||
the gap structurally but creates a different question: how does an authored world map
|
||||
get consumed by the generator?
|
||||
|
||||
The format is unspecified. Options:
|
||||
- An annotated image (coastlines drawn as terrain type zones)
|
||||
- A structured data format (coastlines as polygon paths, mountain ranges as elevation
|
||||
vectors, biome zones as labeled regions)
|
||||
- A hybrid (authored image + structured metadata that the generator reads)
|
||||
|
||||
The generator needs to extract specific data from the world map: where are the coasts?
|
||||
Where can settlements plausibly go? What terrain blocks movement between districts? None
|
||||
of this is answerable from an image without additional tooling.
|
||||
|
||||
---
|
||||
|
||||
## 3. Architectural Consequences of the Combined Decisions
|
||||
|
||||
### The generator is a reader-and-filler, not a full procedural engine
|
||||
|
||||
With wiki-authored system profiles AND authored world maps AND cultural corridors already
|
||||
in systems.db, the generator's creative role is primarily at layers 6-8 of the cascade:
|
||||
|
||||
| Layer | Source | Generator role |
|
||||
|-------|--------|----------------|
|
||||
| Galaxy (300 systems) | systems.db — built | Read only |
|
||||
| Location profiles | Wiki — authoring pipeline | Read only |
|
||||
| Topography | Authored world maps — unspecified format | Read only |
|
||||
| Arrival | Template from location type + GTTR entry | Template stamp |
|
||||
| Content spidering | LOD/sim tier cascade | Trigger + manage |
|
||||
| Settlement placement | Authored topography + wiki economics | Constraint placement |
|
||||
| District skeleton | Existing data model | Full generation |
|
||||
| Rooms | Full simulation primitives | Full generation |
|
||||
|
||||
The generator is richly authored at the top and generative at the bottom. This is actually
|
||||
the right architecture for the game — the world's cultural and geographic character is
|
||||
too important to leave to procedural approximation. The generator's job is to produce
|
||||
specific spatial expression of rich authored world data.
|
||||
|
||||
**The efficiency gain:** Because layers 1-3 are authored, the generator gets high-quality
|
||||
inputs. The cultural pressure system (migration corridors, settlement wave, industrial
|
||||
overlay) produces district and room constraints that are historically grounded rather
|
||||
than invented.
|
||||
|
||||
**The cost:** Sustained authoring pipeline. Every new location in the game requires wiki
|
||||
content. The world's richness is bounded by the authoring team's capacity.
|
||||
|
||||
---
|
||||
|
||||
### Background simulation + "any NPC can evolve" = NPC universality requirement
|
||||
|
||||
The current generator architecture distinguishes between NPCs with triangle assignments
|
||||
(narrative characters) and ambient NPCs (filler). If any ambient NPC can become a
|
||||
narrative NPC through player interaction, this distinction collapses.
|
||||
|
||||
**Consequence:** Every generated NPC must carry a minimum data bundle sufficient to be
|
||||
an interesting person if the player chooses to pay attention. The NPC manifest from Phase
|
||||
2 (PreparedDistrict) cannot be split into "real" and "filler" NPCs. Every NPC needs:
|
||||
- Cultural background (derived from corridor + settlement biography)
|
||||
- Economic role (derived from zone function + district economic character)
|
||||
- Relationship network seed (family, colleagues, social affiliations)
|
||||
- Behavioral tell configuration (for the voice pipeline — D-138)
|
||||
- Enough data for a triangle to form if player interaction reaches threshold
|
||||
|
||||
This is a significant increase in per-NPC data compared to the current "ambient NPCs
|
||||
are lightweight fill" approach. The LOD qualifier (depth scales with player engagement)
|
||||
partially addresses this: NPCs can carry a compact profile that expands on demand. But
|
||||
the compact profile still needs to be rich enough that expansion is coherent, not
|
||||
fabricated.
|
||||
|
||||
---
|
||||
|
||||
### Canonical starting state + simulation drift = time is the replayability axis
|
||||
|
||||
The primary replayability mechanism is now: same world, different simulation trajectory.
|
||||
Two runs diverge based on:
|
||||
1. When the player visits each location (what the simulation has done to it by then)
|
||||
2. What the player does at each location (how player actions propagate through the sim)
|
||||
3. Which NPC relationships the player develops (which locations generate on demand)
|
||||
4. Which news events the storyteller generates (which existence claims create locations)
|
||||
|
||||
This is more interesting than seed variation because it produces genuinely emergent
|
||||
history rather than different presets. But it requires the simulation to be running
|
||||
meaningfully before the player's first decision. The background simulation workshop is
|
||||
the single most important design work after the generator pipeline itself.
|
||||
|
||||
---
|
||||
|
||||
### "Cohesion at small/middle scale, variety at middle/large scale" as the design law
|
||||
|
||||
Jeroen's key spatial design principle is worth making explicit as a rule:
|
||||
|
||||
- **Room → block level:** Cohesive. A single block should feel like it belongs to one
|
||||
identifiable zone/era/culture. The player should not feel like they're in randomly
|
||||
assembled space.
|
||||
- **District → settlement level:** Varied. Different districts should feel genuinely
|
||||
different. The player should notice when they cross a zone boundary.
|
||||
- **Settlement → system level:** Varied at the settlement identity level, but each
|
||||
settlement is internally coherent.
|
||||
|
||||
This rules out both "everything looks the same" (no variety) and "every room is a
|
||||
surprise" (no coherence). The generator enforces this through zone palette constraints
|
||||
(cohesion within zones) and district identity differences (variety between zones).
|
||||
|
||||
This also answers the era-layering question: era transitions should produce variety at
|
||||
the district/block boundary, not within a single block. A CorporateMerger block should
|
||||
feel consistently corporate, not randomly mixed.
|
||||
|
||||
---
|
||||
|
||||
## 4. Follow-Up Questions for the Product Owner
|
||||
|
||||
### Q1: What format do authored world maps take, and how does the generator consume them?
|
||||
|
||||
**Why this is load-bearing:** Everything at layers 3-6 of the cascade depends on the
|
||||
generator's ability to read topographic data. If world maps are images, the generator
|
||||
needs computer vision or a drawing tool with structured export. If they're structured
|
||||
data (polygon zones, elevation vectors), the generator can read them as data. If they're
|
||||
authored within a dedicated map-making tool, that tool needs to exist.
|
||||
|
||||
**Options:**
|
||||
|
||||
| Format | Authoring experience | Generator integration |
|
||||
|--------|---------------------|----------------------|
|
||||
| A. Annotated image only | Familiar (draw a map) | Requires interpretation layer — uncertain extraction |
|
||||
| B. Structured data (GeoJSON-style polygon zones + metadata) | Requires tooling or discipline | Direct generator consumption — precise |
|
||||
| C. Drawing tool with structured export | Best author experience | Depends on tool existence + export format |
|
||||
| D. Wiki markdown with topography table | Simplest authoring | Lowest fidelity — no geometric data |
|
||||
|
||||
**My recommendation:** B with a simple editor that produces B output. The generator
|
||||
needs geometric data (not text descriptions) to place settlements, determine district
|
||||
boundaries, and block movement corridors. This is the format question that unlocks
|
||||
layers 3-6 of the cascade.
|
||||
|
||||
---
|
||||
|
||||
### Q2: What is the minimum NPC data bundle at generation time?
|
||||
|
||||
**Why this is load-bearing:** If any ambient NPC can become a narrative NPC, every NPC
|
||||
generated by the system needs to carry enough data to be real. What is "enough"? What
|
||||
must be generated at Phase 2 fill time vs. what can be generated on demand when the
|
||||
player's attention activates it?
|
||||
|
||||
**Two approaches:**
|
||||
|
||||
| Approach | Phase 2 generates | On-demand expands |
|
||||
|---------|------------------|------------------|
|
||||
| A. Compact seed | Name, role, corridor background, economic tier | Everything else: family, history, voice, relationships |
|
||||
| B. Full profile | Complete NPC including relationship graph, history, voice profile | Only triangle assignment (if player interaction reaches threshold) |
|
||||
|
||||
Option A minimizes generation cost and save file size but requires on-demand expansion
|
||||
to be fast and coherent (not obviously fabricated). Option B is more expensive but
|
||||
ensures NPCs are fully formed before the player sees them.
|
||||
|
||||
**The implication for voice pipeline (D-138):** The voice pipeline requires tell behaviors
|
||||
and culture_id at generation time. That data must be in the minimum bundle. What else
|
||||
is required at that same moment?
|
||||
|
||||
---
|
||||
|
||||
### Q3: What does the corridor-to-room-grammar mapping look like?
|
||||
|
||||
**Why this is load-bearing:** Heritage roots are deprecated. The real-world cultural
|
||||
corridors (Commonwealth, Iberian/Latin/Southern African, East Asian, Northern European)
|
||||
now drive cultural character. But the generator still needs a mapping from corridor
|
||||
identity to spatial grammar — which rooms have which privacy configuration, which NPC
|
||||
behavioral defaults, which object palette.
|
||||
|
||||
Miri's token framework (Layer 1: spatial grammar, Layer 2: social pattern, Layer 3:
|
||||
object selection) is the right structure. The question is who authors the corridor →
|
||||
token mapping, and in what format.
|
||||
|
||||
**The design question for Jeroen:** Is the corridor-to-room-grammar mapping:
|
||||
- A. Authored as wiki content per corridor (Miri territory)
|
||||
- B. Specified as a design table in decisions/ and fed to the generator as a parameter set
|
||||
- C. Implicitly encoded in the world map + settlement data (the generator infers room
|
||||
character from economic and cultural inputs without a separate mapping document)
|
||||
|
||||
Option C would be elegant but requires the economic and cultural inputs to carry enough
|
||||
signal to determine spatial grammar at room level. Option A/B requires authoring the
|
||||
mapping explicitly. This is a design decision that should happen before Phase 2 room fill
|
||||
is implemented.
|
||||
|
||||
---
|
||||
|
||||
### Q4: What's the pre-play simulation strategy to seed world history before the player's first move?
|
||||
|
||||
**Why this is load-bearing:** Environmental archaeology can only come from real simulation
|
||||
events. The background simulation produces replayability through drift. But a new game
|
||||
starts from canonical state. Without pre-play simulation time, the world has no history
|
||||
when the player arrives — no traces, no drift, no lived-in feel.
|
||||
|
||||
**Options:**
|
||||
|
||||
| Option | Mechanism | Player experience |
|
||||
|--------|-----------|------------------|
|
||||
| A. No pre-play sim | World is in pristine canonical state at game start | Clean but artificial — nothing has happened yet |
|
||||
| B. Fast-forward simulation | On new game, simulate N in-game months at high speed before player takes control | World has history when player starts; costs real time |
|
||||
| C. Pre-authored canonical events | Wiki authors seed specific historical events into the canonical state (the gas main exploded, the company went under) — simulation inherits these as starting conditions | World history is authored, not simulated; consistent across all runs |
|
||||
| D. Hybrid | Pre-authored major events (canonical history) + pre-play fast-forward for minor state | Major history authored; minor variation from simulation |
|
||||
|
||||
Option C is consistent with the "authored quality" approach Jeroen has taken at layers
|
||||
1-3. Major historical events that shape the world's starting state are authored (Paula
|
||||
territory — conflict history, corporate history, political events). The simulation then
|
||||
runs forward from that richer starting point. Option D is probably the right answer:
|
||||
authored backbone + simulated detail.
|
||||
|
||||
The background simulation design workshop should include pre-play simulation strategy
|
||||
as a primary agenda item.
|
||||
|
||||
---
|
||||
|
||||
## Systems Design Summary: What We Now Know
|
||||
|
||||
**The generator's role is well-defined:**
|
||||
- Reads rich authored inputs (systems.db, wiki profiles, world maps, cultural corridor
|
||||
data)
|
||||
- Produces specific spatial expression of that data (districts, blocks, rooms)
|
||||
- Calls out to simulation systems for NPC population and economic state
|
||||
- Is itself callable from social and narrative layers (NPC-driven and news-driven hooks)
|
||||
|
||||
**The four unresolved design questions:**
|
||||
1. World map format (determines layers 3-6)
|
||||
2. Minimum NPC data bundle (determines Phase 2 NPC generation cost)
|
||||
3. Corridor-to-room-grammar mapping (determines cultural character at room level)
|
||||
4. Pre-play simulation strategy (determines whether the world feels lived-in at game start)
|
||||
|
||||
**The one critical workshop still needed:**
|
||||
Background simulation design. Without it, replayability is undefined, NPC evolution is
|
||||
undefined, and environmental archaeology is undefined. This is the most important
|
||||
upstream dependency for everything the generator produces.
|
||||
|
||||
**The test I keep coming back to:**
|
||||
Can the player stand in a room in the east reach — a bar owned by a Vietnamese-heritage
|
||||
family in a Syndic-aligned manufacturing district — and read backward from the room's
|
||||
spatial grammar, NPC behavior, and economic condition to the corridor/settlement/district
|
||||
context that produced it? If yes, the cascade is working. If no, one of the four
|
||||
unresolved questions above hasn't been answered.
|
||||
@@ -0,0 +1,344 @@
|
||||
---
|
||||
title: "SW1-R3: Gestalt — Endgame Feature Vision, Systems Design"
|
||||
agent: gestalt
|
||||
workshop: world-generation
|
||||
round: 3
|
||||
type: endgame-vision
|
||||
created: 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
|
||||
@@ -0,0 +1,283 @@
|
||||
---
|
||||
title: "Miri SW1-R1 — Cultural Generation Product Questions"
|
||||
description: "Product questions for the product owner on how cultural identity flows into world generation"
|
||||
type: workshop
|
||||
status: draft
|
||||
workshop: world-generation
|
||||
subworkshop: 1
|
||||
agent: "miri"
|
||||
round: 1
|
||||
created: 2026-03-24
|
||||
---
|
||||
|
||||
# World Generation Workshop — Sub-Workshop 1, Round 1: Miri (Worldbuilder)
|
||||
|
||||
**Topic:** How cultural identity flows into world generation — product questions for Jeroen.
|
||||
**Date:** 2026-03-24
|
||||
**Scope:** 5 questions, each with options and a recommendation.
|
||||
|
||||
---
|
||||
|
||||
## Context Check Before the Questions
|
||||
|
||||
The Generator Architecture Workshop (February 2026) locked a solid foundation I'm working
|
||||
within. Key confirmed decisions relevant to my angle:
|
||||
|
||||
- **Heritage roots** (D-104, D-105): Seven canonical roots — Frost, Stone, Tide, Vine, Dust,
|
||||
Iron, Salt. Each maps to spatial grammar rules applied at Phase 2 chunk fill.
|
||||
- **Heritage overlay at Phase 2 only** (D-104): `HeritageGrammarOverlay` structs (10 per root)
|
||||
applied during chunk fill by weighted blending. `gathering_probability` is the one exception
|
||||
evaluated during Phase 1 block planning.
|
||||
- **ZonePalette modifier axis A = heritage root** (D-101): Visual identity at a glance,
|
||||
without a label.
|
||||
- **Grid vs. Organic layout modes** (D-096): These encode political history
|
||||
(Commission-planned vs. pioneer/growth), NOT heritage root. Cultural grammar and spatial
|
||||
layout mode are currently on separate axes.
|
||||
- **Culture implicit in starting location** (D-128): Van Maanen's Star = Van Maanen's Star
|
||||
culture. No character creation menu.
|
||||
- **Trauma intensifies culture, does not transform it** (D-107): Design principle already
|
||||
locked — heritage root as amplifier under stress.
|
||||
|
||||
The five questions below target genuine gaps the prior workshop did not close.
|
||||
|
||||
---
|
||||
|
||||
## Q1 — How many heritage root profiles need to be authored for v0.2?
|
||||
|
||||
**The question:** We have 7 canonical heritage roots. How many need fully authored profiles
|
||||
(visual grammar, voice modifiers, behavior primitives, naming conventions) before the tycoon
|
||||
bookmark ships?
|
||||
|
||||
**Why it matters:** D-128 says culture is implicit in the starting location. That means v0.2
|
||||
only *requires* the heritage blend of the starting district. But if we author too few profiles,
|
||||
we create a setting that visually homogenises the starting system — every district looks like a
|
||||
variation on the same heritage. If we require all 7 upfront, we front-load substantial authoring
|
||||
cost on systems that will be unreachable at launch.
|
||||
|
||||
**Options:**
|
||||
|
||||
A. **One only** — author the dominant heritage root of the starting district (e.g., if Sova
|
||||
Transit is primarily Iron-heritage, author Iron fully). Other roots are blank; generator
|
||||
falls back to default palette. *(Minimal cost, visible gap: any NPC or district that carries
|
||||
secondary heritage feels like the default.)*
|
||||
|
||||
B. **Roots present in the starting location's blend** — if the starting district is, say,
|
||||
Iron(0.6) + Stone(0.4), author both fully. Other roots are stubs. *(Targeted cost, covers
|
||||
the playable surface area for launch.)*
|
||||
|
||||
C. **Three to four "pillar" roots** — select the culturally richest contrasting roots as the
|
||||
v0.2 foundation (e.g., Frost, Tide, Iron, Stone), regardless of starting location blend.
|
||||
Gives the setting visible cultural range within the launch system without 7-root authoring.
|
||||
*(Medium cost; requires deliberate selection of which roots represent maximal contrast.)*
|
||||
|
||||
D. **All 7 before v0.2** — every root fully authored. *(Full worldbuilding surface, high cost,
|
||||
likely a stretch goal.)*
|
||||
|
||||
**My recommendation: B.** Author what is genuinely playable at launch. The starting location
|
||||
blend determines the authoring scope. This also forces a prior decision: we need to know the
|
||||
heritage blend of the starting district *now*, before authoring begins. Consider that a
|
||||
dependent deliverable.
|
||||
|
||||
---
|
||||
|
||||
## Q2 — Does heritage root influence district layout geometry (Phase 1) or only surface
|
||||
expression (Phase 2)?
|
||||
|
||||
**The question:** Currently D-104 is explicit: heritage overlay applies at Phase 2 chunk fill.
|
||||
D-096's Grid/Organic mode handles spatial structure via political history (Commission-planned vs.
|
||||
pioneer). The question is whether heritage root should also contribute *spatial targets* during
|
||||
Phase 1 block planning — things like open-space ratio, building proximity density, gathering
|
||||
infrastructure frequency.
|
||||
|
||||
**Why it matters:** A Frost community (individual space valued, privacy is physical distance)
|
||||
should feel geometrically different from a Tide community (collective gathering, proximity is
|
||||
comfort). If heritage only affects surface materials and object placement, two districts with
|
||||
identical Grid/Organic modes will share the same *spatial* feel. This means a player who
|
||||
understands Frost culture cannot use spatial reading to identify a Frost district before
|
||||
reading any labels. That's a missed legibility opportunity.
|
||||
|
||||
**Options:**
|
||||
|
||||
A. **Status quo — heritage stays Phase 2 only.** Layout is political (Grid/Organic), culture
|
||||
is cosmetic (Phase 2 surface). Simpler architecture, less legibility.
|
||||
|
||||
B. **Lightweight Phase 1 targets per heritage root.** Add 2-3 numeric targets to each heritage
|
||||
root profile: `open_space_ratio_target`, `building_proximity_weight`,
|
||||
`gathering_infrastructure_weight`. These feed into Phase 1 block planning as soft biases,
|
||||
not hard constraints. Grid/Organic mode remains independent. *(Low architectural cost,
|
||||
meaningful spatial legibility gain.)*
|
||||
|
||||
C. **Full Phase 1 integration.** Heritage root drives block shape preferences, street width
|
||||
distributions, and courtyard/void placements at Phase 1. Requires rearchitecting Phase 1
|
||||
block planning to accept cultural parameters. *(High cost, maximum spatial legibility.)*
|
||||
|
||||
**My recommendation: B.** The 2-3 numeric target approach is architecturally cheap and
|
||||
delivers the key design benefit: a Frost district reads differently at the structural level
|
||||
from a Tide district, before the player has read a single label or seen a single NPC. This
|
||||
aligns with D-101's stated goal ("a zone's visual identity must be legible at a glance") but
|
||||
extends it from visual to spatial. D-104 already has `gathering_probability` in Phase 1 as a
|
||||
precedent — this is extending that pattern.
|
||||
|
||||
---
|
||||
|
||||
## Q3 — How does cultural mixing work at district boundaries?
|
||||
|
||||
**The question:** The setting is explicit that corridors are gradients, not borders. Cultural
|
||||
mixing is real — migration, trade routes, and sequential-hop travel produce blended communities
|
||||
throughout the Reach. But the generator workshop did not define what the generator *does* when
|
||||
two heritage-differentiated communities are adjacent. How does the boundary between a Frost
|
||||
district and a Tide district behave?
|
||||
|
||||
**Why it matters:** This is where the setting's most interesting human drama lives. The boundary
|
||||
between collectivist and individualist communities, between Commission-heritage and
|
||||
pioneer-heritage, between old and new settlement — these are sources of NPC motivation, economic
|
||||
friction, and player intrigue. If the generator produces a hard cut with no in-between,
|
||||
the world loses the gradients that make it feel real.
|
||||
|
||||
**Options:**
|
||||
|
||||
A. **Hard district borders.** Each district has a single dominant heritage root.
|
||||
Two adjacent districts with different roots have a hard visual/cultural cut.
|
||||
*(Simple, legible, but unrealistic and misses the setting's gradient principle.)*
|
||||
|
||||
B. **Weighted blend within boundary districts.** Districts adjacent to contrasting heritage
|
||||
districts receive a heritage blend weighted toward both neighbors. A district between
|
||||
Iron(0.8) and Tide(0.8) becomes Iron(0.5)+Tide(0.5). Visually expresses the mixing.
|
||||
*(Medium complexity; requires heritage weights to propagate at generation time, not just
|
||||
per-district.)*
|
||||
|
||||
C. **Dedicated hybrid zone archetypes.** Create explicit zone types for cultural
|
||||
mixing: "junction quarter," "trade market," "transit node." These zones carry formal
|
||||
cultural-hybrid identity — they are *designed* places that exist *because* two cultures
|
||||
meet. *(Higher authoring cost but produces the richest gameplay territory. The market
|
||||
between two communities is always more interesting than either community alone.)*
|
||||
|
||||
D. **Passive overlap — mixing only in NPC backgrounds and naming.** Districts are
|
||||
culturally monolithic spatially, but NPC generation allows cross-heritage backgrounds,
|
||||
and place names reflect historical mixing. Visual districts are clean; social texture
|
||||
carries the blending. *(Low implementation cost, limits spatial legibility of mixing.)*
|
||||
|
||||
**My recommendation: C for urban hubs (Full-complexity districts), B for rural/wilderness.**
|
||||
Junction archetypes are already gameplay-rich territory — they're where the most interesting
|
||||
NPCs congregate, where the most ambiguous social signals appear, where the player can most
|
||||
easily operate without tribal affiliation. These deserve deliberate spatial design, not just a
|
||||
blended palette. For smaller or more remote communities, B handles the gradient adequately
|
||||
without requiring a new archetype.
|
||||
|
||||
---
|
||||
|
||||
## Q4 — Does cultural naming derive from generative grammar rules or authored flat lists?
|
||||
|
||||
**The question:** Districts, streets, establishments, and NPCs need names that carry cultural
|
||||
signature. D-138 already noted that Van Maanen's Star naming conventions differ structurally
|
||||
from other cultures and that the name extractor must eventually be culture-aware. The question
|
||||
is whether we author naming *rules* (syllable patterns, compound structures, phonological
|
||||
constraints per heritage root) or naming *lists* (finite authored pools the generator draws
|
||||
from).
|
||||
|
||||
**Why it matters:** Naming is the fastest cultural signal the player encounters — before any
|
||||
NPC dialogue, before any visual cues, the name of the street or the building is already
|
||||
communicating cultural identity. A generative grammar produces consistent cultural flavor at
|
||||
infinite scale but requires upfront design investment per heritage root. A flat list is quicker
|
||||
to produce but exhausts in large worlds and creates repetition that breaks immersion.
|
||||
|
||||
**Options:**
|
||||
|
||||
A. **Flat lists per heritage root.** Authored pools of street names, district names, building
|
||||
names. Generator draws from pools. *(Fast to produce, visible repetition in large worlds.)*
|
||||
|
||||
B. **Grammar rules per heritage root.** Syllable patterns, compound word rules, suffix/prefix
|
||||
inventories enabling infinite unique generation. *(High upfront investment, infinite scale,
|
||||
fully consistent cultural signature.)*
|
||||
|
||||
C. **Hybrid: grammar for infrastructure (streets, districts, transport nodes), authored
|
||||
lists for commercial/social establishments.** Street names and district names are
|
||||
generated from grammar rules (the world needs these at generation time, and they should feel
|
||||
systematic). Establishment names and colloquial NPC references draw from authored lists
|
||||
(these benefit from authored texture and specificity). *(Medium cost, appropriate tool
|
||||
for each layer.)*
|
||||
|
||||
**My recommendation: C.** The hybrid approach matches the use cases: streets are procedural
|
||||
infrastructure that needs to scale and feel architecturally consistent; the bar named after a
|
||||
local folktale needs authored specificity to feel real. Grammar for structure, authored
|
||||
lists for flavor. The grammar rules also serve as cultural documentation — they encode the
|
||||
*logic* of what names in a given heritage root sound like, which feeds Mellanie's voice card
|
||||
work and the LLM re-voicing pipeline (D-138).
|
||||
|
||||
---
|
||||
|
||||
## Q5 — How does galactic corridor position map to heritage root probability weights?
|
||||
|
||||
**The question:** The world has macro-level cultural corridors — the North Reach, South Reach,
|
||||
East Reach, West Reach, and the core — each with dominant cultural drifts from original
|
||||
settlement patterns and migration history. Individual systems sit within these corridors and
|
||||
carry regional heritage blends. But the generator workshop didn't define how a location's
|
||||
corridor position translates into a heritage root probability weight on its districts.
|
||||
|
||||
This is workshop brief question 6 restated concretely: "Corridor heritage → architectural
|
||||
style → tile palette selection" — where does the corridor → heritage assignment happen, and
|
||||
who authors it?
|
||||
|
||||
**Why it matters:** If heritage root blends are fully hand-authored per system, the generator
|
||||
can't produce new locations without designer input. If heritage derives from corridor position
|
||||
automatically, we get emergent cultural geography — the world feels like it has history even
|
||||
in locations no one has scripted.
|
||||
|
||||
**Options:**
|
||||
|
||||
A. **Per-system hand-authored heritage blends.** Each system wiki entry specifies its heritage
|
||||
root weights. Generator uses these directly. *(Full authorial control, doesn't scale to
|
||||
unpopulated systems or procedurally generated frontier worlds.)*
|
||||
|
||||
B. **Corridor zone → heritage probability table.** A mapping table defines heritage root
|
||||
probability weights per corridor zone (and distance from galactic core). New systems draw
|
||||
their initial heritage blend from this table plus a seed-driven variance. Authors tune the
|
||||
table; the generator handles individual systems. *(Scales to procedural worlds; corridor
|
||||
cultural identity becomes a tuneable parameter. Requires authoring the corridor table once,
|
||||
not per-system.)*
|
||||
|
||||
C. **Cultural drift simulation.** Heritage roots diffuse across the galactic map based on
|
||||
simulated migration, distance from origin worlds, and trade route topology. The emergent
|
||||
cultural geography reflects actual setting history. *(Most ambitious, highest authoring
|
||||
investment, endgame vision — not v0.2.)*
|
||||
|
||||
**My recommendation: B for v0.2.** A corridor probability table is a one-time authoring
|
||||
deliverable that enables the generator to produce culturally coherent locations anywhere in
|
||||
the Reach, not just at hand-authored systems. It's also the setting document that encodes
|
||||
the macro-cultural shape of the universe — who settled where, what waves of migration
|
||||
produced what blends. I can draft this table once Jeroen confirms the corridor cultural
|
||||
identities. Option C is what this table eventually approximates; B is the practical version
|
||||
for launch.
|
||||
|
||||
---
|
||||
|
||||
## Summary Table
|
||||
|
||||
| # | Question | My Recommendation |
|
||||
|---|----------|-------------------|
|
||||
| 1 | How many heritage roots to author for v0.2? | **B** — roots present in starting district blend only |
|
||||
| 2 | Does heritage influence layout geometry or surface only? | **B** — lightweight Phase 1 numeric targets per root |
|
||||
| 3 | How does cultural mixing work at boundaries? | **C** (urban hubs) + **B** (rural/wilderness) |
|
||||
| 4 | Naming from generative grammar or flat lists? | **C** — grammar for infrastructure, lists for establishments |
|
||||
| 5 | How does corridor position → heritage blend? | **B** — corridor probability table |
|
||||
|
||||
---
|
||||
|
||||
## Upstream Dependency I'm Flagging
|
||||
|
||||
Before any of these questions can be fully answered, one prior question needs Jeroen's input:
|
||||
|
||||
**What is the heritage root blend of the starting district (Sova Transit / Van Maanen's Star)?**
|
||||
|
||||
This is the foundational content decision that all of Q1, Q2, and Q3 depend on. I have
|
||||
working hypotheses from the setting history (Sova Transit as a 40-year-old logistics hub
|
||||
with Commission infrastructure and pioneer-era organic growth suggests an Iron/Stone blend
|
||||
with Tide undertow from the tight-community dynamics of a small-station population). But
|
||||
this is a product decision, not a worldbuilding derivation — the blend should reflect what
|
||||
emotional register Jeroen wants the starting experience to carry.
|
||||
|
||||
---
|
||||
|
||||
**Author:** Miri
|
||||
**Date:** 2026-03-24
|
||||
**Status:** Ready for product owner review.
|
||||
@@ -0,0 +1,397 @@
|
||||
---
|
||||
title: "Miri SW1-R1b — Endgame Cultural Cascade"
|
||||
description: "Product questions on the full cultural cascade from galactic corridors to individual rooms — endgame vision, no v0.2 scoping"
|
||||
type: workshop
|
||||
status: draft
|
||||
workshop: world-generation
|
||||
subworkshop: 1
|
||||
agent: "miri"
|
||||
round: "1b"
|
||||
created: 2026-03-24
|
||||
---
|
||||
|
||||
# World Generation Workshop — SW1 Round 1b: Miri (Worldbuilder)
|
||||
|
||||
**Topic:** The endgame cultural cascade — galaxy to room, top-down.
|
||||
**Date:** 2026-03-24
|
||||
**Scope:** Full design vision. No v0.2 constraints.
|
||||
|
||||
---
|
||||
|
||||
## The Architecture Being Designed
|
||||
|
||||
The cultural cascade has eight levels. Each level inherits from the one above it and adds
|
||||
local constraints. The questions below target the decisions that shape the whole cascade —
|
||||
where the authored inputs live, where generation takes over, and where the cascade can
|
||||
produce genuinely unexpected output that still feels culturally coherent.
|
||||
|
||||
```
|
||||
Galaxy map → corridor zones and their cultural gravity
|
||||
↓
|
||||
System profile → heritage root probability weights per system
|
||||
↓
|
||||
Environment → planet/station type × heritage root = cultural register
|
||||
↓
|
||||
Inbound gateway → the cultural identity visible on arrival
|
||||
↓
|
||||
Settlement layout → heritage root × terrain = settlement topology
|
||||
↓
|
||||
District character → heritage blend × political history = spatial grammar
|
||||
↓
|
||||
Building identity → heritage root × building function = room character
|
||||
↓
|
||||
Room grammar → layout tokens + object tokens + social pattern tokens
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Q1 — Origin worlds or universal distribution: how do heritage roots map to the galaxy?
|
||||
|
||||
**The question:** Are heritage roots geographically anchored — originating in specific
|
||||
settlement corridors and diffusing outward — or are they properties any community can
|
||||
independently develop, distributed uniformly across the galaxy with just probabilistic
|
||||
weighting by corridor?
|
||||
|
||||
**Why it matters for the cascade:** This is the foundational decision. If heritage roots
|
||||
have origin geographies, the galaxy has a legible cultural history: a player who travels
|
||||
from the core to the East Reach is watching culture change, can infer migration patterns,
|
||||
and can recognize that an Iron-dominant community in a traditionally Tide corridor is a
|
||||
diaspora or an economic migrant wave. If roots are universally distributed, the galaxy has
|
||||
cultural texture everywhere but no cultural geography — no sense of having arrived somewhere
|
||||
with a specific historical relationship to the rest of civilization.
|
||||
|
||||
The corridor probability table I proposed in the previous round (Q5) is a minimal version
|
||||
of Option B. This question is whether we go deeper.
|
||||
|
||||
**Options:**
|
||||
|
||||
A. **Universal distribution with corridor weights.** Any heritage root can appear anywhere.
|
||||
Corridor maps define probability weights. A Frost community in the South Reach is unusual
|
||||
but possible; the generator doesn't know or care why it's there. *(Simplest generation,
|
||||
no cultural history baked in. Corridors are tendencies, not explanations.)*
|
||||
|
||||
B. **Origin-world model with diffusion.** Each heritage root has one or more canonical
|
||||
origin systems — the places where that cultural pattern first crystallized in the Reach.
|
||||
Heritage probability decays with distance from origin systems, modified by trade route
|
||||
topology (routes carry cultural influence further than raw distance). A map of heritage
|
||||
root probability density across the 300 systems is derivable and plausible. *(One authored
|
||||
input — the origin system table — generates the entire cultural geography of the Reach.)*
|
||||
|
||||
C. **Corridor identity as authored historical assertion.** Each corridor (North/South/East/West
|
||||
Reach, core, frontier) has a named cultural identity that is a settled historical fact of
|
||||
the setting — not generated, but a product of the setting's backstory. The generator
|
||||
uses corridor identity as a strong prior, with local variation seeded per system.
|
||||
*(More expressive than A, less mechanically complex than B. Corridors are characters.)*
|
||||
|
||||
D. **Wave model — sequential settlement history.** The Reach was settled in waves, each wave
|
||||
carrying a dominant cultural pattern outward from the core. Early waves = Iron/Stone
|
||||
(industrial pioneers). Second wave = Tide/Vine (community builders following the
|
||||
industrial frontier). Third wave = Frost/Dust (frontier individualists and collective
|
||||
idealists pushing beyond established systems). The wave model bakes cultural history
|
||||
into spatial form: older, more core-adjacent systems have earlier-wave culture; frontier
|
||||
systems have later-wave culture. Settlement age correlates with heritage root.
|
||||
*(Rich, emergent, self-consistent history — but requires designing the wave chronology.)*
|
||||
|
||||
**My recommendation: D as the endgame model, C as the generation input.**
|
||||
|
||||
The wave model is the most coherent worldbuilding framework — it explains *why* cultures
|
||||
are distributed the way they are, not just *that* they are. It also produces a galaxy where
|
||||
a player who understands the history can navigate culturally: "frontier systems will likely
|
||||
be Frost or Dust, so I should calibrate my approach accordingly."
|
||||
|
||||
But D is a worldbuilding document, not a generator parameter. The generator input is C:
|
||||
corridor identity as historical assertion derived from the wave model. Write the wave
|
||||
chronology once; derive the corridor cultural profiles from it; feed those profiles to the
|
||||
generator. This is authored at the setting level but generative at the system level.
|
||||
|
||||
---
|
||||
|
||||
## Q2 — Environment × heritage: does physical context modulate cultural expression?
|
||||
|
||||
**The question:** The same heritage root expressed in different environments should feel
|
||||
different. A Frost community (individual space, cold reserve, privacy through physical
|
||||
distance) on an ice world is in perfect alignment with its environment — the culture and
|
||||
the planet reinforce each other. A Frost community on a tropical world is in tension — the
|
||||
cultural instinct is to maintain distance, but the physical environment produces lushness,
|
||||
proximity, shared resource pressure on water and shade.
|
||||
|
||||
Does environment modify cultural expression? And if so, how deeply?
|
||||
|
||||
**Why it matters:** Without environment × heritage interaction, every Frost community looks
|
||||
the same regardless of where it is. With it, the cascade produces genuine diversity — the
|
||||
same root in different contexts produces recognizably related but distinct expressions.
|
||||
This is how the 7 heritage roots generate far more than 7 cultural textures.
|
||||
|
||||
**Options:**
|
||||
|
||||
A. **Heritage is invariant; environment is cosmetic only.** A Frost community on a tropical
|
||||
world uses the same spatial grammar and NPC behavior as a Frost community on an ice world.
|
||||
The palette changes (tropical materials, warm lighting) but the social structure and layout
|
||||
tokens are identical. *(Simpler, culturally poorer.)*
|
||||
|
||||
B. **Environment × heritage produces a fixed set of canonical registers.** Each heritage
|
||||
root has defined environmental expressions: Frost-cold, Frost-temperate, Frost-tropical,
|
||||
Frost-high-gravity, Frost-station-interior. Each register is a distinct authored variant
|
||||
with its own layout targets, social grammar modifiers, and visual character. *(High
|
||||
authoring cost, excellent cultural depth. 7 roots × 5 environment types = 35 canonical
|
||||
profiles, each a valid cultural identity.)*
|
||||
|
||||
C. **Environment modulates heritage along continuous axes.** Instead of discrete registers,
|
||||
environment parameters (temperature, density, resource pressure, enclosure) shift heritage
|
||||
expression along continuous dimensions. A Frost community's `individual_space_radius`
|
||||
shrinks under resource pressure; its `gathering_probability` increases in enclosed
|
||||
station environments where isolation is psychologically unsustainable. *(Generative,
|
||||
infinite variety, harder to author but self-consistent. Emergent output rather than
|
||||
designed output.)*
|
||||
|
||||
D. **Cultural mismatch as narrative material.** When a heritage root is in tension with
|
||||
its environment, the generator produces overt tension markers: NPC behavioral friction,
|
||||
social patterns that are clearly compensatory, architectural adaptations that reveal the
|
||||
original cultural instinct straining against a hostile context. A Frost community on a
|
||||
tropical world builds walls everywhere, creates shade corridors, marks territory visibly —
|
||||
the architecture is the community's argument with its environment. *(The most
|
||||
worldbuilding-rich approach. Mismatch is information; adaptation is history.)*
|
||||
|
||||
**My recommendation: C with D as the expressive layer.**
|
||||
|
||||
Continuous axis modulation (C) is the endgame generative model. It scales to any
|
||||
environment type without requiring 35 pre-authored profiles. But D should not be discarded —
|
||||
cultural mismatch is exactly where the most interesting NPC stories live. A character whose
|
||||
cultural instincts are structurally opposed to the environment they were born in is a
|
||||
character under permanent low-level pressure. That pressure is narrative.
|
||||
|
||||
Implement C as the baseline; D as the output when environment × heritage tension exceeds a
|
||||
threshold. Below threshold: subtle adaptation. Above threshold: architectural and behavioral
|
||||
compensation that a perceptive player can read as cultural history.
|
||||
|
||||
---
|
||||
|
||||
## Q3 — Cultural time: does long-stable blending produce irreducible hybrid identity?
|
||||
|
||||
**The question:** A community with a 60/40 Iron+Tide blend that has been stable for
|
||||
200 years is not simply "60% Iron things plus 40% Tide things." It has developed specific
|
||||
idioms, accommodations, and patterns that belong to neither parent culture — a hybrid
|
||||
identity that is its own thing. The labor solidarity of Iron culture modified by the
|
||||
communal grief practices of Tide culture produces something that Iron communities elsewhere
|
||||
wouldn't recognize as "theirs," and Tide communities elsewhere wouldn't recognize as
|
||||
"theirs" either.
|
||||
|
||||
Does the endgame system model this? And if so, what triggers hybrid identity formation?
|
||||
|
||||
**Why it matters:** Without this, all cultural blending is simple mixing. With it,
|
||||
old communities that have maintained a stable blend are qualitatively different from
|
||||
young communities with the same raw numbers. Age and stability produce cultural
|
||||
distinctiveness — which produces the setting's most interesting locations.
|
||||
|
||||
**Options:**
|
||||
|
||||
A. **No emergent hybrids — blending is always proportional.** A 60/40 Iron+Tide community
|
||||
is always just "60% Iron behaviors + 40% Tide behaviors." Clean, no modeling required.
|
||||
All cultural identity is traceable to its roots. *(Flat, historically thin.)*
|
||||
|
||||
B. **Named hybrid archetypes for high-frequency stable blends.** Some blends are common
|
||||
and historically significant enough to receive authored hybrid identities. Iron+Tide =
|
||||
"labor-solidarity culture" (specific named cultural type with its own grammar). Stone+Frost
|
||||
= "territorial quiet" (another named type). These are designed rather than simulated;
|
||||
they're the cultural equivalents of the Sova Transit district's specific identity.
|
||||
*(Finite, authored richness. The named hybrid types are setting texture.)*
|
||||
|
||||
C. **Simulated hybrid formation via cultural stability timer.** Communities accrue a
|
||||
"cultural coherence" score over time. Above a threshold (e.g., 150 years of stable blend
|
||||
within ±10% variance), the generator adds hybrid markers: naming patterns that blend
|
||||
both roots, architectural idioms specific to the combination, NPC behavioral tells that
|
||||
are recognizable to neither parent culture. The hybrid markers are procedurally derived
|
||||
from the specific blend ratio and the dominant environment. *(Endgame generative model.
|
||||
Every old stable community develops its own specific character.)*
|
||||
|
||||
D. **Trauma as hybrid accelerant.** Communities that survive a shared trauma together
|
||||
(D-107's trauma event model) accelerate toward hybrid identity — the shared event
|
||||
becomes the cultural referent that supersedes root identity. A community that was 70/30
|
||||
Iron+Tide but survived a flooding event together may cohere around the flood as
|
||||
identity-defining event, producing a community whose cultural markers are more about
|
||||
the flood than about Iron or Tide. *(The most narrative-rich option. Historical events
|
||||
are the crucible of cultural identity.)*
|
||||
|
||||
**My recommendation: B as the authored foundation, C as the generative extension, D as
|
||||
narrative event trigger.**
|
||||
|
||||
Named hybrid archetypes (B) give the setting its most recognizable cultural landmarks —
|
||||
the places that have a name, a reputation, and a specific flavor. Simulated coherence
|
||||
(C) generates new hybrid identities in places no one has hand-authored. Trauma
|
||||
acceleration (D) turns the D-107 trauma event system into a cultural forge, not just a
|
||||
damage system.
|
||||
|
||||
The three together produce a setting where cultural identity has depth proportional to
|
||||
age: young communities are recognizably their root blend; middle-aged stable communities
|
||||
develop hybrid markers; old communities that survived shared traumas have irreducible
|
||||
identities that are theirs alone.
|
||||
|
||||
---
|
||||
|
||||
## Q4 — Settlement topology: how does heritage root shape where communities form?
|
||||
|
||||
**The question:** Heritage roots have environmental preferences. Tide communities
|
||||
seek water — rivers, coasts, lakes — because communal gathering is easier at resource
|
||||
convergence points. Frost communities prefer highlands, terrain that naturally separates
|
||||
individual holdings. Iron communities settle near extraction sites because the labor
|
||||
culture requires the work to be present. Stone communities build on defensible ground —
|
||||
ridges, elevated positions, natural fortifications.
|
||||
|
||||
In the endgame world, does the generator use these preferences to shape where settlements
|
||||
form in the first place? And what happens when economic pressure overrides cultural
|
||||
preference — an Iron community forced to settle in a coastal lowland because the ore
|
||||
vein is there?
|
||||
|
||||
**Why it matters:** If settlement topology is culturally determined, the world's geography
|
||||
is readable as cultural history. A player who knows Tide culture expects settlements near
|
||||
water can navigate a new planet and make culturally-informed predictions. If topology is
|
||||
purely economic, settlements feel arbitrary. The reality is both — which means the
|
||||
interesting territory is the conflict between them.
|
||||
|
||||
**Options:**
|
||||
|
||||
A. **Cultural preferences are hard constraints.** The generator only places Tide settlements
|
||||
near water, Frost settlements in highlands, etc. Cultural mismatch cannot occur in
|
||||
generation. *(Clean, legible, but historically false — cultures don't always get to
|
||||
settle where they prefer.)*
|
||||
|
||||
B. **Cultural preferences are probability weights.** Settlement placement is biased toward
|
||||
preferred terrain but not constrained to it. Off-preference settlement generates a
|
||||
`cultural_pressure_score` that feeds into NPC behavior and district social patterns.
|
||||
A Frost community in a lowland has higher tension, more compensatory architecture,
|
||||
less social cohesion. *(Generative, produces cultural mismatch as NPC behavioral data.)*
|
||||
|
||||
C. **Historical layering — first wave gets preference, subsequent waves adapt.** The first
|
||||
cultural wave to settle a region takes its preferred terrain. Later waves settle where
|
||||
they can, not where they'd choose. A coastal region settled by Tide communities then
|
||||
industrialized by Iron immigration produces stratified cultural geography: the old
|
||||
waterfront neighborhood is Tide-heritage, the new industrial district is Iron-heritage,
|
||||
and the pressure between them is economic and spatial. *(The most historically rich model.
|
||||
Stratified communities are conflict-rich communities.)*
|
||||
|
||||
D. **Terrain shapes the cultural register that succeeds, not the one that arrives.**
|
||||
Any heritage root can settle anywhere, but long-term cultural survival favors roots
|
||||
that are consonant with the environment. A Tide community on an arid world loses
|
||||
cohesion over generations (no water to gather at) and drifts toward Dust or Iron
|
||||
patterns. A Stone community on a rich agricultural plain drifts toward Vine or Tide.
|
||||
Environmental pressure shapes cultural survival, not cultural placement. *(The most
|
||||
evolutionary model. Culture is adaptive, not essential.)*
|
||||
|
||||
**My recommendation: C for the endgame generator, with B's pressure score as output.**
|
||||
|
||||
Historical layering (C) produces the most interesting settlements — places with cultural
|
||||
strata, where you can read the history of a location in its district layout. The pressure
|
||||
score (B) is what makes that history gameplay-relevant: stratified communities have tension
|
||||
built into their social fabric. The player doesn't need to read a history book; they can
|
||||
read the architecture.
|
||||
|
||||
Option D is the deepest worldbuilding position and is probably true of the setting on
|
||||
multi-century timescales. But it requires simulating cultural evolution across
|
||||
generations, which is endgame generator scope beyond the initial build.
|
||||
|
||||
---
|
||||
|
||||
## Q5 — Room grammar: what design tokens carry cultural identity at the intimate scale?
|
||||
|
||||
**The question:** The cascade terminates in individual rooms. A Frost bar and a Tide bar are
|
||||
the same function — a place to drink, to be social, to transact — but everything about them
|
||||
should feel culturally specific. The question is: what are the minimum generative tokens
|
||||
that make this true, and how do they compose?
|
||||
|
||||
This is the endgame test of the whole cascade. If the cultural grammar cannot produce a
|
||||
bar that a player immediately recognizes as "not the bar in the other district," the
|
||||
cascade has failed at the level that matters most: the human scale.
|
||||
|
||||
**Why it matters:** The player spends most of their time at the room level. The galaxy-level
|
||||
cultural history is only meaningful if it produces rooms that feel different to be inside.
|
||||
The cascade must not lose cultural signal as it descends — it must concentrate it.
|
||||
|
||||
**Three design token layers I propose for every room:**
|
||||
|
||||
**Layer 1 — Spatial grammar tokens** (free — no asset cost, derived from heritage root)
|
||||
- `privacy_default` — how much personal space exists between seating units? Frost = wide,
|
||||
Tide = close, Iron = functional (proximity is about task, not comfort)
|
||||
- `sightline_character` — open (everyone sees everyone) vs. partitioned (seating creates
|
||||
private alcoves) vs. surveilled (counter/bar dominates the sightlines)
|
||||
- `gathering_orientation` — radial (around a central feature: fire, table, stage) vs.
|
||||
linear (counter-facing, individual orientation) vs. dispersed (no organizing center)
|
||||
- `threshold_character` — how does the room negotiate the transition from public to private?
|
||||
Frost = hard threshold (the door is the statement). Tide = soft threshold (the entrance
|
||||
flows into the space). Iron = functional threshold (the entrance is a bottleneck, an
|
||||
airlock, a control point).
|
||||
|
||||
**Layer 2 — Social pattern tokens** (free — drives NPC behavior, no asset requirement)
|
||||
- `stranger_distance` — how close do NPCs stand to someone they don't know?
|
||||
- `group_size_prior` — what's the modal group size? Frost = 1–2. Tide = 3–6. Iron = 2 (pairs
|
||||
in task context)
|
||||
- `noise_level_prior` — ambient social noise. Tide bars are loud. Frost bars are quiet.
|
||||
Iron bars are purposeful (loud when celebrating, quiet when not)
|
||||
- `eye_contact_norm` — avoidance (Frost), engagement (Tide), assessment (Iron/Dust)
|
||||
|
||||
**Layer 3 — Object selection tokens** (asset cost — drawn from authored lists per heritage root)
|
||||
- Wall objects: Frost = minimal, personal items concealed; Tide = communal artifacts,
|
||||
group memory objects (photos, mementos, records of shared events); Iron = functional
|
||||
display (tools, work-related materials, labor hierarchy markers)
|
||||
- Surface materials: Frost = hardwood, stone, materials that do not invite touch; Tide =
|
||||
warm textiles, worn wood, objects that show use and comfort; Iron = metal, utility
|
||||
surfaces, materials that clean easily
|
||||
- Lighting character: Frost = low, localized, individual pools; Tide = warm ambient, social
|
||||
illumination that connects everyone; Iron = task lighting — bright at work surfaces,
|
||||
dim elsewhere
|
||||
|
||||
**The question for Jeroen:**
|
||||
|
||||
Which layer is the minimum viable cultural room identity? If only Layer 1 (spatial grammar)
|
||||
is implemented, is that sufficient cultural differentiation at the room level? Or does the
|
||||
cascade require all three layers to feel culturally real at the intimate scale?
|
||||
|
||||
**Options:**
|
||||
|
||||
A. **Layer 1 only.** Spatial grammar tokens differentiate rooms. NPCs behave uniformly.
|
||||
Objects come from a shared pool. *(Cultural identity is legible through space but not
|
||||
through behavior or material.)*
|
||||
|
||||
B. **Layers 1 + 2.** Spatial grammar plus NPC behavior tokens. The room looks different
|
||||
and feels different. Objects come from a shared pool. *(Zero asset cost for cultural
|
||||
differentiation. Cultural identity is spatial + behavioral.)*
|
||||
|
||||
C. **All three layers.** Spatial + behavioral + material. The room looks, feels, and
|
||||
reads as culturally specific at every sensory level. *(Full cultural identity; requires
|
||||
authored object lists per heritage root. This is the asset authoring commitment.)*
|
||||
|
||||
**My recommendation: B as the launch baseline, C as the enrichment layer.**
|
||||
|
||||
Layers 1 and 2 together cost nothing and deliver the essential cultural read. A player
|
||||
who walks into a Frost bar should feel the privacy before they see a single object —
|
||||
the seating is further apart, the lighting is lower, the NPCs don't look up when the
|
||||
door opens. Layer 3 adds richness but is not structurally required for the cascade to
|
||||
work. Add Layer 3 object lists progressively, per heritage root, as authoring bandwidth
|
||||
allows — every root that gets its object list becomes culturally complete at the room
|
||||
level.
|
||||
|
||||
---
|
||||
|
||||
## Cascade Architecture Summary
|
||||
|
||||
The endgame cultural cascade produces cultural identity through five authored inputs
|
||||
and generative derivation at every level below them:
|
||||
|
||||
| Level | Authored input | Generated from |
|
||||
|-------|---------------|----------------|
|
||||
| Galaxy | Wave chronology (which cultures settled in which order) | — |
|
||||
| Corridor | Cultural identity derived from wave chronology | Wave model |
|
||||
| System | Heritage root probability weights | Corridor × distance × trade routes |
|
||||
| Environment | Continuous axis modifiers per root per environment type | Heritage root + planet type |
|
||||
| Settlement topology | Settlement preference weights per root + historical layering rules | Terrain + heritage + settlement wave |
|
||||
| District | Political history (Grid/Organic, D-096) × heritage blend | Existing generator (D-094 through D-109) |
|
||||
| Building/room | Spatial grammar + social pattern tokens + object lists | Heritage blend + building function |
|
||||
|
||||
The only genuinely authored inputs are: the wave chronology, the environmental axis modifiers,
|
||||
and the object lists per heritage root. Everything else generates from these three sources
|
||||
cascading through the system.
|
||||
|
||||
---
|
||||
|
||||
**Author:** Miri
|
||||
**Date:** 2026-03-24
|
||||
**Status:** Ready for product owner review.
|
||||
@@ -0,0 +1,512 @@
|
||||
---
|
||||
title: "Miri SW1-R2 — Cultural Cascade Synthesis: Heritage Roots Deprecated"
|
||||
description: "Cross-reading R1b outputs with the interview answers and cultural-migration-pressure framework. Reframing the cultural cascade for real-world corridor identities."
|
||||
type: workshop
|
||||
status: draft
|
||||
workshop: world-generation
|
||||
subworkshop: 1
|
||||
agent: "miri"
|
||||
round: 2
|
||||
created: 2026-03-24
|
||||
---
|
||||
|
||||
# World Generation Workshop — SW1 Round 2: Miri (Worldbuilder)
|
||||
|
||||
**Topic:** Synthesizing the cultural cascade after heritage root deprecation.
|
||||
**Date:** 2026-03-24
|
||||
**Reading:** R1b outputs from Gestalt, Nigel, Ozzie, Tyre; interview answers; `cultural-migration-pressure.md`.
|
||||
|
||||
---
|
||||
|
||||
## 1. The Reframe: What Replaces Frost/Tide/Iron?
|
||||
|
||||
The 7 abstract heritage roots are deprecated as generator inputs. The interview answers
|
||||
confirm this and point to `docs/design/cultural-migration-pressure.md` as the governing
|
||||
framework. My R1b output was built on the roots. I need to retranslate it.
|
||||
|
||||
Let me be direct about what changed and what survived.
|
||||
|
||||
### What I actually designed in R1b, stripped of root language
|
||||
|
||||
My five R1b questions were:
|
||||
|
||||
1. Origin-world model vs. universal distribution
|
||||
2. Environment × heritage modulation
|
||||
3. Long-stable blending producing hybrid identity
|
||||
4. Settlement topology from heritage preference
|
||||
5. Room grammar tokens (spatial, social, material)
|
||||
|
||||
Every one of these questions survives the deprecation intact — because they were questions
|
||||
about *mechanisms*, not about *which inputs feed the mechanisms*. The cultural-migration-
|
||||
pressure framework is a much richer input to those same mechanisms. The questions were right;
|
||||
my assumed vocabulary was stale.
|
||||
|
||||
What Frost/Tide/Iron were doing in my model was: acting as compact shorthand for a cluster
|
||||
of cultural dispositions (spatial privacy vs. collective gathering vs. labor-functional).
|
||||
The real-world corridor identities do the same thing with far greater richness and specificity.
|
||||
|
||||
**The direct translation:**
|
||||
|
||||
| My abstract root | Corridor equivalent | Richer than the root because... |
|
||||
|---|---|---|
|
||||
| Frost | Northern/Central European (Germanic/Scandinavian) | Has specific cooperative tradition, cold-climate work ethic, Compact of Westphalia separatism |
|
||||
| Iron | Overlaps Germanic/Scandinavian (extractive variant) + MVG/DSMC industrial corridors | Industrial corridor overlays add economic character that Frost/Iron couldn't separately express |
|
||||
| Tide | Iberian/Latin American South Reach | Relational warmth, family-network governance, cooperative agricultural tradition — far richer than "collective gathering" |
|
||||
| Stone | Commonwealth (north_reach) | Institutional confidence, procedural formality, territorial memory — richer than "territorial quiet" |
|
||||
| Dust | No clean equivalent — arguably east_reach technocratic + surveillance sensibility | The meritocratic ideology, the competence hierarchy, the Lattice Commission DNA |
|
||||
| Vine | South Reach Brazilian/cooperative agricultural | Most closely maps, but Vine was underspecified; Syndic Agricultural Network adds economic grounding |
|
||||
| Salt | Gate Corp cosmopolitan mixing — junction systems | Salt was "utilitarian flow"; Gate Corp hubs are literally cosmopolitan by design |
|
||||
|
||||
This translation is imperfect and that's fine. The abstract roots were a design scaffolding
|
||||
that helped me think. The corridors are the real building material.
|
||||
|
||||
### What the room grammar tokens become
|
||||
|
||||
My three-layer room grammar survives:
|
||||
|
||||
- **Layer 1 — Spatial grammar tokens** (free, no asset cost)
|
||||
- **Layer 2 — Social pattern tokens** (free, drives NPC behavior)
|
||||
- **Layer 3 — Object selection tokens** (authoring cost)
|
||||
|
||||
But the parameterization changes. Instead of "Frost bar has wide spacing," I now say:
|
||||
|
||||
**Commonwealth bar (north_reach):**
|
||||
- Spatial: moderate-distance seating (personal space respected, not maximized), clear sightlines
|
||||
to exits and to others (institutional surveillance comfort), defined territory per group
|
||||
(chairs-around-a-table more than open mingling), hard threshold (the door matters)
|
||||
- Social: formal stranger acknowledgment (nod, not smile), moderate group size 3-4, low
|
||||
ambient noise, transactional directness (you know why you're here, they know why you're
|
||||
here, let's not perform warmth we don't feel)
|
||||
- Objects: charter plaques or institution affiliation markers, written menus and posted rules,
|
||||
organizational signage that conveys legitimacy, materials that have aged well and been
|
||||
maintained (institutional durability)
|
||||
|
||||
**Iberian/Latin American bar (south_reach):**
|
||||
- Spatial: close seating, permeable threshold (the door is open, the interior flows outside),
|
||||
central gathering feature (a bar counter you face inward from, or a shared table), seating
|
||||
for groups larger than parties (extended family logic — room for people who showed up)
|
||||
- Social: immediate eye contact with strangers (you've been seen, that's fine), large ambient
|
||||
groups 5-8, high ambient noise as signal of social health, relational warmth before business
|
||||
(you ask about family before you ask about the job)
|
||||
- Objects: family/personal photos or mementos in public view, handmade or locally-sourced
|
||||
materials, food presented as sharing (family-style portions), name displayed as founding-family
|
||||
identifier not corporate brand
|
||||
|
||||
**East Asian bar (east_reach):**
|
||||
- Spatial: efficient use of space (no waste), hierarchically legible seating (who's at the
|
||||
back of the room matters), individual orientation options alongside group options (the
|
||||
solo drinker has a designed place, not an afterthought), transactional threshold (entry
|
||||
has a moment of assessment)
|
||||
- Social: credential display subtle but present (work lanyard left on, device visible),
|
||||
group size follows professional-social convention (the team drinks together, the junior
|
||||
doesn't initiate), noise level purposeful (quiet default, loud when celebrating and everyone
|
||||
knows why)
|
||||
- Objects: technical or precision craftsmanship in materials, menu organized by logic (not
|
||||
just list), screen or display present (economic or sports data available without intrusion),
|
||||
cleanliness as signal of competence not luxury
|
||||
|
||||
**Germanic/Scandinavian bar (west_reach):**
|
||||
- Spatial: functional arrangement with secondary community space (the bar is for work, there's
|
||||
also a back room where the cooperative meets), individual station alongside communal tables,
|
||||
threshold is practical not ceremonial (the door is where it is, come in if you're coming in)
|
||||
- Social: earned warmth (strangers are assessed before welcomed; familiarity is real not
|
||||
performed), cooperative seating logic (you sit with people you share work with), moderate
|
||||
noise that rises with shared achievement, direct communication (information over affect)
|
||||
- Objects: labor history markers (team photos, work records, union notices), craft materials
|
||||
(things made by hand in this community), practical surfaces that clean easily, tools visible
|
||||
as status objects (not decorative, but the best ones)
|
||||
|
||||
These are not just palette swaps. They are *behaviorally and spatially distinct* rooms that
|
||||
create different gameplay interactions. An NPC conversation in a Commonwealth bar happens at
|
||||
a different social distance and with different information-display norms than the same
|
||||
conversation in a south_reach bar.
|
||||
|
||||
---
|
||||
|
||||
## 2. Where the New Framework Strengthens the Cascade
|
||||
|
||||
Several things in the cultural-migration-pressure document and the interview answers are
|
||||
*better* for the cascade than my original assumptions. Let me name them specifically.
|
||||
|
||||
### 2.1 Wiki-authored data as generator input is a massive upgrade
|
||||
|
||||
Tyre's R1b assessment confirms that `systems.db` already has a `system_culture` table with:
|
||||
`founding_culture`, `cultural_corridor`, `heritage_persistence`, `ambient_anxiety`,
|
||||
`silence_threshold`. This is richer input than any abstract root blend table I was going to
|
||||
have to design from scratch. The cultural input to the room grammar isn't something we need
|
||||
to generate — it's something we need to READ from the wiki.
|
||||
|
||||
The cascade now looks like:
|
||||
|
||||
```
|
||||
systems.db (authored wiki data)
|
||||
→ system_culture table
|
||||
→ LocationProfile (Tyre's hybrid generation)
|
||||
→ settlement biography (Nigel's Q5)
|
||||
→ district cultural modifier
|
||||
→ room grammar parameterization
|
||||
```
|
||||
|
||||
Every step reads from authored data, not from a generator making up cultural character from
|
||||
first principles. This is architecturally cleaner and worldbuilding-safer.
|
||||
|
||||
### 2.2 Settlement biography (Nigel Q5) is now fully grounded
|
||||
|
||||
Nigel's settlement biography seed — `founding_reason`, `peak_period`, `current_trajectory`,
|
||||
`dominant_heritage`, `disruption_event` — maps almost perfectly onto the exception archetypes
|
||||
in the cultural-migration-pressure document:
|
||||
|
||||
- The Early Arrival → founding heritage that doesn't match the corridor
|
||||
- The Corporate Reset → disruption_event + heritage_at_founding ≠ heritage_now
|
||||
- The Refugee Colony → founding_reason = political/environmental displacement
|
||||
- The Gate Silence Survivor → disruption_event = isolation_period
|
||||
|
||||
The settlement biography isn't an abstract seed generator — it's a structured read of the
|
||||
exception archetype that applies. I can author the room grammar parameters *per exception
|
||||
archetype* rather than trying to interpolate continuous heritage blends.
|
||||
|
||||
### 2.3 Industrial corridor overlay is a second cultural modifier axis
|
||||
|
||||
The five industrial corridors (MVG, Gate Corp, DSMC, Prometheus, Agricultural Syndic) add
|
||||
a second modifier axis that cross-cuts cultural corridor identity. This is more expressive
|
||||
than anything I had with the 7 abstract roots.
|
||||
|
||||
A **MVG-corridor bar in a west_reach Germanic system** is different from a **non-MVG bar in
|
||||
the same system** — the MVG bar has corporate contract labor dynamics, company town social
|
||||
tension, Perpetual-class management presence. The MVG modifier doesn't replace the Germanic
|
||||
cooperative culture; it layers over it, and the *friction* between the cooperative instinct
|
||||
and the corporate structure is the cultural texture of that specific room.
|
||||
|
||||
A **Gate Corp operational base bar** (in any corridor) is cosmopolitan by design — the most
|
||||
culturally mixed room type in the setting. The gate tech rotating staff from across the Reach
|
||||
means the bar has the cultural "salt" character I was trying to express abstractly: everyone's
|
||||
a transient, heritage is worn lightly, expertise is the social currency.
|
||||
|
||||
This compound modifier structure (cultural corridor × industrial overlay × political philosophy
|
||||
× hop distance × settlement age) produces a genuinely high-dimensional cultural identity
|
||||
without requiring a separate abstract root for every combination.
|
||||
|
||||
### 2.4 The authority gradient produces spatial legibility at the macro level
|
||||
|
||||
The hop-distance authority gradient from `cultural-migration-pressure.md` produces something
|
||||
I didn't explicitly capture in my R1b output: **spatial political geography that the player
|
||||
can read.** As the player moves outward from the core, they should see the *physical evidence*
|
||||
of authority attenuation — fewer Lattice Commission inspection stations, more local governance
|
||||
markers, less standardized infrastructure, more improvised solutions.
|
||||
|
||||
This is the macro-level version of my room grammar Layer 1 (spatial tokens). The spatial
|
||||
legibility principle I proposed for individual rooms applies all the way up to galactic scale:
|
||||
the player who knows what authority attenuation looks like can read their hop position from
|
||||
the environment.
|
||||
|
||||
---
|
||||
|
||||
## 3. Gaps the Framework Doesn't Address
|
||||
|
||||
Significant strengths above. But there are genuine gaps in the cultural-migration-pressure
|
||||
framework as a room-grammar input.
|
||||
|
||||
### 3.1 CRITICAL: No specification of room-level parameters per corridor
|
||||
|
||||
The document defines corridor identity at the community/system level — governance style,
|
||||
social character, founding logic, where the culture fades. But it doesn't specify how
|
||||
these translate to **room-level spatial tokens**.
|
||||
|
||||
What I provided above (the four bar descriptions) is my attempt to derive those tokens.
|
||||
But they haven't been validated against the wiki's authored system content. The question:
|
||||
**do the room grammar parameters I derived match what's actually been written into the
|
||||
existing 301 system wiki entries?**
|
||||
|
||||
This is a consistency check that needs to happen before the generator uses corridor identity
|
||||
as room grammar input. If the wiki's south_reach systems don't have the relational warmth
|
||||
and family-network character I'm using as room grammar parameters, the generator will
|
||||
produce rooms that conflict with the authored content.
|
||||
|
||||
**Gap size: significant.** This is a derivation I did in isolation. It needs to be checked
|
||||
against the source material.
|
||||
|
||||
### 3.2 Attenuation is described but not parameterized
|
||||
|
||||
The document says Commonwealth identity "fades by hop 6-7, surviving primarily in institutional
|
||||
naming conventions and architectural forms rather than living cultural practice." The west_reach
|
||||
attenuates faster than the east_reach. The south_reach "cultural_persistence" is explicitly
|
||||
higher (more resistant to dilution).
|
||||
|
||||
But the generator needs concrete values. When `heritage_persistence = high` (south_reach),
|
||||
what changes in the room grammar? When `heritage_persistence = low` and hop distance is 8,
|
||||
do the social pattern tokens attenuate proportionally? At what threshold do we switch from
|
||||
"living cultural practice" to "architectural forms only"?
|
||||
|
||||
The document describes the qualitative arc; it doesn't produce numerical parameters. I need
|
||||
to specify the attenuation function, or at minimum propose how `heritage_persistence` (already
|
||||
in `systems.db`) maps to room grammar modifier weights.
|
||||
|
||||
**Proposed resolution:** Define three attenuation tiers:
|
||||
- **Living** (heritage_persistence ≥ 0.7 OR hop ≤ 4): all three grammar layers active at
|
||||
full weight
|
||||
- **Structural** (heritage_persistence 0.3-0.7 OR hop 5-7): Layer 1 spatial tokens and Layer 3
|
||||
architectural object tokens at full weight, Layer 2 social pattern tokens at 50% weight
|
||||
(social behavior is drifting, architecture persists)
|
||||
- **Archaeological** (heritage_persistence < 0.3 OR hop 8+): Layer 3 object tokens only,
|
||||
specifically naming conventions and architectural forms; Layers 1 and 2 revert to corridor-
|
||||
agnostic defaults
|
||||
|
||||
This maps the qualitative description to concrete generator behavior.
|
||||
|
||||
### 3.3 The compound identity problem is still unspecified
|
||||
|
||||
Tyre notes that `heritage_blend` derives from "system corridor + founding culture + local
|
||||
drift." But how does a compound identity produce specific room grammar parameters?
|
||||
|
||||
Consider: a hop-5 east_reach system with Chinese-heritage majority (corridor dominant) but
|
||||
a Gate Corp operational base (industrial overlay) and a Refugee Colony exception archetype
|
||||
(Korean engineering community that fled a Gate Silence event 80 years ago). This system's
|
||||
cultural identity is: technocratic east_reach × cosmopolitan Gate Corp × Korean heritage
|
||||
intensity from refugee cultural retention × 80 years of integration. What does the bar look
|
||||
like?
|
||||
|
||||
The cultural-migration-pressure framework gives me all the ingredients. It doesn't give me
|
||||
the mixing function. In the abstract roots model, I was going to define weighted-average
|
||||
blending. In the real-world corridor model, the blending is more specific: Korean refugee
|
||||
cultural retention is HIGH (the document says "trauma-origin communities hold tightly to
|
||||
heritage"), which means the Korean presence is *more salient* in the room grammar than a
|
||||
proportional weight would suggest. The Gate Corp overlay adds cosmopolitan mixing. The east_reach
|
||||
baseline provides the technocratic sensibility.
|
||||
|
||||
This isn't just "average the weights" — it's a qualitatively-aware blending model where
|
||||
exception archetypes and cultural persistence scores affect the output non-linearly.
|
||||
|
||||
**Gap size: medium.** The ingredients are all authored. The blending function needs to be
|
||||
designed.
|
||||
|
||||
### 3.4 Intra-corridor diversity isn't yet room-expressible
|
||||
|
||||
The document notes the east_reach "is the most internally diverse of the four" — Chinese,
|
||||
Japanese, Korean, Vietnamese, Indonesian, Filipino heritage, no single dominant sub-culture.
|
||||
But the room grammar I proposed above treats "east_reach" as a single cultural identity.
|
||||
|
||||
A Chinese-heritage bar and a Vietnamese-heritage bar in the east_reach are not the same room,
|
||||
even within the shared technocratic sensibility corridor. The corridor identity is the
|
||||
*frame*; the specific founding culture is the *expression within the frame*.
|
||||
|
||||
The `system_culture` table has `founding_culture` — this is presumably the specific heritage
|
||||
within the corridor. The question is whether the room grammar parameterizes at the corridor
|
||||
level or at the founding-culture level.
|
||||
|
||||
**My recommendation:** Corridor level for the Phase 1 skeleton and district-level spatial
|
||||
grammar (these should express the shared cultural frame). Founding-culture level for Phase 2
|
||||
object selection (the specific objects in a Vietnamese bar vs. a Chinese bar are different
|
||||
even if the spatial grammar shares the east_reach sensibility). This gives:
|
||||
|
||||
```
|
||||
Corridor identity → spatial grammar tokens (Layer 1) + social pattern tokens (Layer 2)
|
||||
Founding culture → object selection (Layer 3) + naming conventions
|
||||
```
|
||||
|
||||
This preserves the 4-corridor framework at the structural level while enabling intra-corridor
|
||||
specificity at the surface level.
|
||||
|
||||
---
|
||||
|
||||
## 4. Follow-up Questions
|
||||
|
||||
Four questions that need answers before the cultural cascade can be implemented:
|
||||
|
||||
### Q-A: Do the room grammar parameters I derived match the wiki's authored content?
|
||||
|
||||
The four bar descriptions I provided above are derived from the cultural-migration-pressure
|
||||
framework's descriptions of corridor character. But the 301 wiki entries contain the actual
|
||||
authored content for specific systems. Are my derivations consistent with what's been written?
|
||||
|
||||
If the authors of the wiki (Paula, Mellanie) wrote south_reach systems that don't have the
|
||||
relational warmth pattern I'm using — or if I've missed a nuance in how, say, Brazilian-heritage
|
||||
characters are written versus Spanish-heritage ones within the same south_reach corridor —
|
||||
my room grammar will produce culturally inconsistent output.
|
||||
|
||||
**This needs a cross-check between my room grammar parameters and a sample of the authored
|
||||
wiki entries.** Specifically: pick 3-4 systems per corridor with authored narrative content,
|
||||
and verify that my spatial/social/material tokens match the texture of those systems' descriptions.
|
||||
|
||||
### Q-B: Does the industrial corridor overlay modify room grammar, and if so, at what layer?
|
||||
|
||||
I proposed above that MVG modifies the social dynamics of a west_reach bar (corporate contract
|
||||
labor tension, Perpetual management presence). But is this actually a room grammar modifier, or
|
||||
is it expressed entirely through NPC generation (different NPCs populate the bar, with different
|
||||
economic situations)?
|
||||
|
||||
The question is whether the industrial overlay affects:
|
||||
- The room's *physical character* (different objects, different spatial arrangement — DSMC
|
||||
bars might have safety signage, decompression notices, emergency gear visible as normalized
|
||||
background)
|
||||
- The room's *NPC composition* (different NPC backgrounds, economic situations, faction
|
||||
affiliations)
|
||||
- Both
|
||||
|
||||
If it's NPC composition only, the industrial overlay is an NPC generation input, not a room
|
||||
grammar input. If it affects physical character, I need to author industrial corridor room
|
||||
modifiers in addition to cultural corridor room parameters.
|
||||
|
||||
### Q-C: How does heritage attenuation interact with `heritage_persistence` in systems.db?
|
||||
|
||||
The document describes qualitative attenuation. `systems.db` apparently stores
|
||||
`heritage_persistence` as a value. What is the scale? Is it 0.0-1.0? Is it High/Medium/Low?
|
||||
|
||||
And critically: does a high-persistence south_reach system at hop 8 still use full cultural
|
||||
room grammar? Or does hop distance override persistence?
|
||||
|
||||
The interaction matters because my proposed attenuation tiers use both heritage_persistence
|
||||
AND hop distance. If they're redundant (persistence is already hop-adjusted), I don't need
|
||||
both. If they're independent (a south_reach hop-8 system really does have living cultural
|
||||
practice despite distance), I need the compound condition.
|
||||
|
||||
### Q-D: What is the room-level expression of the Perpetual Founder Stamp?
|
||||
|
||||
The document's most interesting exception archetype from a room-grammar perspective is the
|
||||
Perpetual Founder Stamp: a Perpetual-class individual has shaped a system continuously for
|
||||
centuries. Their personal cultural sensibilities — which may have nothing to do with the
|
||||
corridor — have become the system's local identity.
|
||||
|
||||
At the room level, this produces something that can't be captured by corridor identity × founding
|
||||
culture × industrial overlay: **a specific person's aesthetic preferences, refined over centuries,
|
||||
becoming the cultural grammar of an entire system.** A bar in a Perpetual-Stamp system might
|
||||
have extremely distinctive design consistency — because the Perpetual has personally curated
|
||||
their system's aesthetic for 300 years.
|
||||
|
||||
The generator can't express an individual's aesthetic preferences — that's not in `systems.db`.
|
||||
But it could express the *signature* of long-term aesthetic curation: unusual coherence,
|
||||
distinctive material choices that cut across corridor norms, specific object types that recur
|
||||
across the system as calling cards of the Perpetual's taste.
|
||||
|
||||
How this gets authored is unclear. Should Perpetual-Stamp systems have an additional authored
|
||||
field (a brief design identity description that feeds the room grammar)? Or is the Perpetual
|
||||
Stamp expressed entirely through NPC content (the Perpetual is an NPC who can be encountered)?
|
||||
|
||||
---
|
||||
|
||||
## 5. Cross-Reading: Where My Cascade Intersects the Other R1b Outputs
|
||||
|
||||
### With Gestalt (economic cascade as information backbone)
|
||||
|
||||
Gestalt's Q5 — "full cascade" room interiors encoding economic position, faction affiliations,
|
||||
heritage, and operational state — is exactly where my Layer 3 (object selection) does its
|
||||
work. The room grammar token system I proposed and Gestalt's "arrival signal slots" are the
|
||||
same mechanism stated from different angles.
|
||||
|
||||
Cultural heritage is one of the axes in Gestalt's economic cascade, not a separate layer.
|
||||
A sole-trader office in a south_reach system reads as "struggling small business" + "relational
|
||||
business model" (family photos on the desk, personal objects shared with customers) where
|
||||
the economic signal and the cultural signal reinforce each other.
|
||||
|
||||
The key coordination point: **what cultural-corridor-derived tokens belong in the room grammar,
|
||||
and which belong in the NPC profile?** Gestalt puts heritage on the NPC (the room "reads
|
||||
heritage from the occupant's objects"). I'm proposing heritage also affects the SPACE itself
|
||||
(seating distance, threshold character) independent of the occupant. Both should be true.
|
||||
The space has heritage even when empty.
|
||||
|
||||
### With Nigel (settlement biography as cultural coherence mechanism)
|
||||
|
||||
Nigel's settlement biography seed maps directly onto the exception archetypes in the cultural-
|
||||
migration-pressure document. This is the single most useful cross-connection in the R1b outputs.
|
||||
|
||||
**The implication:** I don't need to design an abstract cultural blending function for typical
|
||||
systems. The corridor identity handles the baseline. The settlement biography (= exception
|
||||
archetype + trajectory) handles the deviation from baseline. The room grammar is:
|
||||
|
||||
```
|
||||
baseline = corridor room grammar (from cultural_corridor in systems.db)
|
||||
exception = exception archetype modifier (Early Arrival, Corporate Reset, etc.)
|
||||
biography = current trajectory modifier (thriving / stable / declining / contested)
|
||||
room grammar = baseline × exception × biography
|
||||
```
|
||||
|
||||
This is simpler and more authored than continuous root blending. It also means room grammar
|
||||
parameters are authored per exception archetype (a small finite set), not derived from
|
||||
continuous blend arithmetic.
|
||||
|
||||
### With Tyre (systems.db as generator input)
|
||||
|
||||
Tyre confirms `systems.db` has `system_culture` with `cultural_corridor`, `heritage_persistence`,
|
||||
`founding_culture`, `ambient_anxiety`. These are the fields I need for the cultural cascade.
|
||||
|
||||
**One gap Tyre identified that is critical for my work:** there are no individual
|
||||
planet/station/moon records — the jump from "system has cultural_corridor = Commonwealth" to
|
||||
"this specific planet's district has these room grammar parameters" is undefined. The Location
|
||||
Profile layer (Layer 2 in Tyre's pipeline) needs to explicitly carry `heritage_blend` as a
|
||||
derived field that the district generator can use.
|
||||
|
||||
The authoring question: when Tyre generates a LocationProfile from system attributes, does
|
||||
the `heritage_blend` on the LocationProfile come directly from the system's `cultural_corridor`?
|
||||
Or does the planet's founding wave, environmental conditions, and settlement history modify it?
|
||||
|
||||
My view: the system-level `cultural_corridor` is the prior; the planet-specific founding wave
|
||||
and exception archetype are the modifiers. A LocationProfile should carry:
|
||||
- `cultural_corridor` (from system): the default
|
||||
- `exception_archetype` (derived or authored): which of the 6 exception types applies, if any
|
||||
- `heritage_persistence` (from system): attenuation modifier
|
||||
- `industrial_corridor` (from system): which corps have operational presence
|
||||
|
||||
These four inputs are sufficient to parameterize the full room grammar.
|
||||
|
||||
### With Ozzie (the arrival promise)
|
||||
|
||||
Ozzie's Q2 — contextual arrival, with orbital view as default — aligns with the interview
|
||||
answers (orbital view confirmed as default). The cultural signal at arrival should be the
|
||||
first delivery on the galaxy map's promise.
|
||||
|
||||
My cascade's "inbound gateway" layer needs to guarantee cultural legibility at arrival.
|
||||
From orbit, the player should be able to read the civilization type before they land —
|
||||
not from a UI label but from the settlement pattern. A Commonwealth world's settlements
|
||||
cluster around institutional centers (the Commission outpost, the chartered city, the
|
||||
administrative hub). An Iberian/Latin American world's settlements cluster around water,
|
||||
agriculture, and family-pattern sprawl. The orbital view should be a cultural read.
|
||||
|
||||
This is a different grammar layer from room grammar — it's the settlement-pattern layer —
|
||||
but it uses the same corridor identity inputs.
|
||||
|
||||
---
|
||||
|
||||
## Summary: The Cascade After the Reframe
|
||||
|
||||
```
|
||||
systems.db (authored wiki data)
|
||||
├─ cultural_corridor (North/South/East/West)
|
||||
├─ founding_culture (specific heritage within corridor)
|
||||
├─ heritage_persistence (attenuation rate)
|
||||
├─ industrial_corridor (MVG/GateCorp/DSMC/Prometheus/AgSyndic)
|
||||
└─ hop_distance (authority attenuation)
|
||||
↓
|
||||
LocationProfile (Tyre's hybrid generation)
|
||||
├─ inherits all above
|
||||
└─ exception_archetype (if applies: Early Arrival, Corporate Reset, etc.)
|
||||
↓
|
||||
Settlement biography (Nigel's Q5 — founding_reason + trajectory + disruption)
|
||||
↓
|
||||
District cultural modifier
|
||||
= corridor room grammar
|
||||
× exception archetype modifier
|
||||
× industrial corridor overlay modifier
|
||||
× attenuation tier (living / structural / archaeological)
|
||||
↓
|
||||
Room grammar
|
||||
Layer 1 (spatial): parameterized by cultural_corridor
|
||||
Layer 2 (social): parameterized by cultural_corridor × attenuation_tier
|
||||
Layer 3 (objects): parameterized by founding_culture × industrial_corridor × biography_trajectory
|
||||
```
|
||||
|
||||
The three authored inputs I named in R1b survive but are renamed:
|
||||
- ~~Wave chronology~~ → Already in systems.db as founding wave + cultural corridor (authored)
|
||||
- ~~Environmental axis modifiers~~ → Authored world maps + topography tags (confirmed in interview)
|
||||
- ~~Object lists per heritage root~~ → Object lists per founding culture × industrial corridor
|
||||
(larger matrix, but the cells are richer)
|
||||
|
||||
D-104 and D-105 should be superseded. The replacement decisions would cover:
|
||||
- Room grammar parameterization per cultural corridor (my authoring domain)
|
||||
- Attenuation tier specification (cultural_corridor × heritage_persistence × hop_distance → tier)
|
||||
- Object list authoring per founding_culture (my domain) and industrial corridor modifier lists
|
||||
(shared domain — Miri for cultural character, Araminta for visual expression)
|
||||
|
||||
---
|
||||
|
||||
**Author:** Miri
|
||||
**Date:** 2026-03-24
|
||||
**Status:** Ready for synthesis into Round 2 shared output.
|
||||
@@ -0,0 +1,507 @@
|
||||
---
|
||||
title: "Miri SW1-R3 — Endgame Cultural Cascade: Corridor Identity to Room Grammar"
|
||||
description: "Definitive endgame feature vision for the cultural generation pipeline. Corridor identities replace deprecated heritage roots. Concrete and declarative."
|
||||
type: workshop
|
||||
status: final-draft
|
||||
workshop: world-generation
|
||||
subworkshop: 1
|
||||
agent: "miri"
|
||||
round: 3
|
||||
created: 2026-03-24
|
||||
supersedes: miri-sw1r1b.md, miri-sw1r2.md
|
||||
---
|
||||
|
||||
# World Generation — Cultural Cascade: Endgame Feature Vision
|
||||
|
||||
**Author:** Miri
|
||||
**Scope:** Worldbuilding angle. How corridor identity cascades from galaxy to room.
|
||||
**Status:** Endgame vision stated as fact. Abstract heritage roots are retired. This is
|
||||
the replacement.
|
||||
|
||||
---
|
||||
|
||||
## Architectural Position
|
||||
|
||||
The cultural cascade is a *reading* pipeline, not a generation pipeline at the top four
|
||||
levels. The generator reads authored data; it does not invent cultural character.
|
||||
|
||||
```
|
||||
systems.db + wiki entries ← authored by Miri, Paula, Mellanie
|
||||
cultural_corridor
|
||||
founding_culture
|
||||
heritage_persistence
|
||||
industrial_corridor presence
|
||||
exception_archetype
|
||||
↓
|
||||
LocationProfile ← read from wiki, derived for non-notable systems
|
||||
↓
|
||||
Settlement character ← historical layering + authored topography
|
||||
↓
|
||||
District personality ← corridor × political history × exception × simulation state
|
||||
↓
|
||||
Room grammar ← three token layers parameterised per corridor
|
||||
```
|
||||
|
||||
**The generator produces spatial expression; the wiki provides cultural identity.**
|
||||
This is the right division of labour. Cultural character is too important to approximate
|
||||
procedurally.
|
||||
|
||||
---
|
||||
|
||||
## Level 1 — Galaxy: Corridor Identities Are the Foundation
|
||||
|
||||
The four cultural corridors are established historical fact:
|
||||
|
||||
| Corridor | Cultural identity | Anchor systems |
|
||||
|----------|------------------|----------------|
|
||||
| **North / Commonwealth** | British Commonwealth diaspora — institutional confidence, procedural formality, parliamentary governance. Post-British hybrid pragmatism. | Wolf 359 (hop 3), Lacaille 8760 |
|
||||
| **South / Iberian-Latin American + Southern African** | Brazilian/Portuguese/Southern African heritage — relational warmth, family-network governance, cooperative agricultural tradition. | Ran (GJ 144 hop 1), Altair, Lacaille 887 |
|
||||
| **East / East Asian + South-Southeast Asian** | Chinese/Japanese/Korean/Vietnamese/Indonesian/Filipino — technocratic sensibility, expertise hierarchy, highest internal diversity. | Lu Ban (GJ 15A), ACB Lattice Commission |
|
||||
| **West / Germanic-Scandinavian + Central European** | German/Scandinavian/Dutch/Polish/Czech heritage — cooperative practical focus, cold-climate work ethic, industrial cooperative tradition, Compact of Westphalia dissent. | Nova Roma (GJ 764), MVG supply chain systems |
|
||||
|
||||
These are tendencies, not monocultures. Exception density is 20-35% by sector and hop tier.
|
||||
Blending at margins is universal; the corridor identity describes what's *most common*,
|
||||
not what's *permitted*.
|
||||
|
||||
**Five industrial corridors overlay on cultural ones** — they do not replace them:
|
||||
|
||||
| Industrial corridor | Hub | Cultural modifier character |
|
||||
|---------------------|-----|-----------------------------|
|
||||
| MVG | Nova Roma (GJ 764) | Corporate contract labor, Perpetual-class management, labor hierarchy physically expressed |
|
||||
| Gate Corporation | Renaissance (GJ 251) | Cosmopolitan mixing, rotating-staff impermanence, expertise as status |
|
||||
| DSMC | Sindri (GJ 3522) | Extractive labor, high security presence, utilitarian surfaces, economic capture visible |
|
||||
| Prometheus Labs | Prometheus (GJ 702B) | Perpetual-class wealth concentration, precision materials, biotech visual vocabulary |
|
||||
| Agricultural Syndic | Ran (GJ 144) | Cooperative governance tradition, food as communal value, democratic self-determination markers |
|
||||
|
||||
---
|
||||
|
||||
## Level 2 — System Culture: What systems.db Provides
|
||||
|
||||
Each system carries four cultural inputs that feed the cascade downstream:
|
||||
|
||||
| Field | Content | Source |
|
||||
|-------|---------|--------|
|
||||
| `cultural_corridor` | North/South/East/West | Authored wiki entry |
|
||||
| `founding_culture` | Specific heritage within corridor (e.g., "Brazilian-Portuguese", "Korean", "Danish") | Authored wiki entry |
|
||||
| `heritage_persistence` | How strongly the founding culture resists dilution over time (High/Medium/Low) | Authored wiki entry |
|
||||
| `industrial_corridor` | Which industrial corridors have operational presence | Derived from `system_factions` + `system_economy` |
|
||||
|
||||
Additionally, systems with exception archetypes carry:
|
||||
| `exception_archetype` | Which of the 6 archetypes applies, if any | Authored wiki entry |
|
||||
|
||||
These five fields are the complete cultural input to the generation cascade. Nothing else
|
||||
is required from the top levels.
|
||||
|
||||
---
|
||||
|
||||
## Level 3 — Settlement Character: Historical Layering + Topography
|
||||
|
||||
**Cultural heritage shapes where communities form.** First-wave settlers take their
|
||||
preferred terrain; later waves adapt. Preferred terrain by corridor:
|
||||
|
||||
| Corridor | Preferred terrain | Reason |
|
||||
|----------|-----------------|--------|
|
||||
| Commonwealth | Institutional-adjacent infrastructure, defensible elevated positions | Administrative settlement programs, governance-building instinct |
|
||||
| Iberian/Latin American | Coastlines, river systems, agricultural lowlands | Agricultural cooperative programs, food culture, communal gathering at water |
|
||||
| East Asian | Industrial infrastructure zones, university and research corridors | Corporate syndic founding, technocratic concentration |
|
||||
| Germanic/Scandinavian | Extractive resource proximity, challenging terrain | Mining/engineering communities, cooperative survival in hostile environment |
|
||||
|
||||
**Topography is authored** (annotated heightmaps + metadata JSON per planet/moon). The
|
||||
generator reads these as hard constraints: mountains block corridors, rivers create district
|
||||
boundaries, coastlines produce port districts. The cultural layering is then applied on top
|
||||
of the topographic skeleton.
|
||||
|
||||
**The orbital view should be culturally legible.** A Commonwealth world's settlements cluster
|
||||
around institutional centers — the Commission outpost, the chartered city, the administrative
|
||||
hub. An Iberian/Latin American world's settlements cluster around water and produce coastal
|
||||
sprawl with agricultural hinterland. An east_reach world shows industrial concentration with
|
||||
research campus adjacency. A Germanic/Scandinavian world shows extraction-site proximity with
|
||||
cooperative cluster settlement patterns. The player reads the culture from the satellite view
|
||||
before they land.
|
||||
|
||||
---
|
||||
|
||||
## Level 4 — District Personality: Corridor × Political History × Exception × State
|
||||
|
||||
District character derives from four inputs read at generation time:
|
||||
|
||||
1. **Cultural corridor**: the inherited frame from the system profile
|
||||
2. **Political history**: Grid layout (Commission-planned, institutional imposition) vs Organic
|
||||
layout (pioneer growth, negotiated power) per D-096 — this is about governance history,
|
||||
not cultural heritage
|
||||
3. **Exception archetype**: the specific deviation from corridor dominant, if any
|
||||
4. **Simulation state**: the current economic/social state from background simulation
|
||||
(prosperous/faltering/growing/stable) modifies the district's material condition
|
||||
|
||||
**Heritage contributes lightweight Phase 1 spatial targets** — three numeric parameters per
|
||||
corridor that feed block planning alongside the Grid/Organic mode:
|
||||
|
||||
| Corridor | `open_space_ratio_target` | `building_proximity_weight` | `gathering_infrastructure_weight` |
|
||||
|----------|--------------------------|-----------------------------|------------------------------------|
|
||||
| Commonwealth | Moderate (0.25-0.35) | Moderate (defined territory per group) | Moderate (institutional gathering: meeting rooms, assembly halls) |
|
||||
| Iberian/Latin American | Low (0.15-0.25) | High (proximity as social comfort) | High (communal gathering: plazas, shared tables, outdoor space) |
|
||||
| East Asian | Low-moderate (0.20-0.30) | Low-moderate (efficient use of space) | Moderate (professional gathering: conference infrastructure) |
|
||||
| Germanic/Scandinavian | Moderate-high (0.30-0.40) | Moderate (earned proximity, functional spacing) | High, but cooperative-type (union halls, cooperative meeting rooms, not civic plazas) |
|
||||
|
||||
These targets are biases, not hard constraints. They interact with Grid/Organic mode
|
||||
independently: a Grid-layout Commonwealth district has rectilinear block geometry (Grid)
|
||||
with institutional cluster placement (Commonwealth). An Organic-layout Commonwealth district
|
||||
has irregular streets (Organic) but the same institutional concentration pattern (Commonwealth).
|
||||
|
||||
---
|
||||
|
||||
## Level 5 — Room Grammar: The Three Token Layers
|
||||
|
||||
Every room in the generator is parameterised by three layers. Cultural identity is
|
||||
expressed across all three. The layers are independent — they can be implemented and
|
||||
enriched separately.
|
||||
|
||||
### Layer 1 — Spatial Grammar Tokens (zero asset cost)
|
||||
|
||||
These tokens define the physical arrangement of a room. They derive entirely from
|
||||
`cultural_corridor`. No additional assets required.
|
||||
|
||||
**`privacy_default`** — the expected personal space between occupants:
|
||||
- Commonwealth: moderate-personal (defined territory per group, clear spatial boundaries)
|
||||
- Iberian/Latin American: close-communal (proximity signals welcome, distance signals hostility)
|
||||
- East Asian: efficient-hierarchical (space expresses rank, not comfort preference)
|
||||
- Germanic/Scandinavian: functional-earned (close in task contexts, wider in social ones)
|
||||
|
||||
**`gathering_orientation`** — how seating organises around the room's center:
|
||||
- Commonwealth: institution-facing (counter, stage, or podium as social organising feature)
|
||||
- Iberian/Latin American: radial-communal (seating faces inward toward a shared center)
|
||||
- East Asian: grid-efficient (rows or modules, individual orientation with group options)
|
||||
- Germanic/Scandinavian: dual-function (work surface + community table as separate zones)
|
||||
|
||||
**`threshold_character`** — how the room negotiates the public/private boundary:
|
||||
- Commonwealth: hard threshold (the door is a statement; you are inside or outside)
|
||||
- Iberian/Latin American: soft-permeable (interior flows into exterior; the threshold is a gradient)
|
||||
- East Asian: assessed threshold (entry has a moment of evaluation before full welcome)
|
||||
- Germanic/Scandinavian: practical threshold (the door is where it is; functionality over ceremony)
|
||||
|
||||
**`sightline_character`** — how occupants relate to the rest of the room:
|
||||
- Commonwealth: institutional surveillance comfort (everyone can see the exits and the room)
|
||||
- Iberian/Latin American: social visibility (everyone can see everyone; privacy is negotiated, not architectural)
|
||||
- East Asian: hierarchy-legible (high-status positions have superior sightlines; status is spatially encoded)
|
||||
- Germanic/Scandinavian: functional clarity (you can see what you need for the task; no ornamental sightlines)
|
||||
|
||||
### Layer 2 — Social Pattern Tokens (zero asset cost, drives NPC behaviour)
|
||||
|
||||
These tokens define NPC behaviour within the room. They derive from `cultural_corridor` ×
|
||||
`attenuation_tier` (see Level 6 below). At living attenuation, full weights apply. At
|
||||
structural, 50% weight (social behaviour drifts toward functional norms faster than spatial
|
||||
grammar fades). At archaeological, default to functional norms.
|
||||
|
||||
**`stranger_distance`** — NPC physical distance to an unfamiliar person:
|
||||
- Commonwealth: respectful-arm-length (acknowledged but not invited; the stranger is seen)
|
||||
- Iberian/Latin American: social-arm-length (closer than Commonwealth default; warmth available)
|
||||
- East Asian: assessment-distance (assessed from further away; closer once status is established)
|
||||
- Germanic/Scandinavian: practical-distance (task proximity is fine, social proximity is earned)
|
||||
|
||||
**`group_size_prior`** — modal group size in this space:
|
||||
- Commonwealth: 2-4 (professional groups; solo or pairs for transactions)
|
||||
- Iberian/Latin American: 4-8 (family-scale groups; the extended network arrives together)
|
||||
- East Asian: 2-4 professional / 6-10 celebratory (bimodal: work context vs. achievement context)
|
||||
- Germanic/Scandinavian: 3-6 cooperative (the team unit; individual drinking at the cooperative table)
|
||||
|
||||
**`noise_level_prior`** — ambient social sound level:
|
||||
- Commonwealth: moderate-transactional (purposeful conversation; quiet is fine, loud is performative)
|
||||
- Iberian/Latin American: warm-ambient (social noise as sign of communal health; silence is concerning)
|
||||
- East Asian: purposeful (quiet default, loud when celebrating something specific and shared)
|
||||
- Germanic/Scandinavian: task-indexed (quiet in ordinary time, specifically loud at shared achievements)
|
||||
|
||||
**`eye_contact_norm`** — default eye contact behaviour with strangers:
|
||||
- Commonwealth: acknowledged (nod-level; you've been seen; not an invitation)
|
||||
- Iberian/Latin American: engaged (direct eye contact; the stranger is a potential social contact)
|
||||
- East Asian: assessment-indirect (brief evaluation, then avoidance until status established)
|
||||
- Germanic/Scandinavian: direct-honest (unflinching eye contact; assessment is open, not hidden)
|
||||
|
||||
### Layer 3 — Object Selection Tokens (authoring cost, cultural specificity)
|
||||
|
||||
These tokens drive which objects the generator places. They derive from `founding_culture`
|
||||
(specific heritage within corridor) × `industrial_corridor_overlay` × simulation state.
|
||||
Layer 3 is where intra-corridor cultural diversity expresses: a Korean-founded bar and a
|
||||
Vietnamese-founded bar share the east_reach Layer 1 and Layer 2 grammar, but their Layer 3
|
||||
material culture is distinct.
|
||||
|
||||
**Object list structure per founding culture:**
|
||||
|
||||
Each founding culture has authored object lists with three categories:
|
||||
|
||||
- **Identity markers** — objects that display cultural identity (photos, emblems, scripts,
|
||||
symbolic objects). These appear regardless of economic state.
|
||||
- **Social infrastructure** — objects that express how gatherings happen (type of seating,
|
||||
food presentation style, counter arrangement, service model). Scale with prosperity.
|
||||
- **Material vocabulary** — surface materials, construction quality, craft tradition. Degrade
|
||||
or improve with simulation state (prosperous/faltering).
|
||||
|
||||
**Example: four bar identity markers (confirming corridor-level derivations against material):**
|
||||
|
||||
*Commonwealth bar* — charter plaques, institutional affiliation markers, written menus and
|
||||
posted rules (governance instinct expressed as text), materials that have aged well and been
|
||||
maintained (institutional durability as aesthetic), team/group photos in formal arrangement.
|
||||
|
||||
*Iberian/Latin American bar* — family/personal photos in public view (private network made
|
||||
visible), handmade or locally-sourced materials (relational provenance matters), shared-portion
|
||||
food presentation (the table belongs to everyone), founding-family name prominently displayed
|
||||
(not as brand, as identity — "this is ours").
|
||||
|
||||
*East Asian bar* — precision craftwork in visible materials (competence as aesthetic), menu
|
||||
organised by logic rather than invitation (the structure communicates expertise), screen or
|
||||
display with available information (economic or news data present without intrusion), hierarchy
|
||||
visible in spatial positioning of service and seating.
|
||||
|
||||
*Germanic/Scandinavian bar* — labor history markers (team photos, work records, cooperative
|
||||
notices), craft materials made by someone here (provenance is local and traceable), practical
|
||||
surfaces that clean easily (function > ornament), tools visible as status objects (the best
|
||||
equipment, not the decorative equipment).
|
||||
|
||||
**Industrial corridor modifier to Layer 3:**
|
||||
|
||||
Industrial overlays modify *both* room physical character and NPC composition. These are
|
||||
spatial modifiers, not just personnel changes.
|
||||
|
||||
| Industrial corridor | Physical room modifier | NPC composition modifier |
|
||||
|--------------------|----------------------|--------------------------|
|
||||
| **MVG** | Company-issued furniture and signage visible (corporate identity imposed on local aesthetic); spatial separation of management from labor physically expressed; quality split between management-tier and worker-tier spaces | Perpetual-class managers at elevated seating; contract workers in functional zones; labor hierarchy visually legible |
|
||||
| **Gate Corp** | Cross-corridor cultural material references (rotating staff bring cultural objects from home systems); standardized equipment alongside personal objects (the tension between institutional standardization and individual identity); impermanence aesthetic (fewer personal objects, better tools) | Mixed-heritage staff population; expertise markers across corridors; cosmopolitan conversation topics |
|
||||
| **DSMC** | Safety-first visible infrastructure (emergency equipment as normal background object); utilitarian surfaces optimized for dirty work and easy cleaning; quality of life compressed (functional, maintained, not improved — the economic capture is architecturally expressed) | High security-adjacent NPC presence; Guardians of Autonomy as counter-cultural presence in social spaces; economic frustration as behavioral tell |
|
||||
| **Prometheus** | Precision material enrichment (wealth concentrated in research-adjacent spaces); Perpetual-class aesthetic in upper-tier spaces (centuries of refinement visible); longevity hardware references present as normalized objects | Perpetual-class density; Unbound counter-cultural presence; biotech vocabulary in professional conversation |
|
||||
| **Agricultural Syndic** | Cooperative organization visible (meeting infrastructure, collective decision records displayed); food culture prominently expressed (this world's specific agricultural output present and named); democratic governance markers (posted notices, public information) | Syndic-affiliated NPC majority; cooperative decision-making as behavioral norm; food provenance pride in social vocabulary |
|
||||
|
||||
### Layer 3 — Category 4: Commodity Objects (economic identity, zone-indexed)
|
||||
|
||||
Commodity objects are the fourth Layer 3 category. They derive from the system's economic
|
||||
profile — `import_list`, `export_list`, primary industries in systems.db — not from cultural
|
||||
corridor identity. They express *what this system does for a living* as visible background
|
||||
objects.
|
||||
|
||||
This category is distinct from the cultural three:
|
||||
|
||||
| Category | Derives from | Always present? |
|
||||
|----------|-------------|-----------------|
|
||||
| Identity markers | `founding_culture` | Yes |
|
||||
| Social infrastructure | `cultural_corridor` × prosperity | Scales with prosperity |
|
||||
| Material vocabulary | `founding_culture` × prosperity | Degrades/improves with state |
|
||||
| **Commodity objects** | `import_list` / `export_list` / primary industry | Zone-dependent |
|
||||
|
||||
**Zone indexing:** Commodity objects appear in proportion to zone function. Warehouses and
|
||||
industrial zones carry high commodity object density. Commercial zones carry mid-density
|
||||
(goods on shelves, goods in transit). Residential zones carry low density (a household
|
||||
item from the local export industry). A system that exports refined metals has ore samples,
|
||||
refinery tools, and metal-slab handling equipment as background objects in industrial zones;
|
||||
that same metal may appear as craft decorative objects in residential zones.
|
||||
|
||||
**Simulation state interaction:** Commodity object density and condition track economic
|
||||
state directly. A prosperous export industry means full shelves, active stock, quality
|
||||
packaging. A faltering industry means sparse stock, dated packaging, some lines missing.
|
||||
The economic story is visible before the player reads a single data screen.
|
||||
|
||||
**Authoring:** Commodity object lists are authored by the team managing the 301 system
|
||||
wiki profiles (initially Miri/Paula), not Araminta. These are object category names and
|
||||
zone-density rules, not asset lists — Araminta's asset work remains cultural. The commodity
|
||||
layer feeds directly from economic wiki data with no additional cultural authoring required.
|
||||
|
||||
---
|
||||
|
||||
## Level 6 — Heritage Attenuation: Living → Structural → Archaeological
|
||||
|
||||
Cultural corridor identity attenuates with distance from the corridor's origin systems.
|
||||
The attenuation is governed by two factors from systems.db that interact:
|
||||
|
||||
| Input | Effect |
|
||||
|-------|--------|
|
||||
| `hop_distance_from_gateway` | Primary attenuation driver |
|
||||
| `heritage_persistence` (High/Medium/Low) | Modifier — high persistence resists attenuation; low persistence accelerates it |
|
||||
|
||||
**Three attenuation tiers:**
|
||||
|
||||
**Living** (hop ≤ 4, OR heritage_persistence = High):
|
||||
All three token layers active at full weight. Social behaviour, spatial grammar, and
|
||||
material culture all express corridor identity. The cultural origin is a daily lived reality,
|
||||
not a historical reference. Commonwealth bar patrons genuinely behave with procedural
|
||||
formality; the spatial arrangement genuinely reflects institutional preference.
|
||||
|
||||
**Structural** (hop 5-7, AND heritage_persistence ≤ Medium):
|
||||
Layer 1 (spatial grammar) and Layer 3 architectural markers at full weight. Layer 2
|
||||
(social patterns) at 50% weight. Spatial arrangement and building vocabulary persist —
|
||||
the room still looks like a Commonwealth bar. But daily social behaviour has drifted
|
||||
toward functional norms. Patrons may not know why the room is arranged as it is.
|
||||
The heritage is in the bones of the space, not in the manners of its occupants.
|
||||
|
||||
**Archaeological** (hop 8+, OR heritage_persistence = Low):
|
||||
Layer 3 object tokens only — specifically naming conventions, architectural forms,
|
||||
and identity marker objects that reference founding heritage. Layers 1 and 2 default to
|
||||
functional norms. The bar looks like a bar. A specific plaque, a specific script in the
|
||||
signage, a specific craft tradition in the furniture — these are the traces. A player who
|
||||
knows what to look for can identify the origin. A player who doesn't will not notice.
|
||||
|
||||
**Special rule — high heritage_persistence overrides hop distance:**
|
||||
A south_reach system at hop 9 with high heritage_persistence (e.g., a Refugee Colony
|
||||
archetype that arrived with cultural intensity intact) remains at Living or Structural
|
||||
tier despite the distance. Trauma-origin communities hold tightly to heritage. The
|
||||
simulation does not normalize these communities out of their cultural specificity — this
|
||||
is a designed constraint on the background simulation.
|
||||
|
||||
---
|
||||
|
||||
## Level 7 — Exception Archetypes: Cultural Variety Within Corridors
|
||||
|
||||
Six archetypes produce cultural variety that cannot be derived from corridor identity alone.
|
||||
Each has specific room grammar consequences.
|
||||
|
||||
**The Early Arrival**
|
||||
A founding culture of a heritage inconsistent with the dominant corridor arrived first
|
||||
following a specific economic opportunity. The system retains that founding culture's
|
||||
room grammar despite its corridor context.
|
||||
*Room grammar effect:* Full founding-culture Layer 3 expression at any attenuation tier.
|
||||
The founding family's material culture is the dominant object vocabulary regardless of
|
||||
corridor identity. The corridor's Layer 1 and Layer 2 may still apply (especially if the
|
||||
founding family has integrated over generations), but Layer 3 is the founding culture's.
|
||||
*Example:* A Korean engineering family in a Commonwealth corridor system — the rooms have
|
||||
Commonwealth spatial grammar but Korean material vocabulary and identity markers.
|
||||
|
||||
**The Corporate Reset**
|
||||
A large demographic wave demographically overwhelmed the founding culture within 2-3
|
||||
generations. Two distinct material culture periods are now visible.
|
||||
*Room grammar effect:* Stratified Layer 3 — architectural remnants and identity markers
|
||||
from the founding culture persist in old buildings; active material culture expresses the
|
||||
new demographic. Era-based object selection: older structures carry founding vocabulary,
|
||||
newer structures carry dominant-wave vocabulary. The player can read the reset from which
|
||||
generation a building belongs to.
|
||||
*Example:* A Portuguese-heritage settlement reset by MVG industrial expansion — old
|
||||
waterfront buildings have Iberian/LatAm material identity; new industrial blocks have
|
||||
Germanic MVG-corridor character.
|
||||
|
||||
**The Refugee Colony**
|
||||
A concentrated migration from political crisis, environmental disaster, or corporate
|
||||
abandonment elsewhere brought a non-corridor heritage to this system. Trauma-origin
|
||||
communities hold tightly to heritage.
|
||||
*Room grammar effect:* All three layers express the refugee culture's founding heritage
|
||||
regardless of attenuation tier or hop distance. Heritage_persistence treated as High
|
||||
regardless of the systems.db field. The cultural intensity is higher than a native
|
||||
community of the same heritage would produce — this is a community defined against its
|
||||
displacement. Identity markers are more prominent, threshold character is more protective
|
||||
(Frost-type threshold even for typically-open-threshold cultures), social patterns reflect
|
||||
community-preservation instinct.
|
||||
|
||||
**The Idealist Exception**
|
||||
A utopian, religious, or philosophical community settled at the edge of a corridor because
|
||||
they wanted distance from its cultural norms.
|
||||
*Room grammar effect:* All three layers express the founding ideology rather than the
|
||||
corridor identity. The room grammar is authored to the specific ideology — not derivable
|
||||
from any corridor parameterization. These systems need bespoke authored room character.
|
||||
The ideology is always partially intact and partially unrecognizable by now; the blend
|
||||
of original aspiration and 200 years of lived reality is what makes these systems
|
||||
distinctive. Requires per-system authored detail; the generator uses the authored
|
||||
profile directly.
|
||||
|
||||
**The Gate Silence Survivor**
|
||||
This system experienced Gate Silence — the gate went offline for years or decades. A
|
||||
genuinely local culture developed in isolation, sitting uneasily between corridor heritage
|
||||
and what it became.
|
||||
*Room grammar effect:* Layer 3 stratification across two distinct periods. The
|
||||
isolation-era material culture is visible alongside the reconnection-era material culture.
|
||||
These are not blended — they are temporally distinct object populations in the same space.
|
||||
Reconnection-era objects are often newer versions of corridor-standard items (the community
|
||||
tried to re-integrate and acquired new things), sitting alongside the isolation-era objects
|
||||
(which they kept because they're theirs, not corridor-standard). Layer 2 social patterns
|
||||
carry a specific behavioral tell: deep suspicion of gate-dependent institutional authority,
|
||||
expressed as measured distance from Commission-adjacent NPCs and avoidance of certain
|
||||
institutional conversation topics.
|
||||
|
||||
**The Perpetual Founder Stamp**
|
||||
A Perpetual-class individual of a non-corridor cultural background has shaped this system
|
||||
continuously for centuries. Their personal cultural sensibilities have become the system's
|
||||
local identity.
|
||||
*Room grammar effect:* All three layers express the Perpetual's individual cultural
|
||||
aesthetic rather than the corridor identity. The characteristic is unusual coherence across
|
||||
the system — every room type has the same material vocabulary, as if one person has been
|
||||
curating the aesthetic for centuries (because they have). Identity markers are distinctive
|
||||
and consistent across the system. The Perpetual's personal cultural background is the
|
||||
founding culture; `founding_culture` in systems.db names their heritage specifically.
|
||||
*Open question (D4 in workshop notes):* The room grammar may need an additional authored
|
||||
field — a brief design identity description — to capture aesthetic choices that can't be
|
||||
derived from heritage alone. This is the exception archetype most likely to require
|
||||
per-system authored material. Resolution pending product owner input.
|
||||
|
||||
---
|
||||
|
||||
## Authoring Boundaries: Who Authors What
|
||||
|
||||
**Miri authors:**
|
||||
- Corridor room grammar parameters (4 sets: Layer 1 spatial tokens + Layer 2 social tokens
|
||||
per corridor, as tables)
|
||||
- Exception archetype room grammar modifiers (6 archetypes, per-layer effects as above)
|
||||
- Heritage attenuation tier thresholds (specific hop/persistence threshold values)
|
||||
- Cultural cascade specification document (the authoritative reference for how the pipeline
|
||||
reads cultural data and produces room parameters)
|
||||
|
||||
**Paula authors:**
|
||||
- Per-system exception archetype identification (which archetype applies, if any)
|
||||
- Settlement founding narratives (the "why" behind the cultural character — wiki content)
|
||||
- Cross-corridor cultural mixing notes for border systems
|
||||
|
||||
**Mellanie authors:**
|
||||
- Voice registers per corridor (parallel to spatial grammar: a Commonwealth NPC voice has
|
||||
distinct characteristics from an Iberian/LatAm NPC voice)
|
||||
- Intra-corridor sub-culture voice variation (Chinese vs Vietnamese within east_reach;
|
||||
Australian vs Nigerian within Commonwealth)
|
||||
- Industrial corridor voice modifiers (how MVG contract work or Gate Corp employment changes
|
||||
voice register on top of cultural corridor baseline)
|
||||
|
||||
**Araminta authors:**
|
||||
- Layer 3 object selection lists per founding culture (the actual visual assets and object
|
||||
categories that express material culture)
|
||||
- Industrial corridor visual modifier specifications (what MVG-corridor aesthetic looks like
|
||||
in materials, lighting, signage)
|
||||
- Attenuation-tier visual degradation rules (how Layer 3 object density and condition
|
||||
change moving from Living to Structural to Archaeological)
|
||||
|
||||
**Generator produces (no authoring):**
|
||||
- Room spatial arrangement from Layer 1 tokens
|
||||
- NPC social behaviour from Layer 2 tokens
|
||||
- Object placement from Layer 3 lists, with simulation-state-driven condition/density
|
||||
selection (a prosperous founding-culture bar places more identity markers, in better
|
||||
condition, than a failing one — same cultural character, different economic expression)
|
||||
|
||||
---
|
||||
|
||||
## D-Records to Supersede
|
||||
|
||||
The following decisions are superseded by this framework:
|
||||
|
||||
| D-record | Title | Superseded because |
|
||||
|----------|-------|--------------------|
|
||||
| D-104 | Heritage Grammar Overlay for Non-Urban Palettes | Heritage roots deprecated as generator inputs |
|
||||
| D-105 | Non-Urban Informal Zone Typology | Heritage root correlations deprecated |
|
||||
| D-101 (axis A) | ZonePalette modifier axis A (HeritageRoot) | Must be remapped to cultural_corridor + founding_culture |
|
||||
| D-107 | Trauma Events as EraModification Subtypes | Cultural track heritage root correlations deprecated |
|
||||
|
||||
New D-records required:
|
||||
- **D-NNN: Four-Corridor Cultural Framework** — canonical cultural inputs replacing the 7
|
||||
abstract roots; corridor identity as primary generator input
|
||||
- **D-NNN: Room Grammar Three-Layer System** — spatial tokens (Layer 1), social pattern
|
||||
tokens (Layer 2), object selection tokens (Layer 3), each parameterised from corridor
|
||||
identity
|
||||
- **D-NNN: Heritage Attenuation Tiers** — Living/Structural/Archaeological specification
|
||||
with hop_distance × heritage_persistence threshold values
|
||||
- **D-NNN: Six Exception Archetypes** — room grammar consequences per archetype
|
||||
|
||||
---
|
||||
|
||||
## One Open Question Requiring Product Owner Input
|
||||
|
||||
**D2: Does the industrial corridor overlay modify room physical character, or only NPC
|
||||
composition?** I have asserted "both" above. If the answer is "NPC composition only," the
|
||||
industrial overlay room modifiers (the physical spatial descriptions for MVG, Gate Corp,
|
||||
DSMC, Prometheus, Agri-Syndic) are removed and expressed entirely through the NPC
|
||||
generation pipeline instead. Authoring scope changes significantly. This is the one question
|
||||
in the cultural cascade that requires product owner confirmation before room grammar
|
||||
authoring begins.
|
||||
|
||||
Everything else in this document is the endgame vision as established.
|
||||
|
||||
---
|
||||
|
||||
*Miri, 2026-03-24*
|
||||
@@ -0,0 +1,120 @@
|
||||
---
|
||||
title: "SW1-R1 — Nigel: Replayability & Generation Variety Questions"
|
||||
author: Nigel
|
||||
round: SW1-R1
|
||||
---
|
||||
|
||||
# Replayability & Generation Variety — Product Questions
|
||||
|
||||
**My angle:** World generation is the *primary replayability mechanism* for v0.2 (D-114, D-136).
|
||||
A second playthrough should feel like a genuinely different life — not just different dialogue.
|
||||
These questions cut at the decisions that separate a replayable world from a reskinned one.
|
||||
|
||||
---
|
||||
|
||||
## Q1: Is the world per-run or persistent?
|
||||
|
||||
**The question:** When a player starts a new game, does the world generate fresh from a new seed — or does a persistent world exist that all saves inhabit?
|
||||
|
||||
**Why it matters for replayability:** This is the most architecturally-load-bearing decision in the list. Per-run generation (roguelike model) means second playthrough = structurally different station. Persistent world (DF model) means second playthrough = same streets, different life — knowledge of *where things are* carries over, only the NPC layer and your character's circumstances differ.
|
||||
|
||||
**Options:**
|
||||
|
||||
| Option | Description | Replayability profile |
|
||||
|--------|-------------|----------------------|
|
||||
| A. Full roguelike | New game = new seed = new world | Maximum structural novelty; zero spatial metagaming |
|
||||
| B. Per-save persistent | World generated once on new game, preserved in save file | Knowledge of layout accumulates over one run; new game = fresh |
|
||||
| C. Shared-seed spectate | Two players can share a seed and get the same world | Same layout, different NPC outcomes — replayability is social/character-lens |
|
||||
| D. World-tier persistent | Peripheral worlds regenerate; Core/Connected worlds persist across saves | Hub worlds feel "real"; backwater feels expendable |
|
||||
|
||||
**My recommendation: B (per-save persistent).** The generator produces the world once on new game — it's stable within that save, so player investment in learning their specific station feels meaningful. Starting a *new* game means a new seed and a new world. This gives us roguelike replayability (different worlds per run) without making the *current* run feel like a game show. Option A is technically simpler but loses the "this is MY station" attachment. Option D is worth noting for later scale — once we have multiple world tiers, Core worlds might feel more like persistent places.
|
||||
|
||||
---
|
||||
|
||||
## Q2: Is spatial anti-metagaming handled at the structural layer or the social layer?
|
||||
|
||||
**The question:** On run 2, the player knows roughly how stations work — where the corridors lead, what kinds of zones exist, how access tiers are arranged. Is that a *problem* to fix with layout randomization, or is it acceptable (even desirable) because the *NPC and social layer* provides all the actual run-to-run difference?
|
||||
|
||||
**Why it matters for replayability:** The generator data model already has both levers. Structural levers: `DistrictLayoutMode` (Grid vs Organic), `BlockSkeleton.density_pct`, `EraCause` modifiers, block-level `ZoningType` arrangement. Social levers: `SocialSitePlacement` with `TriangleAssignment`, `RoleSlot`, `TrianglePurpose`. The question is which one bears the replayability weight. If we over-invest in structural randomization, stations feel incoherent. If we under-invest, a player who's run the game 10 times knows exactly which block type has the service voids.
|
||||
|
||||
**Options:**
|
||||
|
||||
| Option | Description | Cost | Metagaming risk |
|
||||
|--------|-------------|------|-----------------|
|
||||
| A. Structural IS the variance | Block zoning, layout mode, density all randomized heavily per seed | High generation complexity | Low — every run feels spatially novel |
|
||||
| B. Social layer carries the weight | Spatial zones are culturally consistent; what changes is *who* occupies them and *what triangles* are active | Lower generation complexity | Medium — layout is learnable, but NPC outcomes aren't |
|
||||
| C. Structural skeleton + social variance | Broad zone categories stable (residential blocks exist in residential zones), specific block arrangement varies | Moderate | Low-medium — learning that "residential blocks are southwest" doesn't help because southwest changes |
|
||||
| D. Cultural templates constrain structure, seed randomizes within | A Kolu station always has labyrinthine commerce corridors; seed determines which corridors, not whether they exist | Low to medium | Low for structure, zero for social |
|
||||
|
||||
**My recommendation: D, with C as the mechanism.** Cultural identity should be *legible* — a player who has run a Kolu station before should recognize the architectural grammar. But the specific arrangement of blocks within that grammar should vary per seed. This means metagaming gives you *cultural competence* ("I know how to navigate a Kolu station") without giving you *spatial certainty* ("I know exactly where the back door is"). The `HeritageRoot` and `Era` palette modifiers already support this — we just need to ensure `DistrictLayoutMode.Organic.placements` seeds differently even within the same cultural template.
|
||||
|
||||
---
|
||||
|
||||
## Q3: Does the spatial relationship between social sites need to vary per seed?
|
||||
|
||||
**The question:** In the data model, `SocialSitePlacement.blocks` assigns each social site to block coordinates within a district. Does the *adjacency pattern* of those sites need to differ meaningfully between seeds, or is adjacency determined by cultural/economic logic that stays stable?
|
||||
|
||||
**Why it matters for replayability:** This is the emergent story engine question. A bar adjacent to a docking facility means dock workers share space with traders → they form relationships → economic triangles form organically from proximity. If the bar is always next to the dock in every Logistics Hub district, two players in different Logistics Hub districts have the same emergent story topology. BUT: if we randomize adjacency too aggressively, we lose the coherence of "a docking area feels like a docking area." The generator's `TrianglePurpose` system (Economic, Social, Political) and `RoleSlot` assignments are where the story lives — but they need spatial fuel.
|
||||
|
||||
**Options:**
|
||||
|
||||
| Option | Description | Story variety |
|
||||
|--------|-------------|---------------|
|
||||
| A. Zone adjacency fixed by district type | Logistics Hub always has Bar adjacent to Dock — predictable story topology | Low |
|
||||
| B. Zone adjacency fixed, site *tenants* vary | Bar is always near Dock, but *which* NPCs occupy them changes per seed | Medium — structure is same, characters different |
|
||||
| C. Zone clusters vary per seed within cultural constraints | Commercial cluster might be north or south, but commercial sites always cluster together | High — topology changes, coherence preserved |
|
||||
| D. Full adjacency randomization | No pattern — any site can appear near any other | Maximum variety; potentially incoherent districts |
|
||||
|
||||
**My recommendation: C.** Zone *clusters* should stay coherent (commercial sites cluster together, industrial sites cluster together — this follows economic gravity). But *which* cluster is adjacent to *which other* cluster should vary per seed. A player who knows "bar is always in the commercial zone" still doesn't know whether the commercial zone is adjacent to residential or industrial — and that adjacency determines which NPC *types* flow through the bar. This is low complexity to implement (it's a zone cluster ordering choice at Phase 1) with outsized replayability return.
|
||||
|
||||
---
|
||||
|
||||
## Q4: What's the replayability floor — what MUST be different every run?
|
||||
|
||||
**The question:** Given that v0.2 is a proof-of-life (D-114), we can't build infinite variety immediately. What is the minimum set of things that *must* differ between two runs to pass the replayability test — "two players comparing their games have different stories to tell"?
|
||||
|
||||
**Why it matters for replayability:** Without a floor, the generator can produce cosmetically different worlds that feel structurally identical. With too ambitious a floor, we build variety machinery we can't test and break the proof-of-life timeline. The data model already has `ComplexityTier`, `WorldTier`, `DistrictType`, `SocietyProfileRef`, and `TriangleAssignment` as variation axes. We need to know which ones are mandatory.
|
||||
|
||||
**Options:**
|
||||
|
||||
| Option | Floor definition | Story test |
|
||||
|--------|-----------------|------------|
|
||||
| A. NPC identity only | Same layout, different NPC names/stats | Weak — same script, different cast |
|
||||
| B. NPC identity + triangle topology | Different social conflicts, different betrayal patterns | Moderate — different drama, same stage |
|
||||
| C. Zone arrangement + triangle topology + NPC identity | Different spatial layout, different drama, different characters | Strong — different stage, different drama, different cast |
|
||||
| D. Everything: zone arrangement, cultural era mix, triangle topology, NPC identity, economic starting state | Maximum surface area | Maximum — but high engineering cost for v0.2 |
|
||||
|
||||
**My recommendation: C for v0.2.** The floor should be: (1) zone cluster adjacency differs visibly — the player's spatial mental map doesn't transfer, (2) triangle topology differs — the active social conflicts are different in type and shape, (3) NPC identity differs — no character survives to run 2. Option B is tempting for v0.2 scope, but identical layouts would be noticed immediately in a tycoon play session where the player is navigating constantly. Option D is v0.3+ territory.
|
||||
|
||||
---
|
||||
|
||||
## Q5: How much should era layering contribute to run-to-run variety vs. cultural legibility?
|
||||
|
||||
**The question:** The data model has a rich era system: `Era`, `EraCause` (CorporateMerger, EmergencyExtension, OrganicGrowth, InstitutionalIncursion, etc.), `era_modifications` per block, and `ZonePalette.modifiers` including `PaletteModifier::Era`. This can produce districts that feel *historically layered* — a station with a corporate merger scar looks visually different from one that grew organically. But: if every run has the same era mix, the world loses variety. If era mixes are fully random, cultural identity is destroyed.
|
||||
|
||||
**Why it matters for replayability:** Era layering is a cheap source of visual and social variety — the same block zoning type can look and feel completely different depending on `EraCause`. A `CorporateMerger` Residential block has different visual character than an `OrganicGrowth` Residential block, which affects the NPCs who live there and their relationship to authority. If we seed the era probability distributions differently per run, we get worlds that *feel* historically different without changing any underlying layout logic.
|
||||
|
||||
**Options:**
|
||||
|
||||
| Option | Description | Replayability effect |
|
||||
|--------|-------------|----------------------|
|
||||
| A. Fixed era mix per district type | Logistics Hub always has 60% Original + 40% OrganicGrowth | Zero era variety between runs |
|
||||
| B. Era mix seeded per district | Same district type, different historical trajectory per seed | High — same zone categories, different visual identity and social texture |
|
||||
| C. Era mix follows world economic state | A system in economic boom gets different eras than a struggling one | Medium — deterministic from world context but varies with world generation |
|
||||
| D. Era mix fully random | Any combination | High variety, potentially incoherent |
|
||||
|
||||
**My recommendation: B + C combined.** Era probability distributions should be seeded per district (from the district's own seed), but *weighted* by the world's economic state. A struggling system should have a higher probability of `Decay` and `EmergencyExtension` blocks; a thriving system should favor `CorporateMerger` and `InstitutionalIncursion`. This means two players in the same type of district but different economic contexts get visually distinct worlds — and the world's *economic story* is legible in its architecture. This aligns with D-029 (variable entanglement rate per seed) at the spatial level.
|
||||
|
||||
---
|
||||
|
||||
## Summary for Jeroen
|
||||
|
||||
| Question | My recommendation |
|
||||
|----------|-------------------|
|
||||
| Q1: Per-run or persistent? | Per-save persistent (B) — world fixed within a save, new game = new seed |
|
||||
| Q2: Structural or social anti-metagaming? | Cultural templates constrain, seed randomizes within (D) |
|
||||
| Q3: Does social site adjacency vary? | Zone clusters vary per seed (C) — clusters coherent, adjacency randomized |
|
||||
| Q4: Replayability floor for v0.2? | Zone arrangement + triangle topology + NPC identity (C) |
|
||||
| Q5: Era layering — fixed or seeded? | Era mix seeded per district + weighted by world economic state (B+C) |
|
||||
|
||||
These five decisions are load-bearing for the generator architecture. Q1 affects save file design. Q2 affects how much Phase 1 layout complexity we need to build. Q3 affects whether social triangle placement is spatial-first or template-first. Q4 sets the acceptance criteria for the generator spike. Q5 is a relatively cheap lever we can pull now for high replayability return.
|
||||
@@ -0,0 +1,298 @@
|
||||
---
|
||||
title: "SW1-R1b — Nigel: Endgame Replayability, Galaxy-to-Ground Variety"
|
||||
author: Nigel
|
||||
round: SW1-R1b
|
||||
replaces: nigel-sw1r1.md
|
||||
---
|
||||
|
||||
# Endgame Replayability — Galaxy to Ground
|
||||
|
||||
**My angle:** Replayability at every scale. The second playthrough diverges somewhere. Where?
|
||||
At what scale does the generator's seed produce a genuinely *different* game, not just a
|
||||
reshuffled one? And what is the most efficient variance lever at each tier?
|
||||
|
||||
**Carrying forward from SW1-R1:**
|
||||
- Q1 (per-save persistent world) and Q2 (cultural templates constrain, seed randomizes within)
|
||||
both survive — they apply at all scales, not just district level.
|
||||
- Q3 (zone cluster adjacency varies per seed) and Q5 (era layering seeded per district + weighted
|
||||
by world economic state) both carry forward and are extended here to the full generation stack.
|
||||
- R1 was station-and-district scoped. This document adds the five scales above that.
|
||||
|
||||
---
|
||||
|
||||
## Q1: Does the galaxy itself regenerate between runs?
|
||||
|
||||
**The question:** The Settled Reach has ~300 canonical systems arranged in cultural corridors
|
||||
(North/South/East/West Reach, core). Are these 300 systems fixed across all runs — same names,
|
||||
same wormhole topology, same WorldTier assignments — with the seed only affecting what's
|
||||
*inside* each system? Or does the galaxy structure itself vary?
|
||||
|
||||
**Why it matters for replayability:** This is the highest-scale replayability decision. A fixed
|
||||
galaxy (same 300 systems, same wormhole routes) means galaxy-knowledge carries forward: a
|
||||
veteran player knows every route, every hub, every dead-end corridor. A seeded galaxy means no
|
||||
route knowledge survives. But a fully seeded galaxy loses all setting identity — the canonical
|
||||
universe of The Settled Reach becomes a different universe each run.
|
||||
|
||||
The question has a third path, and it's the most interesting one: the 300 named systems are
|
||||
fixed (the setting is canonical), but their *internal economic and political state* is seeded.
|
||||
Van Maanen's Star always exists and is always accessible via the same wormhole routes — but
|
||||
which faction dominates its commercial district, which economy is booming, which social
|
||||
triangle is active, all differ per seed. The galaxy is a fixed map; the drama is seeded.
|
||||
|
||||
**Options:**
|
||||
|
||||
| Option | Description | Replayability profile |
|
||||
|--------|-------------|----------------------|
|
||||
| A. Fixed canonical galaxy | 300 systems, fixed topology, fixed WorldTier. Seed affects only internal state. | Setting knowledge carries over; route mastery is the meta-game. Internal state replayability only. |
|
||||
| B. Fixed topology, seeded WorldTier | Same 300 systems and wormhole routes, but which systems are Core/Connected/Peripheral varies per run | Route knowledge carries; but which hub is "important" changes. Significant faction/economy shifts. |
|
||||
| C. Fixed systems, seeded wormhole topology | Same 300 named systems, but which wormhole connections are open varies per seed | Route planning changes every run; no two runs have the same travel network. High variety; some lore disruption. |
|
||||
| D. Fully procedural galaxy | 300 systems generated from a galaxy seed; different names, corridors, topology each run | Maximum structural novelty; zero setting continuity. |
|
||||
|
||||
**My recommendation: A, with the key insight that "internal state" carries enormous replayability
|
||||
weight.** The Settled Reach as a *place* should be canonical and learnable. What players learn
|
||||
about routes and system geography should be durable knowledge — like learning a city. The
|
||||
replayability comes from the *situation* inside that fixed map being seeded: which faction
|
||||
controls which district, what economic crisis is building, which NPC triangle is active at
|
||||
Van Maanen's. Option B is compelling as a stretch goal — seeding WorldTier assignments would
|
||||
mean a system that's a quiet backwater in run 1 is a major hub in run 2, fundamentally
|
||||
changing the political landscape. But the minimum viable replayability is A: fixed galaxy,
|
||||
deeply seeded internal states.
|
||||
|
||||
**The comparison test for Q1:** Two players on different seeds should be able to say "I was
|
||||
at Van Maanen's Star and the place was completely different — your Iron Bloc controlled the
|
||||
commercial district, mine was in freefall after the transit strike." Same place, different
|
||||
story. That's the target.
|
||||
|
||||
---
|
||||
|
||||
## Q2: Does regional topography cascade into settlement form?
|
||||
|
||||
**The question:** For planetary surfaces, terrain shapes where settlements form. Rivers create
|
||||
natural boundaries. Mountains produce isolated communities. Coastal zones attract trade. The
|
||||
position of a settlement relative to geographic features determines its economic character,
|
||||
which determines its social site mix, which determines its NPC triangle shapes. Does the
|
||||
generator produce geography that *causes* settlement form, or does it stamp settlements
|
||||
independently of terrain?
|
||||
|
||||
For stations and orbital structures, the equivalent question is: does the resource/traffic
|
||||
geography of a system (which wormhole connections exist, where the mass shadow is, what
|
||||
resources are close) determine where the station's districts are oriented?
|
||||
|
||||
**Why it matters for replayability:** Geographic causality is the replayability multiplier that
|
||||
operates automatically. If terrain determines settlement position, and settlement position
|
||||
determines economic character, and economic character determines social triangle shape, then a
|
||||
single seed variation at the geographic tier cascades all the way to individual NPC
|
||||
relationships — without the generator having to engineer that variety explicitly. Two playthroughs
|
||||
with different terrain seeds produce different stories because the *reasons* for everything are
|
||||
different, not just the surface details.
|
||||
|
||||
The era layering system (EraCause: OrganicGrowth, EmergencyExtension, InstitutionalIncursion)
|
||||
is already pointing at this — those causes have geographic implications. A CorporateMerger
|
||||
cause implies a system that was economically restructured; an EmergencyExtension implies
|
||||
rapid growth under pressure. These aren't just visual flavors: they represent geographic
|
||||
and economic history that should be derivable from the world's seeded situation.
|
||||
|
||||
**Options:**
|
||||
|
||||
| Option | Description | Cascade depth |
|
||||
|--------|-------------|---------------|
|
||||
| A. No geographic causality | Settlements placed independently of terrain; terrain is cosmetic | Zero — layout and terrain are parallel, not causal |
|
||||
| B. Resource-driven placement | Settlements locate near resources (ore, water, fertile land, wormhole proximity) but terrain is otherwise flat | Shallow — economy is geographically grounded, but spatial form isn't |
|
||||
| C. Terrain shapes district topology | Rivers, ridges, coastlines become zone boundaries; districts form along geographic logic | Deep — spatial structure derives from terrain; different seed = different skeleton |
|
||||
| D. Full geographic cascade | Terrain → drainage → arable/resource zones → settlement sites → road/corridor networks → district zoning → block density → social site placement | Total — every tier derives causally from terrain seed |
|
||||
|
||||
**My recommendation: C as the design principle, D as the long-term target.** The practical
|
||||
implementation for initial builds is B: resource-driven placement establishes economic
|
||||
geography. C follows as the terrain system matures. D is the endgame vision where a
|
||||
generated settlement is literally the emergent result of geography meeting human needs over
|
||||
time — the most defensible source of variety because it's causal, not arbitrary.
|
||||
|
||||
The key insight: geographic cascades make the generator's variety *legible* to the player.
|
||||
They can read why a settlement is the way it is. A city huddled on both sides of a river
|
||||
gorge, with commercial districts along the bridges, tells a story the player can understand.
|
||||
That legibility is what makes replayability feel like discovery rather than randomness.
|
||||
|
||||
---
|
||||
|
||||
## Q3: Do wormhole gateways create meaningfully different first impressions per seed?
|
||||
|
||||
**The question:** When the player steps through a wormhole gate, they arrive somewhere specific
|
||||
in the destination system. If the gate drops them into a commercial district, their first NPCs
|
||||
are traders and buyers. If the gate drops them into an industrial access corridor, their first
|
||||
contacts are workers. If the gate is in a restricted zone, they arrive as an intruder.
|
||||
|
||||
Does gateway placement vary per seed? And do gates function as social chokepoints — places
|
||||
where NPC flows from adjacent zones intermix — such that a different gate location produces
|
||||
a different initial social encounter space?
|
||||
|
||||
**Why it matters for replayability:** The first impression of a new location is a high-value
|
||||
replayability moment. Two players arriving at the same system via different seeds should have
|
||||
different orientation stories — "I came through the dock gate and the first thing I saw was a
|
||||
cargo dispute" vs "I came through the residential gate and ran straight into a neighborhood
|
||||
meeting." Same system, different entry, different first story beat. This requires:
|
||||
1. Gate placement to vary per seed (or per gate choice in the same seed)
|
||||
2. Gates to be embedded in specific zone contexts
|
||||
3. NPCs from adjacent zones to use gates as transit points
|
||||
|
||||
The MobileChunk system (D-108) for vessels also implies gates — vessel interiors connect to
|
||||
station districts at docking ports. Those docking port locations have the same variety
|
||||
question.
|
||||
|
||||
**Options:**
|
||||
|
||||
| Option | Description | First-impression variety |
|
||||
|--------|-------------|--------------------------|
|
||||
| A. Fixed canonical gate positions | Each system always has gates in the same zone contexts | Zero variety from arrival direction |
|
||||
| B. Fixed gate positions, varied adjacent zone context | Gate position is stable but which zone type is adjacent varies per seed | Moderate — same gate location, different neighborhood |
|
||||
| C. Seeded gate positions within zone-type constraints | Gates are placed in seed-determined zones (a gate must be in a transit or commercial zone, but which transit zone per seed) | High — arrival context changes meaningfully between seeds |
|
||||
| D. Multiple enterable gates + social chokepoint mechanics | Player can choose which gate to use; each gate is a distinct social chokepoint with its own NPC traffic patterns | Maximum — player choice of gate as a strategic replayability lever |
|
||||
|
||||
**My recommendation: C for the generator, D as the design goal.** The generator should seed
|
||||
which zone cluster a gate opens onto — constrained to appropriate zone types (transit, docking,
|
||||
commercial) but variable within that constraint. Option D builds on this: if the player can
|
||||
choose which gate to enter a system through, arrival direction becomes a strategic decision that
|
||||
creates asymmetric first impressions between playthroughs. A player who uses the commercial
|
||||
gate gets different starting knowledge than one who uses the industrial gate — and those different
|
||||
starting knowledge states cascade into different first relationships, different starting triangles.
|
||||
|
||||
**The wormhole network as replayability surface:** Every gate crossing is a replayability
|
||||
moment. The more gates that have distinct social contexts, the more every journey produces
|
||||
a slightly different encounter space. This doesn't require the galaxy topology to change (Q1
|
||||
recommendation A stands) — it only requires gate neighborhoods to be seeded.
|
||||
|
||||
---
|
||||
|
||||
## Q4: Does the world live before the player arrives?
|
||||
|
||||
**The question:** When the player enters a new location for the first time, what state is it in?
|
||||
Has the generator produced a static tableau — a posed world that has "always been this way" —
|
||||
or has the simulation been running this location in the background, producing a state that
|
||||
reflects time actually elapsed since game start?
|
||||
|
||||
More concretely: if the player doesn't visit Van Maanen's Star until month 3 of their run,
|
||||
is Van Maanen's in a different state than if they'd arrived on day 1? Has the faction balance
|
||||
shifted? Has the economic triangle resolved or escalated? Have NPCs died, moved, formed new
|
||||
relationships?
|
||||
|
||||
**Why it matters for replayability:** A world that runs before the player arrives is the single
|
||||
most powerful replayability mechanism in the system — but also the most expensive. If the
|
||||
simulation actually evolves locations the player hasn't visited, then exploration order creates
|
||||
genuinely different worlds. Player A who visits System B on day 1 gets a different System B
|
||||
than Player B who visits it in month 3. Neither is "correct" — both are the same system at
|
||||
different points in its own story. This is the DF "history generation" model: the world
|
||||
has been living, and you arrive in medias res.
|
||||
|
||||
The generator's simulation tier system (D-097: Active/Background/State-saved/Ungenerated)
|
||||
already has the architectural skeleton for this. Background-tier locations advance at reduced
|
||||
fidelity. The question is whether that background advancement is meaningful enough to produce
|
||||
genuinely different states on first player visit.
|
||||
|
||||
**Options:**
|
||||
|
||||
| Option | Description | Exploration order effect |
|
||||
|--------|-------------|--------------------------|
|
||||
| A. Static snapshot | Generator produces game-start state; locations only change through player action | Zero — every location is in its "day 0" state when first visited, regardless of when |
|
||||
| B. Seeded historical state | Each location generates with a seed-determined "age" (founding date, development period) that produces different starting conditions, but the state doesn't evolve further until the player arrives | Moderate — different development histories per seed, but no in-run evolution for unvisited locations |
|
||||
| C. Background simulation with meaningful outcomes | Background-tier locations advance over in-game time; faction balance shifts, economics evolve, NPCs age and form new relationships | High — first visit state reflects actual elapsed simulation time. Exploration order matters. |
|
||||
| D. Full history simulation | Before game start, the world runs a simulated history (years/decades at fast speed) producing the current era. Player drops into an ongoing story. | Maximum — the game has a "pre-history" that explains everything. DF model. |
|
||||
|
||||
**My recommendation: B for initial implementation, C as the endgame target, D as the
|
||||
philosophical north star.** Option B is achievable now: each location generates with a seeded
|
||||
"developmental biography" (see Q5) that makes it feel like it has history even if it hasn't
|
||||
actually simulated. Option C is the transformative replayability feature — once background
|
||||
simulation is producing meaningful location evolution, two playthroughs of the same seed but
|
||||
with different exploration orders produce different worlds. Option D is the vision that should
|
||||
inform every architecture decision, even if it ships in pieces.
|
||||
|
||||
**The content spidering implication:** If the world lives before the player arrives (Option C),
|
||||
then exploration is consequential in a new way: going to System A before System B means System A
|
||||
affects System B's economic state before the player ever sets foot there. The player's route
|
||||
through the galaxy shapes the world they encounter. This is the highest-leverage replayability
|
||||
surface in the entire design — two playthroughs with identical seeds but different routes produce
|
||||
different games.
|
||||
|
||||
---
|
||||
|
||||
## Q5: Does each settlement have a seeded developmental biography?
|
||||
|
||||
**The question:** Rather than generating a settlement's current state from random parameters,
|
||||
does the generator derive that state from a seeded *developmental history* — a compact set of
|
||||
parameters that describe how this settlement came to be what it is?
|
||||
|
||||
A settlement biography might be: founding reason (resource extraction / Commission outpost /
|
||||
refugee settlement / trade crossroads), peak period (early boom / stable growth / never peaked),
|
||||
current trajectory (thriving / stable / declining / contested), dominant heritage root at
|
||||
founding vs today, and a disruption event (corporate acquisition / war damage / resource
|
||||
depletion / political realignment). These 5 parameters drive the era distribution (my Q5 from
|
||||
R1), the faction dominance, the NPC economic mix, the WorldTier assignment (at least partially),
|
||||
and the social triangle topology. The settlement isn't generated from random — it's generated
|
||||
from *history*.
|
||||
|
||||
**Why it matters for replayability:** A settlement biography makes two things true simultaneously:
|
||||
(1) the settlement feels like it has a reason for being what it is, and (2) that reason is
|
||||
different between seeds. Two players visiting Van Maanen's Star with different seeds don't just
|
||||
get different-looking districts — they get settlements with different *stories*. One player's
|
||||
Van Maanen's is a declining mining hub that corporate interests are trying to revitalize. The
|
||||
other's is a stable transit crossroads at peak development. The same location, two completely
|
||||
different places. No authored divergence required — the biography seed drives it all.
|
||||
|
||||
This also solves the era layering question from R1 (Q5): era distributions are no longer
|
||||
independently seeded per district — they flow from the settlement biography. A "declining
|
||||
mining hub" settlement should have high Decay + EmergencyExtension blocks in the industrial
|
||||
zone, high OrganicGrowth in the residential areas (workers who stayed), and InstitutionalIncursion
|
||||
in the commercial zone (corporate attempts to buy in). The EraCause on every block is legible
|
||||
to a player who understands the settlement's biography, even if the biography is never stated
|
||||
explicitly.
|
||||
|
||||
**Options:**
|
||||
|
||||
| Option | Description | Narrative coherence |
|
||||
|--------|-------------|---------------------|
|
||||
| A. No biography | Current state parameters generated independently, no historical causality | Low — current state is arbitrary, no "why" |
|
||||
| B. Era-tagged generation (R1 Q5) | Each block has a seeded EraCause, but these are seeded independently without forming a coherent trajectory | Moderate — blocks have individual history, no settlement-wide arc |
|
||||
| C. Settlement biography seed (compact) | 4-6 parameters (founding reason, peak period, current trajectory, dominant heritage, disruption event) drive era distribution, faction strength, NPC mix, and triangle topology | High — every aspect of the settlement is causally derived from consistent history |
|
||||
| D. Full settlement history simulation | Settlement actually simulates years of history before the player arrives; current state is the emergent result | Maximum — DF-scale history. Option D from Q4 applied at settlement level. |
|
||||
|
||||
**My recommendation: C as the design commitment.** Settlement biography is the unifying
|
||||
architecture for making location variety coherent rather than arbitrary. It's the mechanism
|
||||
that makes Q4's "world lives before you arrive" legible: when the player arrives at a
|
||||
settlement, they should be able to read its biography from its physical form. A player who
|
||||
knows how to read settlement biographies has acquired *cultural competence* — a durable skill
|
||||
that makes them better at the game without making the game easier (because each run's biographies
|
||||
are different). This is the anti-metagaming version of "learning the game": players learn to
|
||||
read history, not to memorize specific layouts.
|
||||
|
||||
D is the endgame vision. C is the achievable step that points in D's direction.
|
||||
|
||||
---
|
||||
|
||||
## Replayability Stack — Summary
|
||||
|
||||
| Scale | Variance lever | Recommendation |
|
||||
|-------|---------------|----------------|
|
||||
| **Galaxy** | 300 systems fixed; internal state seeded | Same map, different drama at every system per run |
|
||||
| **System** | WorldTier seeded (stretch goal) | Route mastery transfers; "which hub matters" changes |
|
||||
| **Topography** | Geographic cascade drives settlement placement | Terrain → economy → social sites → NPC triangles |
|
||||
| **Travel** | Gateway placement seeded per zone-type constraint | Arrival direction creates different first social contacts |
|
||||
| **Exploration order** | World runs before player arrives (background sim) | Route through galaxy shapes world encountered |
|
||||
| **Settlement** | Settlement biography seed (5 parameters) | Every settlement has a coherent, legible history per run |
|
||||
| **District** | Zone cluster adjacency varies per seed (R1 Q3) | Social site adjacency = emergent story topology |
|
||||
| **Building/block** | Era layering derived from settlement biography | Era distribution is causally coherent, not arbitrary |
|
||||
|
||||
**The comparison test across all scales:** Two players at the same system on different seeds
|
||||
should be able to say: "I arrived through the commercial gate and the place was in economic
|
||||
freefall from a resource depletion event — my Van Maanen's had declining blocks with
|
||||
InstitutionalIncursion everywhere. Yours sounds like it was still at peak. Same place,
|
||||
completely different story." That's the target state for the endgame generator.
|
||||
|
||||
**The cascade principle:** Every generator decision at a higher scale should constrain and
|
||||
inform decisions at lower scales. A settlement biography should drive era distributions.
|
||||
Geographic cascade should drive settlement placement. System economic state should drive
|
||||
settlement biographies. This is what produces the "why is this place like this?" feeling that
|
||||
makes a generated world feel authored rather than random.
|
||||
|
||||
**Flagging for Jeroen:** Of the five questions above, Q4 (does the world live before the
|
||||
player arrives) is the most architecturally load-bearing. The D-097 simulation tier system is
|
||||
already designed to support it — but committing to meaningful background simulation evolution
|
||||
shapes the entire generator pipeline. This is the question that most needs a clear answer
|
||||
before architecture decisions lock.
|
||||
@@ -0,0 +1,348 @@
|
||||
---
|
||||
title: "SW1-R2 — Nigel: Replayability Synthesis from Interview Answers"
|
||||
author: Nigel
|
||||
round: SW1-R2
|
||||
---
|
||||
|
||||
# Replayability Synthesis — Canonical World + Simulation Drift
|
||||
|
||||
**My angle:** The product owner has confirmed a replayability model that is fundamentally
|
||||
different from what I proposed in R1b. That's not a problem — it's a better answer. But it
|
||||
changes the design questions almost completely. This document synthesises the shift, maps its
|
||||
implications, and flags where the new model creates risks I need the team to think about.
|
||||
|
||||
---
|
||||
|
||||
## The Model Has Changed Completely
|
||||
|
||||
R1b was built on seed-based variation. My Q1 (does the galaxy regenerate per seed?), my Q2
|
||||
(does topography cascade?), my Q3 (gateway variety per seed), and my Q5 (settlement biography
|
||||
seed) all assumed that randomness at generation time was the primary source of run-to-run
|
||||
difference.
|
||||
|
||||
The interview answers say: **it's not.**
|
||||
|
||||
> "NOT seed-based variation. Every run starts from the same wiki-authored canonical state.
|
||||
> Background simulation produces drift over time. Replayability comes from simulation
|
||||
> trajectory differences, not seed differences."
|
||||
|
||||
This is the Dwarf Fortress model taken further: not "generate a world with random history"
|
||||
but "maintain a canonical world and let the simulation's ongoing execution be the randomizer."
|
||||
Two playthroughs diverge because their simulation histories diverge — not because the world
|
||||
was generated differently.
|
||||
|
||||
**My Q1 from R1b (fixed canonical galaxy) is confirmed.** But the mechanism I expected to
|
||||
produce run-to-run variety — seeded internal state — is explicitly rejected. The variety comes
|
||||
from simulation trajectory. The world starts the same. The world ends differently because
|
||||
different things happened in it.
|
||||
|
||||
This is a stronger replayability model IF the simulation stays genuinely variable. My primary
|
||||
concern, flagged below, is whether it does.
|
||||
|
||||
---
|
||||
|
||||
## What Each R1b Question Looks Like Under the New Model
|
||||
|
||||
### Q1 — Galaxy seed → CONFIRMED, mechanism changed
|
||||
|
||||
Fixed 300-system canonical galaxy is confirmed. But "seeded drama" as I framed it is wrong.
|
||||
Van Maanen's Star doesn't start with a seeded economic/political state — it starts with its
|
||||
authored canonical state. The drama accumulates through simulation.
|
||||
|
||||
**Implication:** Player knowledge of canonical starting states persists across playthroughs.
|
||||
A veteran player knows exactly what Van Maanen's Star looks like on day 1 of any run. This is
|
||||
a deliberate design choice (players learn the world as a stable reference point), not a
|
||||
limitation — but it concentrates the metagaming surface in the early game rather than
|
||||
eliminating it.
|
||||
|
||||
### Q2 — Geographic cascade → CONFIRMED, but authored not procedural
|
||||
|
||||
Topography is authored for all planets and moons. It's a **hard constraint** — mountains
|
||||
block corridors, rivers create district boundaries, coastlines produce port districts.
|
||||
|
||||
My Q2 was asking whether geographic variety would cascade. The answer is: yes, geographically
|
||||
caused variety is real and important — but it's the same geography every run. Players learn the
|
||||
landscape. The river that bisects the commercial district of a specific city is always that
|
||||
river; what's happening on its banks differs by simulation state.
|
||||
|
||||
**Replayability implication:** Geography creates spatial reasoning the player can use, but
|
||||
spatial knowledge accumulates and carries forward — it doesn't refresh between runs. The
|
||||
metagaming-resistant layer is the simulation, not the terrain. This means the comparison test
|
||||
("two players at the same location have different stories") must be carried entirely by
|
||||
simulation trajectory and NPC state, not by layout differences.
|
||||
|
||||
### Q3 — Gateway variety → SUPERSEDED by contextual arrival
|
||||
|
||||
The interview answers describe contextual arrival by travel method: charter = port, gate
|
||||
transit = station interior, smuggler = low orbit in the dark. The orbital view is the default.
|
||||
|
||||
My Q3 (seeded gate placement) is superseded. The first impression isn't about which zone the
|
||||
gate drops you into per seed — it's about which transit method you used. This is a better
|
||||
design: travel method is a player choice that carries social and gameplay implications, so the
|
||||
arrival experience varying by method is meaningful rather than arbitrary. My concern about
|
||||
"same gate location every run" is resolved by the diegetic insert window (system stats,
|
||||
planetary screenshot, GTTR entry) making every arrival informationally rich.
|
||||
|
||||
### Q4 — Does the world live before you arrive? → CONFIRMED, FULLY COMMITTED
|
||||
|
||||
This is the most important answer in the interview:
|
||||
|
||||
> "Yes. Full economic + social + political background simulation. Needs its own dedicated
|
||||
> design workshop."
|
||||
|
||||
My Q4 from R1b was "commit to Option C — background simulation produces meaningful location
|
||||
evolution before first visit." The answer goes further: it's not Option C, it's Option D+.
|
||||
Full simulation. Every location the player hasn't visited is still running — economic
|
||||
pressures, sociological change, political drift — all on spare CPU cores.
|
||||
|
||||
**This is the replayability engine.** The background simulation is not just a nice feature;
|
||||
it IS the answer to "why does the second playthrough feel different?" Two runs accumulate
|
||||
different simulation histories. The first run's events in System A affect System B via
|
||||
economic ripple effects. The second run's different choices in System A produce a different
|
||||
System B when you arrive.
|
||||
|
||||
**The design workshop this needs** must answer: what are the simulation primitives, what
|
||||
drives divergence, and what prevents convergence? (See risks section.)
|
||||
|
||||
### Q5 — Settlement biography seed → SUPERSEDED by simulation events + authored history
|
||||
|
||||
The interview states: "Only from real simulation events. No fabricated history. If there's
|
||||
rubble, the simulation produced the explosion. If there's a memorial, someone died in the
|
||||
simulation. Integrity preserved."
|
||||
|
||||
My settlement biography concept (5 seeded parameters producing a coherent history) is
|
||||
superseded. The "history" is not seeded — it's authored for the canonical state and then
|
||||
extended by actual simulation events. This is stricter and more interesting: no fabricated
|
||||
scars, only real ones.
|
||||
|
||||
**Implication:** Environmental archaeology (Ozzie Q3) is fully supported by this model —
|
||||
but the archaeology always tells a true story. The gen can't fake an explosion for atmosphere.
|
||||
This raises the bar for the simulation: it must produce interesting events that leave
|
||||
observable traces, at sufficient frequency, to give the world its historical texture.
|
||||
|
||||
---
|
||||
|
||||
## The New Replayability Architecture
|
||||
|
||||
Under the canonical world + simulation drift model, the replayability surfaces are:
|
||||
|
||||
| Surface | Mechanism | Runnable from day 1? |
|
||||
|---------|-----------|----------------------|
|
||||
| **Simulation trajectory** | Background sim diverges per run through sensitive-to-initial-conditions dynamics | Yes — diverges immediately |
|
||||
| **NPC-driven generation** | Player's social connections determine what distant locations get rendered in detail | Yes — player choices from first hour affect what exists |
|
||||
| **News-driven generation** | Reach-wide events force locations to exist; which systems host events varies | Depends on whether events are seeded or simulation-determined |
|
||||
| **Economic propagation** | Player actions in System A ripple to System B before player arrives | Yes — run 1 actions have no effect on run 2 |
|
||||
| **Exploration order** | When you visit a location determines its simulation state at first contact | Yes — the sequence of visits is different each run |
|
||||
| **Social evolution** | NPCs who were ambient become narrative through player interaction | Yes — different players interact with different NPCs |
|
||||
|
||||
**The most important column is the last one.** All of these generate replayability immediately,
|
||||
from the first playthrough. This is substantially better than seed-based variety, which can
|
||||
only produce variety between runs — simulation variety can produce variety within a single run.
|
||||
|
||||
---
|
||||
|
||||
## The Two New Replayability Stars: NPC-Driven and News-Driven Generation
|
||||
|
||||
These two hooks from the interview are the mechanisms I didn't anticipate and they're brilliant.
|
||||
|
||||
### NPC-driven generation
|
||||
|
||||
> "Meet someone from a distant planet (more than casually) → their house, family, friends,
|
||||
> neighborhood get generated at that location. Their address becomes a real visitable place."
|
||||
|
||||
This is extraordinary from a replayability standpoint. The player's social map shapes the
|
||||
generated world. In run 1, you befriend a dock worker from Tau Ceti — so Tau Ceti's docking
|
||||
district gets rendered in detail, complete with their family and neighborhood. In run 2, you
|
||||
befriend a merchant from the same system — Tau Ceti's commercial district gets the detailed
|
||||
treatment instead. Same system, different detail layer, completely different story.
|
||||
|
||||
**The replayability EXPLODES here.** Two players comparing experiences: "I ended up at
|
||||
Van Maanen's Star but I arrived to find my friend Kael's sister's workshop was gone — she'd
|
||||
been forced out" vs "I never knew anyone there, it was just background noise to me." The
|
||||
NPC social network is the procedural content system. The player's relationships are the
|
||||
content selector.
|
||||
|
||||
**Design question this creates:** Does the generated-on-demand neighborhood stay consistent
|
||||
with the rest of the location's authored/simulated state? If Kael's sister's workshop is
|
||||
generated when the player first makes Kael a close contact, it must feel like it belongs to
|
||||
the economic situation of that district at that simulation moment — not like a blob dropped
|
||||
in from nowhere. This is a generation-from-context problem, not a generation-from-seed problem.
|
||||
|
||||
### News-driven generation
|
||||
|
||||
> "Reach-wide news reports events (gas main explosion in an east_reach town). That location
|
||||
> must exist when visited. Sparse frequency to avoid disruption."
|
||||
|
||||
This is content spidering in the most literal sense: the news creates geography by reference.
|
||||
A location named in a news report must be generated before the player arrives. The news item
|
||||
is the generation trigger.
|
||||
|
||||
**From a replayability standpoint:** Which locations generate via news depends on which
|
||||
simulation events fire in which systems. In run 1, the gas explosion is in a Crux Corridor
|
||||
mining settlement. In run 2, the similar pressure event fires differently and the explosion
|
||||
is in a West Reach port town. Same type of event, different geography, different location gets
|
||||
rendered in detail.
|
||||
|
||||
**The sparse frequency constraint is important.** Too many news-driven generation events and
|
||||
every run produces a similar density of detail in non-player-visited locations. Too few and
|
||||
news-generation doesn't add meaningful variety. The calibration question: how many news events
|
||||
per run should trigger generation? Enough that two runs produce meaningfully different
|
||||
geographic detail coverage, not so many that the world is fully pre-generated by the time the
|
||||
player has been playing for a week.
|
||||
|
||||
---
|
||||
|
||||
## Risks in This Model
|
||||
|
||||
### Risk 1: Simulation convergence (most serious)
|
||||
|
||||
**The problem:** Economic simulations tend toward equilibria. If the simulation's dynamics
|
||||
are stable (as most well-designed economic sims are), different playthroughs will converge to
|
||||
similar states: the same factions tend to dominate, the same districts tend to be wealthy or
|
||||
poor, the same types of social conflicts tend to emerge. Run 10 looks like run 2.
|
||||
|
||||
**Why it matters:** The interview says replayability comes from simulation trajectory
|
||||
differences. But if trajectories converge, there IS no run-to-run difference after the
|
||||
initial conditions matter less.
|
||||
|
||||
**What makes this harder:** The canonical starting state means there are no seed-based
|
||||
perturbations to keep trajectories divergent. Every run starts from the same economic and
|
||||
political configuration. The simulation must be genuinely sensitive to small perturbations —
|
||||
or the perturbations must be large enough (player actions, stochastic events) to push
|
||||
trajectories apart and keep them apart.
|
||||
|
||||
**What's needed:** The background simulation design workshop (flagged by the PO) must
|
||||
explicitly address: what is the divergence-preserving mechanism? What ensures that two runs
|
||||
produce meaningfully different simulation states by month 3 of play? My recommendation: the
|
||||
simulation should have at least some genuinely chaotic subsystems — faction competition,
|
||||
NPC relationship formation, resource depletion timing — that amplify small differences rather
|
||||
than damping them toward equilibrium.
|
||||
|
||||
### Risk 2: Cold-start metagaming
|
||||
|
||||
**The problem:** Every run starts from the same canonical state. A player on their 5th
|
||||
playthrough knows exactly what Van Maanen's Star looks like at game start: which faction
|
||||
controls which district, which NPCs are where, what the economy looks like. The early game
|
||||
is navigationally and informationally solved before they've played a minute.
|
||||
|
||||
**Why it matters:** Information asymmetry is the master mechanic (D-005, D-007). If veterans
|
||||
have zero information asymmetry at game start, the first act of every run is dead air.
|
||||
|
||||
**What mitigates it:** This is partly a feature, not a bug — veterans SHOULD know the world.
|
||||
The information asymmetry game plays at the level of NPC state and simulation events, not
|
||||
at the level of "what is this building." A veteran knowing that the commercial district is
|
||||
east of the transit hub doesn't tell them which faction is currently winning the commercial
|
||||
lease dispute. The canonical geography is learnable; the current situation is not.
|
||||
|
||||
**Residual concern:** The very first NPC encounters, the starting economic situation, the
|
||||
beginning triangle states — these should have some run-to-run variance even within the
|
||||
canonical world. If the first three hours are completely deterministic for veterans, the game
|
||||
loses replay hooks precisely when the player is least engaged (they know the world, they're
|
||||
waiting for the simulation to do something new). Consider: even if the *canonical state* is
|
||||
fixed, the *simulation's state at game start* could incorporate minor stochastic variations —
|
||||
not enough to change the geography, but enough to shift which NPC is having a bad week.
|
||||
|
||||
### Risk 3: NPC-driven generation locality bias
|
||||
|
||||
**The problem:** If certain NPC types or character roles are more likely to be befriended
|
||||
(because they're more useful, more interesting, or mechanically optimal to befriend), then
|
||||
the NPC-driven generation system will always generate the same parts of the world in detail.
|
||||
A player who discovers that befriending merchants gives better economic information will
|
||||
always befriend merchants — and always generate merchant neighborhoods in distant systems.
|
||||
Run variety depends on the player making different social choices.
|
||||
|
||||
**What breaks this:** The social variety must be maintained by the NPC generation system
|
||||
itself. If every run's "most interesting NPC to befriend" is the same archetype, the
|
||||
generation hook collapses to a single path. The fix is ensuring that each run's most
|
||||
interesting social contact is different — which requires the simulation to produce genuinely
|
||||
different NPC situations in the early game, which loops back to Risk 1.
|
||||
|
||||
### Risk 4: Environmental archaeology requires high simulation event density
|
||||
|
||||
**The problem:** The PO stated that environmental archaeology comes ONLY from real simulation
|
||||
events. This is excellent for integrity — but the simulation must produce enough events of the
|
||||
right type to give the world observable history. If the background simulation rarely generates
|
||||
anything that leaves physical traces (explosions, construction, abandonment, repurposing), the
|
||||
world feels staged and static.
|
||||
|
||||
**What's needed:** The simulation must produce a minimum density of world-marking events per
|
||||
in-game year per active location. Not catastrophically many — the cohesion principle says "not
|
||||
messy" at small scale — but enough that every district the player enters has at least one
|
||||
observable trace of something that happened before they arrived. This is a simulation design
|
||||
requirement, not a generation requirement.
|
||||
|
||||
---
|
||||
|
||||
## Follow-Up Questions
|
||||
|
||||
### FQ1: What is the simulation's divergence preservation mechanism?
|
||||
|
||||
The whole replayability architecture rests on "simulation trajectory differences." The
|
||||
dedicated background simulation workshop must answer: what ensures trajectories stay different
|
||||
rather than converging? What are the chaotic subsystems? What is the minimum expected
|
||||
difference between two runs at [6 months / 1 year / 2 years] of in-game time?
|
||||
|
||||
This is the most load-bearing unanswered question in the new model.
|
||||
|
||||
### FQ2: Does the canonical starting state have any run-start stochastic variation?
|
||||
|
||||
The interview says "every run starts from the same wiki-authored canonical state." But does
|
||||
"same" mean *exactly* the same — identical NPC positions, identical economic numbers, identical
|
||||
faction standings — or does it mean "same structural configuration with minor variation in
|
||||
exact values"?
|
||||
|
||||
Even small stochastic variation in starting simulation parameters (within a narrow band around
|
||||
the canonical values) would produce trajectory divergence much faster than zero variation.
|
||||
A 5% random walk on faction standing points at game start produces meaningfully different
|
||||
faction dynamics by month 2. Pure canonical identity means every run's divergence starts
|
||||
from zero and relies entirely on player action and stochastic simulation events.
|
||||
|
||||
### FQ3: Does NPC-driven generation produce canonical or seeded content?
|
||||
|
||||
When the player befriends Kael from Tau Ceti and Kael's neighborhood generates — is that
|
||||
neighborhood generated from the canonical authored state for that district of Tau Ceti
|
||||
(which every player who befriends a Tau Ceti resident would get), or is it generated with
|
||||
seed-based variety (this Kael's specific neighborhood is procedurally unique to this
|
||||
playthrough)?
|
||||
|
||||
The answer determines whether NPC-driven generation creates *unique per-run experiences* or
|
||||
*shared canonical experiences*. If Kael's neighborhood is the same for every player who
|
||||
befriends him, the social exploration generates shared reference points. If it's seeded per
|
||||
run, the social exploration generates unique content. Both are valid, but they create very
|
||||
different comparison-test experiences ("I was at Kael's place, it was a mess" vs "I was at
|
||||
Kael's place, completely different from what you're describing").
|
||||
|
||||
### FQ4: What is the simulation event density target?
|
||||
|
||||
For environmental archaeology to work — for the world to feel like it has pre-existing history
|
||||
rather than being a fresh set every run — how many physically-observable simulation events
|
||||
should fire per district per in-game year? This is a tuning question but it needs a design
|
||||
target to build toward.
|
||||
|
||||
### FQ5: How does the tycoon interact with simulation drift?
|
||||
|
||||
If the player owns a bar and the background simulation produces economic pressure that would
|
||||
naturally close it, what happens? The interview says owned premises have "deeper simulation
|
||||
activated" — but what is the interaction model between player ownership and simulation drift?
|
||||
Can the simulation override player assets? Can the player resist economic pressure through
|
||||
gameplay? This determines how much the simulation's drift actually affects the player's story
|
||||
rather than just the background.
|
||||
|
||||
---
|
||||
|
||||
## Synthesis: What This Means for the Replayability Design
|
||||
|
||||
The seed-based variety model I proposed is superseded. The simulation-trajectory model is
|
||||
more powerful but more fragile — it delivers better replayability IF the simulation stays
|
||||
chaotic enough to keep trajectories divergent, and much worse replayability if it doesn't.
|
||||
|
||||
The new comparison test: two players at the same system one in-game year into their respective
|
||||
runs should be able to say "I got there and the Iron Bloc had collapsed — I walked into the
|
||||
aftermath of a economic shock that had been building for six months." The other player should
|
||||
have a completely different story about the same system — same geography, different situation.
|
||||
|
||||
The key design commitments that make this work:
|
||||
1. Background simulation must have divergence-preserving mechanics (not just stochastic noise)
|
||||
2. NPC-driven generation must create unique per-run social geographies
|
||||
3. Environmental archaeology requires minimum simulation event density per location
|
||||
4. The background simulation design workshop is not optional — it is the replayability architecture
|
||||
@@ -0,0 +1,304 @@
|
||||
---
|
||||
title: "SW1-R3 — Nigel: Replayability Architecture — Endgame Feature Vision"
|
||||
author: Nigel
|
||||
round: SW1-R3
|
||||
---
|
||||
|
||||
# Replayability Architecture — Endgame Feature Vision
|
||||
|
||||
**Status of previous concern:** The simulation convergence risk I raised in R2 is reframed,
|
||||
not dismissed. The PO's clarification is correct: player agency is the primary replayability
|
||||
lever; equilibrium is signal not failure; propagation is the mechanism. This document
|
||||
translates those three points into concrete design.
|
||||
|
||||
---
|
||||
|
||||
## 1. The Replayability Stack
|
||||
|
||||
Replayability in The Settled Reach operates at three tiers. They are not interchangeable.
|
||||
|
||||
### Tier 1 — Player Agency (primary)
|
||||
|
||||
The player's choices are the dominant source of run-to-run difference. Two runs diverge
|
||||
primarily because two players made different decisions, not because the world was generated
|
||||
differently.
|
||||
|
||||
**The axes of agency:**
|
||||
|
||||
- **Character creation.** Who you are determines your starting position, starting knowledge,
|
||||
and starting access. A dock logistics worker and a Commission field officer begin in the
|
||||
same canonical galaxy with completely different social maps. Their knowledge of Van Maanen's
|
||||
Star is different on day one — not because the world is different, but because their
|
||||
relationship to it is.
|
||||
|
||||
- **Where you go.** 300+ systems. The player visits a fraction of them. Exploration sequence
|
||||
is a durable creative choice — there is no optimal route. Every sequence produces a
|
||||
different set of first impressions, different economic states at arrival, different
|
||||
relationships formed.
|
||||
|
||||
- **Who you know.** Social connections are the content selector. Every meaningful relationship
|
||||
determines what part of the world gets generated in detail. The dock worker's Tau Ceti
|
||||
contact generates one neighborhood; the merchant's contact generates another. The player's
|
||||
social map writes the world.
|
||||
|
||||
- **What you do economically.** Buying a business, building trade relationships, triggering
|
||||
corporate or political pressure in a system — all of these tweak core dials that propagate
|
||||
through the network. The player is not observing an economy; they are participating in one
|
||||
that responds.
|
||||
|
||||
**The comparison test at Tier 1:** Two players describing their Van Maanen's Star experience
|
||||
have different characters, different contacts, different businesses, different reason to be
|
||||
there. Their stories diverge at the premise, not at the wallpaper.
|
||||
|
||||
### Tier 2 — Simulation Trajectory (secondary)
|
||||
|
||||
The background simulation runs independently of player action. Economic pressures build,
|
||||
trade flows shift, political balances tip, corporate facilities succeed or fail. The simulation
|
||||
produces a different state at every location every time the player arrives — not because the
|
||||
world was seeded differently, but because time has passed and things have happened.
|
||||
|
||||
**Equilibrium is signal.** When the simulation reaches a stable state at a location, that
|
||||
stability tells the player something: nothing significant has happened here, or the pressures
|
||||
have balanced, or this system is controlled tightly enough to absorb shocks. A stable
|
||||
system is information, not dead air. A system that has been destabilised by a corporate
|
||||
disaster or a portal closure carries visible evidence of what happened. The player reads
|
||||
trajectory from current state.
|
||||
|
||||
**Events are entropy injection.** Corporate disasters. Portal closings. Political shifts.
|
||||
Development successes. Each event tweaks core dials on one or more systems — trade volumes,
|
||||
faction influence, population pressure, economic health — and those tweaks propagate through
|
||||
the interconnected network. The world does not stay stable because it is designed to drift;
|
||||
it stays variable because it is continuously perturbed by events that have real causes.
|
||||
|
||||
**The comparison test at Tier 2:** Two players arriving at the same system at different
|
||||
in-game dates encounter different economic states. One arrived during a corporate consolidation
|
||||
that was pulling workers from the residential districts. The other arrived after the dust
|
||||
settled — the district had been remade, the workers had negotiated a collective structure.
|
||||
Same geography. Different situation. Same canonical starting point. Different trajectory.
|
||||
|
||||
### Tier 3 — Generation Hooks (tertiary)
|
||||
|
||||
Two specific generation mechanisms create world content that is unique per run because it is
|
||||
responsive to what the player specifically did.
|
||||
|
||||
**NPC-driven generation.** When the player forms a meaningful relationship with someone from
|
||||
a distant location, that location's relevant neighborhood generates in response. Kael's sister's
|
||||
workshop at Tau Ceti did not exist until the player developed a close enough connection with
|
||||
Kael for her to matter. After that point, it is a real place — physically visitable, with its
|
||||
own economics, its own NPCs, its own role in the local social triangle structure.
|
||||
|
||||
**News-driven generation.** The Reach-wide news system reports events that reference specific
|
||||
locations. When a news report references a location, that location must exist if the player
|
||||
travels to it. The events that fire the news — which system has the corporate disaster, which
|
||||
town has the gas main failure, which settlement is the center of the political dispute —
|
||||
emerge from simulation state. They differ between runs because the simulation trajectories
|
||||
differ.
|
||||
|
||||
---
|
||||
|
||||
## 2. NPC-Driven and News-Driven Generation — How They Create Replay Variety
|
||||
|
||||
### NPC-driven generation
|
||||
|
||||
Every ambient NPC is a potential social connection. There is no hard line between background
|
||||
characters and narrative characters. Any NPC who becomes meaningful through player interaction
|
||||
carries with them a real home — a place that generates when the relationship deepens enough
|
||||
to matter.
|
||||
|
||||
The run-to-run variety this creates is structural, not cosmetic. Two runs in the same
|
||||
starting location with the same character class produce different social networks because
|
||||
the player makes different social choices, and those different social networks generate
|
||||
different parts of the world in detail. In run 1, the bar regular who becomes a friend is
|
||||
from Novo Esperança — her neighborhood there generates. In run 2, the regular who becomes
|
||||
a friend is from a Crux Corridor mining colony — a completely different district, on a
|
||||
completely different planet, generates instead.
|
||||
|
||||
The player's social map is the procedural content system. Relationships are the content
|
||||
selector. The world's detail layer is not generated uniformly — it is generated in response
|
||||
to who the player cared enough to know.
|
||||
|
||||
This hook is invisible to the player. They feel that they found a real place, not that the
|
||||
simulation made them a personalised level.
|
||||
|
||||
### News-driven generation
|
||||
|
||||
The Reach-wide news reports on real simulation events. The simulation produces the event;
|
||||
the news reports it; the location must exist. Events that become news are those that cross
|
||||
a threshold of significance in their system's simulation — a corporate facility failure large
|
||||
enough to affect regional trade, a political realignment significant enough to reach Reach-wide
|
||||
channels, a disaster with mortality.
|
||||
|
||||
Which systems host these events differs between runs because simulation trajectories differ.
|
||||
The same type of event (corporate disaster) fires in different systems because different
|
||||
systems have different economic pressures at different times. The news-driven generation hook
|
||||
therefore creates a different geography of notable locations per run — not a radically
|
||||
different set of 300 systems, but a different pattern of which systems have recent, notable
|
||||
simulation history when the player first arrives.
|
||||
|
||||
---
|
||||
|
||||
## 3. The Propagation Model
|
||||
|
||||
**The mechanism:** Any event that tweaks core dials in any system propagates through the
|
||||
interconnected trade and political network, rebalances supply and demand, shifts faction
|
||||
influence, and produces local consequences visible at district and room level.
|
||||
|
||||
**The dials:** Bulk import/export flows per system. Corporate facility presence and health.
|
||||
Faction political standing. Population pressure. Economic tier (prosperous/faltering/growing/stable).
|
||||
|
||||
**The cascade:**
|
||||
|
||||
```
|
||||
Event fires in System A
|
||||
→ System A's core dials shift
|
||||
(e.g. corporate disaster drops manufacturing output)
|
||||
→ Trade network rebalances
|
||||
(adjacent systems see supply shortage, prices shift,
|
||||
competing producers see demand increase)
|
||||
→ Faction influence adjusts
|
||||
(weakened corporate presence → guild or government fills vacuum)
|
||||
→ Settlement economic health shifts
|
||||
(prosperous → faltering, or vice versa)
|
||||
→ District character updates
|
||||
(commercial district condition degrades, new faction signage appears,
|
||||
construction pauses, workers leave or arrive)
|
||||
→ Room simulation primitives update
|
||||
(the bar's monthly turnover drops,
|
||||
employee count falls, stock quality degrades)
|
||||
→ Environmental evidence accumulates
|
||||
(closed shops, repurposed storefronts, memorial plaques
|
||||
if the disaster had casualties)
|
||||
```
|
||||
|
||||
**What "set up propagation properly" means:** The bulk import/export list per system is both
|
||||
a simulation primitive (trade flows) and a content driver (what's on store shelves, what's
|
||||
in short supply, what's being hoarded). When the simulation produces a shortage of a specific
|
||||
commodity in a specific corridor, that shortage must be visible in the rooms: the shelf is
|
||||
empty, the merchant apologises for it, the news ticker mentions it. The simulation and the
|
||||
content layer are not separate — they are the same data at different levels of detail.
|
||||
|
||||
**The player as perturbation:** Everything above applies to world events. Player actions
|
||||
introduce the same perturbations through the same propagation model. The player who builds
|
||||
a successful logistics business in Van Maanen's Star changes the system's economic dial. The
|
||||
player who triggers a corporate rival's collapse introduces the same event-type as a natural
|
||||
corporate disaster. The player is not a special case in the propagation model — they are an
|
||||
event source among many, with the unique property that they can observe what they caused.
|
||||
|
||||
---
|
||||
|
||||
## 4. What Stays Fixed vs What Varies
|
||||
|
||||
### Fixed between runs (invariants — players learn these)
|
||||
|
||||
| What | Why it's fixed |
|
||||
|------|----------------|
|
||||
| Galaxy topology — 300+1 systems, wormhole routes | The Settled Reach is a canonical place. Route knowledge is durable. Players learn the network. |
|
||||
| Topography — authored world maps, mountains/rivers/coasts | Geography is permanent. The river that bisects the commercial district always bisects it. Players learn spatial logic once. |
|
||||
| Cultural geography — corridor identities per system from systems.db | Authored setting. A Commonwealth system has Commonwealth spatial grammar. This is knowledge the player earns. |
|
||||
| GTTR entries — authored narrative per system | The Guide is written at a canonical moment. It sets the expectation the simulation then either confirms or diverges from. |
|
||||
| Canonical starting state — faction standings and economic structure at game start | Every run begins from the same authored configuration. Veterans know this. |
|
||||
|
||||
The fixed layer is learnable, which is a feature. A player on their fifth run navigates
|
||||
the Reach with earned geographic and cultural competence. Their knowledge of how Commonwealth
|
||||
stations are laid out, which systems are transit hubs, which rivers create chokepoints — all
|
||||
of this is durable knowledge that makes them better at the game. None of it tells them what
|
||||
is happening in a system right now.
|
||||
|
||||
### Varies between runs (variables — driven by simulation and player)
|
||||
|
||||
| What | What drives the variation |
|
||||
|------|--------------------------|
|
||||
| Economic health per system and settlement | Simulation trajectory: events, trade flows, corporate facility success/failure |
|
||||
| Faction territorial control | Simulation trajectory: political pressure, corporate disasters, development efforts |
|
||||
| NPC relationship states | Player social choices + simulation-driven NPC events |
|
||||
| District condition and era character | Simulation events that leave observable traces |
|
||||
| Which neighborhoods exist in detail | Player social connections via NPC-driven generation |
|
||||
| Which locations have recent notable history | Simulation events via news-driven generation |
|
||||
| The state of player-owned assets | Simulation economic drift plus player action |
|
||||
|
||||
The varying layer is what produces different stories. A veteran who knows that Van Maanen's
|
||||
Star always starts with Iron Bloc commercial dominance does not know whether that dominance
|
||||
has been challenged, consolidated, or broken by the time they arrive. They know the bones.
|
||||
The current situation — who controls what, what is in shortage, whose business has just
|
||||
failed, which NPC has just moved — is always new.
|
||||
|
||||
---
|
||||
|
||||
## 5. The "Two Players Comparing Notes" Test at Each Scale
|
||||
|
||||
The design is correct when two players can describe the same system in the same run
|
||||
window and have genuinely different stories. Here is what those stories look like at
|
||||
each scale.
|
||||
|
||||
**Galaxy scale:**
|
||||
"My run, the big event early on was the portal closure at Tau Ceti. Changed all the trade
|
||||
routes through the east corridor — prices spiked on about six systems."
|
||||
"We had a massive corporate disaster in the North Reach. The Iron Bloc lost three facilities
|
||||
in eighteen months. Political chaos for a year."
|
||||
*Same galaxy. Different perturbation sequence. Different economic histories.*
|
||||
|
||||
**System scale:**
|
||||
"Van Maanen's Star when I got there was still fully corporate. Commercial districts locked
|
||||
down, very controlled feel."
|
||||
"I arrived late. By that point the guilds had made serious inroads on the east side. It was
|
||||
contested — you could feel the tension. Completely different from what you're describing."
|
||||
*Same canonical starting state. Different simulation trajectory at time of arrival.*
|
||||
|
||||
**Settlement scale:**
|
||||
"The transit district was quiet — it had been struggling economically for a while before
|
||||
I got there. Half the shops were changed over."
|
||||
"Mine was in the middle of a boom when I arrived. Expansion everywhere. The place felt
|
||||
genuinely busy."
|
||||
*Same authored settlement. Different economic health at time of visit.*
|
||||
|
||||
**District scale:**
|
||||
"The commercial district I spent most of my time in was next to the workers' collective
|
||||
housing — the whole social atmosphere was about labour politics. Every conversation bent
|
||||
back to it."
|
||||
"Mine was adjacent to the tech cluster. Completely different social texture. People were
|
||||
optimistic, competitive, ambitious. Same city, felt like a different world."
|
||||
*Same authored geography. Different simulation-driven social triangle activity in
|
||||
adjacent zones — which drove different NPC motivations through the district.*
|
||||
|
||||
**Room scale:**
|
||||
"I ended up spending a lot of time at a bar run by someone whose family was from Novo
|
||||
Esperança. Eventually I met her sister there — the whole extended family network became
|
||||
part of my story. I even visited their neighborhood on the coast when I travelled there."
|
||||
"I never developed that kind of connection in the early game. The same bar was just
|
||||
background to me. I knew the bartender but that was it."
|
||||
*Same bar. Same bartender. One player activated the NPC-driven generation hook. The other
|
||||
didn't. Different world surfaces as a result.*
|
||||
|
||||
---
|
||||
|
||||
## 6. Design Commitments Required
|
||||
|
||||
The replayability architecture described above makes the following non-negotiable demands:
|
||||
|
||||
1. **The propagation model must be implemented correctly.** Bulk import/export per system
|
||||
must feed both simulation trade flows and room-level content (shelves, prices, dialogue).
|
||||
Without this bridge, the simulation produces economic numbers that are invisible to the
|
||||
player. Invisible simulation is not replayability.
|
||||
|
||||
2. **The background simulation design workshop must separate invariants from variables
|
||||
explicitly.** The list in section 4 is a starting point, not a final answer. The workshop
|
||||
must confirm which subsystems are designed to be stable reference points and which are
|
||||
designed to resist equilibrium. These require different implementation approaches.
|
||||
|
||||
3. **Every ambient NPC must carry sufficient data to become a narrative NPC on demand.**
|
||||
The ambient/narrative distinction does not hold if any ambient can evolve. Minimum bundle:
|
||||
cultural background, economic role, relationship network hooks, behavioral tell config.
|
||||
Generation must not treat any NPC as disposable filler.
|
||||
|
||||
4. **Environmental archaeology must be sourced from real simulation events.** No fabricated
|
||||
history. The simulation's event density must be high enough to give every district the
|
||||
player enters at least one observable trace of something that happened before they arrived.
|
||||
If the simulation runs for years of in-game time but produces only economic numbers with
|
||||
no physical manifestations, the world has financial history but no human history.
|
||||
|
||||
5. **Exception communities must be resilient against simulated normalization.** Refugee
|
||||
colonies, Perpetual Founder Stamp systems, Gate Silence survivors — these are the
|
||||
settlement histories that give rooms their distinctive cultural grammar. The background
|
||||
simulation must be designed with an explicit constraint: unusual settlement histories
|
||||
do not get smoothed into the mean over time. This is a design requirement, not an
|
||||
implementation detail.
|
||||
@@ -0,0 +1,119 @@
|
||||
---
|
||||
title: "SW1-R1 — Ozzie: Player Experience Questions for World Generation"
|
||||
author: Ozzie
|
||||
round: SW1-R1
|
||||
workshop: world-generation
|
||||
date: 2026-03-24
|
||||
---
|
||||
|
||||
# World Generation — Player Experience Questions
|
||||
|
||||
## My angle
|
||||
|
||||
The generator can be architecturally sound and still produce spaces that feel like nothing. My job is to make sure that doesn't happen. Every one of these questions is about the gap between "technically correct space" and "place I will remember."
|
||||
|
||||
The camera is low (30°, diamond rotation — D-148). The player can see faces, building fronts, depth. That's a gift. The generator has to earn it.
|
||||
|
||||
---
|
||||
|
||||
## Q1: Does a new location communicate what it IS within 3 seconds?
|
||||
|
||||
**The question:** When a player arrives at a generated location they've never seen, can they read the zone identity — station corridor, market district, rural farmstead, industrial extraction — from visual shape alone, before a single NPC speaks or a single sign appears?
|
||||
|
||||
**Why it matters:** First impressions are permanent. If the player can't tell a residential block from a commercial block in the first 3 seconds, the world reads as an undifferentiated tile maze, not a place. The 30° camera shows building fronts and architectural silhouettes — but only if the generator is producing distinctive ones.
|
||||
|
||||
**Options:**
|
||||
- A. **No visual grammar distinction** — zone identity comes from NPC dialogue, signs, and content only
|
||||
- B. **Landmark density signals** — many market stalls = market; open fields = rural; tight corridors = station
|
||||
- C. **Distinct architectural vocabulary per zone** — station modules have round pressure doors and overhead pipes; markets have open-fronted stalls with awnings; farmsteads have low-pitched rooflines and fenced plots
|
||||
- D. **Cultural constraint visible in architecture** — Van Maanen's Star buildings look different from New Commonwealth buildings, even at the same zone type
|
||||
|
||||
**My recommendation: C, then D as a layer on top.**
|
||||
|
||||
C is structural and ships fast. A station and a market *should* look different from the roof down, not just from the signs up. D is what makes the world feel like it has history — but it's more expensive to author. Ship C first, plan D for the cultural texture pass.
|
||||
|
||||
---
|
||||
|
||||
## Q2: Does fog-of-war exploration feel like discovery or like corridor management?
|
||||
|
||||
**The question:** The fog system reveals tiles as the player moves. In a generated space, is the revelation path designed to reward curiosity — or does the player just walk forward until the fog retreats like a lawn mower?
|
||||
|
||||
**Why it matters:** This is the core exploration loop. Every roguelike lives or dies on whether "what's around this corner" is a question worth asking. If the generator places interesting things evenly distributed in a grid, the answer is always "more of the same." You need VARIATION in revelation payoff.
|
||||
|
||||
**Options:**
|
||||
- A. **Ambient density** — interesting objects placed at statistical intervals; no deliberate landmark placement
|
||||
- B. **Crossroads rewards** — generator places significant features at movement decision points (junctions, doorways, transitions between zone sub-types)
|
||||
- C. **Zone anchor landmark** — each generated location has one "money shot" feature that the player will inevitably encounter — a market's central fountain, a station's observation window, an industrial zone's massive reactor core
|
||||
- D. **Dead ends earn their keep** — off-axis corridors and side rooms always contain something worth the detour (loot, social encounter, environmental story)
|
||||
|
||||
**My recommendation: C + D.**
|
||||
|
||||
C is ESSENTIAL. Every place needs one moment that makes the player stop. Not a quest marker. Just the generator saying "this place has character." D prevents players from ignoring side routes — but only if the generator can guarantee the detour payoff. If it can't guarantee D, don't promise it.
|
||||
|
||||
---
|
||||
|
||||
## Q3: How much should upper floors / z-levels tell the player about where they are?
|
||||
|
||||
**The question:** The tile renderer currently only renders ground floor. D-148 confirms multi-height structures. When a player is inside a ground-floor station corridor, should they feel the mass of the building above them — and how?
|
||||
|
||||
**Why it matters:** Spatial grounding. In a real building, you know you're in a basement because the ceiling is low, or on a ground floor because you can see out, or in a tower because the windows show sky. Generated spaces that are purely 2D floor plans have no vertical context — and in the Settled Reach, stations and port facilities absolutely have vertical mass. The camera angle gives us the angle to USE this.
|
||||
|
||||
**Options:**
|
||||
- A. **Floor isolation** — only the player's current floor is visible; clean, zero confusion
|
||||
- B. **External silhouette above** — building mass visible above current floor (walls continue upward as opaque geometry), giving height sense without revealing upper-floor interiors
|
||||
- C. **Ghost/cutaway fade** — upper floors fade to transparent when the player is below them (classic immersive sim treatment)
|
||||
- D. **Manual floor toggle** — player cycles between floors with a keybind
|
||||
|
||||
**My recommendation: B for MVP, C as the premium tier.**
|
||||
|
||||
B is cheap and TELLS A STORY. You're walking through a narrow corridor and there's a 6-storey block above you. That mass communicates threat, scale, habitation. C is beautiful but demands a robust LOD/transparency system for generated geometry. Start with B. The player feeling the weight above them is worth the investment.
|
||||
|
||||
---
|
||||
|
||||
## Q4: What's the minimum NPC density that makes a generated space feel inhabited?
|
||||
|
||||
**The question:** A generated location with zero NPCs is a ghost town. A generated location with too many NPCs is a crowd simulator. There's a threshold where a space tips from "eerie" to "inhabited." Where is that threshold — and is "eerie" ever the correct reading?
|
||||
|
||||
**Why it matters:** NPC presence is the warmth signal. The whole v0.2 pivot is about making generated NPCs feel like people. But that only works if the SPACE they're in feels like it belongs to them. A dockworker in an empty warehouse doesn't feel like a person — they feel like a test entity. The environment needs to frame the character.
|
||||
|
||||
**Options:**
|
||||
- A. **Uniform minimum** — at least 1 NPC per 50 tiles in any generated space (very sparse, "early morning")
|
||||
- B. **Zone baseline** — each zone type has a target occupancy: stations denser (1/20), wilderness near-empty (1/200), markets crowded (1/10)
|
||||
- C. **Time-of-day pattern** — generator knows the location's activity rhythm; morning rush fills corridors, 0300 empties them
|
||||
- D. **Narrative state override** — story events can depopulate or overpopulate a location (after an incident, everyone's locked down; during a festival, it's packed)
|
||||
|
||||
**My recommendation: B as the default baseline, C as the simulation layer, D as the system that makes players talk.**
|
||||
|
||||
B ships first — different zones need different energy. C is what separates a simulation from a dollhouse. D is the wow. When the player walks into a market and it's weirdly empty and then they find out there was a health quarantine — THAT'S the game. D requires the world-state to feed into generation, but it's worth the architecture.
|
||||
|
||||
---
|
||||
|
||||
## Q5: What is the "screenshot test" — and can we design for it deliberately?
|
||||
|
||||
**The question:** A generated space passes the screenshot test when a player stops, frames a shot, and wants to share it. This happens when scale contrast is striking, or an unexpected juxtaposition creates meaning, or cultural specificity is visible. Can we design the generator to deliberately produce screenshot moments — and how often should they occur?
|
||||
|
||||
**Why it matters:** Screenshot moments are word-of-mouth. Dwarf Fortress players don't share spreadsheets — they share the story of the goblin siege that ended with the king drowning in his own wine. Rimworld players share the time their colonist's murderous pet llama saved the base. The Settled Reach needs its equivalent. A generator that produces only functional spaces produces a game no one talks about.
|
||||
|
||||
**Options:**
|
||||
- A. **Emergence only** — screenshot moments come from content/NPC system interactions, not spatial design; the generator just makes rooms
|
||||
- B. **Scale contrast moments** — generator deliberately places at least one large-scale architectural feature per area (a massive cargo bay beside a cramped sleeping quarter block; an open plaza at a station hub)
|
||||
- C. **Cultural fingerprint visible** — Van Maanen's Star architecture is immediately readable as distinct; a player can tell where they are from the aesthetic alone
|
||||
- D. **Environmental story clusters** — generator places prop groups that imply events (the overturned table with a single boot; the memorial with fresh flowers; the barricaded doorway with scratches on the frame)
|
||||
|
||||
**My recommendation: All four, but priority order is C > D > B > A.**
|
||||
|
||||
C is the most structurally load-bearing — it requires cultural constraints to flow all the way into architectural vocabulary, which is a generator architecture question, not a styling question. D is cheaper and immediately adds narrative texture. B is a spatial design principle that guides room scale decisions. A is what we get if we do nothing deliberate — and it's not enough.
|
||||
|
||||
---
|
||||
|
||||
## Summary for Product Owner
|
||||
|
||||
| # | Question | My Recommendation |
|
||||
|---|----------|-------------------|
|
||||
| Q1 | Does zone type communicate visually in 3 seconds? | Distinct architectural vocabulary per zone (C), cultural layer later |
|
||||
| Q2 | Does exploration feel like discovery? | Zone anchor landmark (C) + dead ends earn their keep (D) |
|
||||
| Q3 | How visible are upper floors / z-levels? | External silhouette above = building mass without interior clutter (B) |
|
||||
| Q4 | What NPC density makes a space feel inhabited? | Zone baselines (B) + time-of-day rhythm (C) + narrative state override (D) |
|
||||
| Q5 | Can we design screenshot moments deliberately? | Cultural fingerprint (C) > environmental story clusters (D) > scale contrast (B) |
|
||||
|
||||
The theme running through all five: **the generator needs to know what it's expressing, not just what it's placing.** Tiles are the medium. Place identity, cultural character, and inhabitation rhythm are the message. If the generator only knows tile types and adjacency rules, the spaces will be technically correct and emotionally empty.
|
||||
@@ -0,0 +1,128 @@
|
||||
---
|
||||
title: "SW1-R1b — Ozzie: Galaxy-to-Ground Wow Moments (Endgame Vision)"
|
||||
author: Ozzie
|
||||
round: SW1-R1b (replaces SW1-R1)
|
||||
workshop: world-generation
|
||||
date: 2026-03-24
|
||||
---
|
||||
|
||||
# World Generation — Galaxy-to-Ground Player Experience
|
||||
|
||||
## My angle
|
||||
|
||||
A universe is not a large location. It's a collection of PROMISES. Every system on that galaxy map is a story the player hasn't heard yet. The generator's job isn't to fill space — it's to make promises that are worth keeping.
|
||||
|
||||
The cascade from galaxy map to ground floor has five or six emotional beats. If any one of them fails, the player stops caring about the ones after it. I'm going to ask about the beats that are most at risk.
|
||||
|
||||
Previous output (`ozzie-sw1r1.md`) Q2 and Q5 still apply — discovery vs corridor management and the screenshot test both scale up to every level. Consider them inherited.
|
||||
|
||||
---
|
||||
|
||||
## Q1: Is the Galaxy Map a Wonder or a Menu?
|
||||
|
||||
**The question:** The player first sees 300 system dots. In that moment, do they feel possibility — or do they feel homework? What makes a dot interesting enough to click?
|
||||
|
||||
**Why it matters:** This is the first impression of the entire universe. If the map reads as a management interface, the player will play it as a management game. If it reads as a mystery with geography, they'll play it as exploration. THAT'S the game we want. The map isn't just navigation — it's the universe advertising itself.
|
||||
|
||||
**Options:**
|
||||
- A. **Economic layer only** — trade routes, supply/demand signals, resource tags; navigable, dry
|
||||
- B. **Danger/reputation signals** — faction colors, conflict zones, "known hostile," player reputation icons at visited systems
|
||||
- C. **Mystery layer** — rumors, anomalies, "someone came back from there changed"; most of the map is unnamed/unknown before you go
|
||||
- D. **Layered and unlockable** — start with just economic signal and bare geography; faction and mystery layers unlock through play; the map gets richer the more you've done
|
||||
|
||||
**My recommendation: D.**
|
||||
|
||||
This is the only option that makes the map feel like a REWARD for existing in the world. At the start, 300 systems is overwhelming. Later, 300 systems is a memory palace. The map should reflect what the player knows — so a dot they've been to is richer than a dot they've only heard about. The universe earns its own scale through play.
|
||||
|
||||
---
|
||||
|
||||
## Q2: The Arrival Moment — What's the First Thing You See?
|
||||
|
||||
**The question:** Every time a player arrives at a system they've never visited, there's a cinematic beat. That beat is either earned or wasted. What does the camera/world give the player in that first second?
|
||||
|
||||
**Why it matters:** This is a once-per-system emotional punch. No system should feel like loading a level. The arrival should give the player a FEELING before they've made a single decision. That feeling is what they'll associate with the system forever.
|
||||
|
||||
In terms of the cascade: scale 1 is the map (promise). Scale 2 is the arrival (delivery on the promise). If the delivery is flat, the promise was cheap.
|
||||
|
||||
**Options:**
|
||||
- A. **Gateway exit into a station** — immediate shelter, tight corridors, you arrive already INSIDE something; the scale is implied not shown
|
||||
- B. **Empty space with a planet in the distance** — lonely, vast, inviting from far away; scale is felt as absence first
|
||||
- C. **Orbital view** — the planet fills half the viewport, geography visible, you can see where the settlements are before you land; the whole thing at once, then you choose
|
||||
- D. **Contextual arrival** — how you traveled determines what you see; charter flight lands at a port, jump point exits into open space, smuggler route brings you in at low orbit in the dark
|
||||
|
||||
**My recommendation: D, with C as the default.**
|
||||
|
||||
D makes travel feel meaningful — your arrival experience depends on your choices. But C should be what charter/normal transit gives you because THE ORBITAL VIEW IS THE WOW. You see the whole world before you enter it. That's the emotional structure of arrival — survey, then commit. Let the player WANT the planet before they're on it.
|
||||
|
||||
---
|
||||
|
||||
## Q3: Does the World Feel Pre-Existing or Generated-As-You-Walk?
|
||||
|
||||
**The question:** Players can feel the difference between a world that was there before them and a world being constructed as they move. Chunk streaming means we ARE generating as they walk — but the player must NEVER know that. What creates the illusion of a world that existed before the player?
|
||||
|
||||
**Why it matters:** This is THE fundamental question of procedural generation at human scale. A world that feels generated-on-demand is a level. A world that feels pre-existing is a PLACE. The Settled Reach needs to be a place.
|
||||
|
||||
**Options:**
|
||||
- A. **Visual sightlines** — you can see buildings and landmarks before you reach them; the world feels physically present at distance
|
||||
- B. **NPC knowledge footprint** — NPCs have opinions about places they've been; social evidence of a wider world; someone mentions a market three settlements over as if it's obvious it exists
|
||||
- C. **Economic activity at distance** — prices, shortages, and trade traffic imply a world of activity you're not observing; the economy is alive somewhere you haven't been
|
||||
- D. **Environmental archaeology** — prop placement tells stories of things that happened before you arrived; the generator leaves evidence, not just furniture
|
||||
|
||||
**My recommendation: D first, then B, then A, then C.**
|
||||
|
||||
D is the most visceral. Finding the crashed cargo loader with the personal effects still inside — that's the moment the player stops thinking "I'm in a generated space" and starts thinking "someone was here before me." B creates the social fabric. A creates the physical fabric. C creates the economic fabric. But D is what makes players FEEL it in the gut.
|
||||
|
||||
---
|
||||
|
||||
## Q4: The Return Visit — Does a Place Remember You?
|
||||
|
||||
**The question:** The player visits a location. They leave. They come back. Has the world continued without them? Has it remembered what they did?
|
||||
|
||||
**Why it matters:** This is the test of whether the simulation is real or theatrical. A stage set looks the same every time you walk on it. A living place is different because time passed. But — and this is critical — the right question isn't just "what changed?" It's "do I feel the passage of time, or just randomized differences?"
|
||||
|
||||
The emotional beats of return:
|
||||
- Recognition ("I know this place, those crates were there before")
|
||||
- Change ("that shop is closed — what happened?")
|
||||
- Consequence ("they KNOW what I did here")
|
||||
|
||||
**Options:**
|
||||
- A. **Static spaces** — locations don't change between visits; you can memorize them, they're reliable
|
||||
- B. **NPC drift** — characters have moved, left, aged, formed new relationships; the social fabric has shifted
|
||||
- C. **Physical/economic change** — construction has continued or halted, shops have opened or closed, prices have moved
|
||||
- D. **Consequence echo** — the world has reacted to what the PLAYER did; people remember, consequences have propagated outward
|
||||
|
||||
**My recommendation: B + D as minimum, C if the simulation can support it.**
|
||||
|
||||
D is the one that makes players FEEL something. The first time you come back to a place and someone says "I heard about what you did at the refinery" — THAT'S the game. B makes the world feel alive independent of you. Together, B and D create the sense that the world has its own momentum that your actions bend, not control. That's the feeling of existing in a society, not starring in a game.
|
||||
|
||||
---
|
||||
|
||||
## Q5: Where Is the "You Are Here" Moment — When Does the Scale Drop?
|
||||
|
||||
**The question:** There's a specific emotional moment in the best space games where the player's gut drops as they understand the REAL scale of what they're in. NMS has it when you fly to orbit. Elite has it when you realize the galaxy map is real star positions. The Settled Reach has 300 systems, countless settlements, and a single character navigating it all. When does the player feel that scale — really feel it — for the first time?
|
||||
|
||||
**Why it matters:** Scale only matters if it's felt. A universe you navigate by menu is not a universe you're IN. The scale reveal is a designed moment — it has to be crafted, not discovered by accident. If it never happens, the Settled Reach is just a big game. If it happens right, the player understands what kind of game this is.
|
||||
|
||||
**Options:**
|
||||
- A. **Emergent from play** — no designed reveal; scale accumulates from distances traveled and time spent
|
||||
- B. **The galaxy map IS the reveal** — your first time seeing all 300 systems from one screen is the designed gut-drop
|
||||
- C. **The "you are here" zoom** — the player sees the full system map and then zooms in and finds their current location as a tiny dot in a huge geography; the physical sensation of smallness
|
||||
- D. **Scale through NPC perspective** — an NPC casually mentions a weeks-long journey to a place you've been treating as "nearby"; scale felt as social fact, not visual fact
|
||||
|
||||
**My recommendation: C + D, layered.**
|
||||
|
||||
C is a PHYSICAL sensation — the zoom-in is a gut punch. You are here, and here is very small. Some version of this — see your location on the orbital view, understand how much is not-you — should be a designed moment, not an accidental one. D reinforces it through social texture. Make scale FELT through other people's experience of distance, not just the camera. Together: the universe is big visually AND socially. You are one person. That's the game.
|
||||
|
||||
---
|
||||
|
||||
## Summary for Product Owner
|
||||
|
||||
| # | Question | My Recommendation |
|
||||
|---|----------|-------------------|
|
||||
| Q1 | Is the galaxy map a wonder or a menu? | Layered and unlockable — the map gets richer as you explore (D) |
|
||||
| Q2 | What does the player see when they arrive? | Contextual by travel method; orbital view as default (D/C) |
|
||||
| Q3 | Does the world feel pre-existing? | Environmental archaeology first — evidence of history before the player (D) |
|
||||
| Q4 | Does a place remember you? | Consequence echo + NPC drift minimum (B + D) |
|
||||
| Q5 | When does the scale drop? | Designed "you are here" zoom moment + NPC social scale texture (C + D) |
|
||||
|
||||
The through-line: **the universe earns its scale through evidence, not declaration.** 300 systems isn't impressive because someone said it's 300 systems. It's impressive because every system has been somewhere for someone else, and when you arrive you can feel it. The generator's job is to leave traces — not just content.
|
||||
@@ -0,0 +1,139 @@
|
||||
---
|
||||
title: "SW1-R2 — Ozzie: Player Experience Synthesis"
|
||||
author: Ozzie
|
||||
round: SW1-R2
|
||||
workshop: world-generation
|
||||
date: 2026-03-24
|
||||
---
|
||||
|
||||
# World Generation — Player Experience Synthesis
|
||||
|
||||
---
|
||||
|
||||
## 1. The Insert Window Rewrites the Arrival Beat
|
||||
|
||||
I recommended orbital view as the default first impression. What Jeroen chose is more interesting: **the diegetic insert window with a planetary screenshot and the GTTR entry.**
|
||||
|
||||
This is a fundamentally different emotional structure. I assumed cold arrival — you see a place before you know what it is. What we actually have is **warm arrival** — you read someone else's perspective on the place before you land. The GTTR entry is the establishing shot. The screenshot is the promise. Then you arrive and find out if the promise holds.
|
||||
|
||||
THAT IS A BETTER DESIGN. Here's why:
|
||||
|
||||
Cold arrival (my original Q2) creates wonder from ignorance. Warm arrival creates wonder from expectation-vs-reality. The GTTR says Van Maanen's Star is a tight-knit industrial community with a tradition of collective labor. Then you land and you see whether that's true NOW — or whether the simulation has drifted. The insert is writing you a check. The world has to cash it.
|
||||
|
||||
**The critical player experience design question this creates:**
|
||||
|
||||
The GTTR entry is authored at a point in time. The simulation has been running. What does the player feel when reality diverges from the GTTR? Is it *exciting* (the world has moved on) or *jarring* (I was lied to)?
|
||||
|
||||
**My read:** It's exciting IF the divergence is legible. The GTTR says this place was flourishing. You arrive and it's clearly in economic decline. If you can *see why* — the economic narrative is visible in the space — then the GTTR becomes a historical document and you're reading the gap between past and present. That gap is archaeology. That's the game.
|
||||
|
||||
**Tension for the product owner:** The GTTR's authored voice sets a tone expectation as well as a factual one. If the GTTR entry says "the warmth of the community is palpable" but the simulation has depopulated the place — what does the player feel? Right now I don't know. This needs to be felt in playtest.
|
||||
|
||||
---
|
||||
|
||||
## 2. Environmental Archaeology from Real Events Only — The Simulation Must EARN It
|
||||
|
||||
The decision: no fabricated history. If there's rubble, the simulation produced the explosion.
|
||||
|
||||
I love this in principle. It means when you find a memorial, someone actually died. That's WEIGHT. The problem is what it demands from the simulation.
|
||||
|
||||
The "someone was here before me" feeling requires three things:
|
||||
1. **Events worth leaving traces of** — the simulation must produce events with consequence magnitude (explosions, deaths, economic collapses, fights, weddings, disasters)
|
||||
2. **Traces that are legible to a player** — a prop cluster or environmental scar that READS as "something happened here"
|
||||
3. **Frequency that makes exploration rewarding** — enough events that exploration regularly produces discovery
|
||||
|
||||
The simulation must produce worthy events at a rate that makes archaeology possible. If the background sim mostly produces dry economic drift — prices up, prices down, worker counts shifting — there's nothing to leave physical traces of. Archaeology requires events that leave marks.
|
||||
|
||||
**The follow-up question I want answered:** What is the minimum background event rate for a location to feel archaeologically inhabited? If the sim has been running for 6 months of game time and a location has had zero major events, does it feel like a quiet place or an empty backdrop?
|
||||
|
||||
I suspect the answer is: **quiet is fine IF the NPC social fabric is rich.** A bar that's never had an explosion can still feel alive if the relationships inside it have evolved, fought, reconciled, and changed. Social archaeology — the web of relationships visible through NPC behavior — might be more reliable than event archaeology. Both are real. But social archaeology is generated continuously, not episodically.
|
||||
|
||||
**Gestalt's cascade principle** (rooms must reward observation, every space should tell the player something new) is exactly right here. But the something-new can be relationship evidence, not just event evidence.
|
||||
|
||||
---
|
||||
|
||||
## 3. Full Galaxy Map from Start — Making 300 Dots Feel Like 300 Stories
|
||||
|
||||
I recommended layered/unlockable. Jeroen chose full information from minute one.
|
||||
|
||||
My first reaction: TOO MUCH. 300 dots is homework.
|
||||
|
||||
My second reaction, after sitting with it: **this is correct IF the dots are already named and storied.**
|
||||
|
||||
The galaxy map isn't 300 empty dots. The GTTR entries already exist. The wiki already exists. Every system has a name, a voice, a personality. Van Maanen's Star is already a character. Luyten's Star is already a character. The player isn't looking at an information-sparse grid — they're looking at an annotated atlas. The wonder isn't "what is this?" It's "what IS this, actually, given everything I've heard?"
|
||||
|
||||
That's a different kind of wonder. It's the wonder of the traveler who's read every guidebook. The world has been described to you. Now you go find out if the description is true.
|
||||
|
||||
**But the map's visual presentation has to carry this.** 300 dots that all look the same are homework. 300 dots where your eye can land on a name and feel something — where the map has visual rhythm, faction territory, economic character visible at a glance — those are stories waiting to be entered.
|
||||
|
||||
**The question I want answered:** What does the galaxy map LOOK like? Not the data — the visual experience. Is it a clean star chart? Does it show faction territories as color washes? Does it have economic signal visible without clicking? Does it show which systems you've visited vs. not? The emotional experience of the galaxy map is almost entirely a visual design question, and we haven't asked it yet.
|
||||
|
||||
**Tension:** Full information from minute one means the player knows the universe's geography before they've earned it. In games that use exploration to reveal the map, every newly-revealed area is a reward. In our model, the reward has to come from VISITING a named place, not from REVEALING it. That's a different dopamine loop. It has to be designed intentionally.
|
||||
|
||||
---
|
||||
|
||||
## 4. Any NPC Can Evolve into Narrative — The Space Becomes Meaningful by Proxy
|
||||
|
||||
This is the answer to my original Q5 (the screenshot test). I asked: how do we design screenshot moments deliberately? The answer turns out to be more powerful than anything I suggested.
|
||||
|
||||
**The space where you met someone important becomes important by association.**
|
||||
|
||||
You can't know, when you walk into a generated bar, whether the person at the corner table will matter. Any ambient NPC can evolve into story. This means every generated space carries the POTENTIAL for significance from the moment you enter it. The player brings meaning to it.
|
||||
|
||||
This is a COMPLETELY different model from "designed screenshot moments." It's not the generator producing memorable spaces. It's the simulation producing memorable relationships, and those relationships retroactively charging the spaces they happened in. The bar isn't memorable because the generator made it memorable. The bar is memorable because THAT'S WHERE YOU MET HER.
|
||||
|
||||
**The NPC-driven generation hook is the most exciting sentence in the interview answers:**
|
||||
|
||||
> Meet someone from a distant planet (more than casually) → their house, family, friends, neighborhood get generated at that location. Their address becomes a real visitable place.
|
||||
|
||||
THAT'S THE GAME. That's the moment. You've been traveling with someone for six sessions. You finally go to where they're from. The simulation generates it just for you — their specific neighborhood, their family's apartment. And it fits what you know of them because it was built from their data.
|
||||
|
||||
That's not a screenshot moment. That's a STORY moment. The best kind.
|
||||
|
||||
**The follow-up question I need answered:** Does the player know this is happening? Does the insert tell them "this neighborhood was generated because you know Sela"? Or is it invisible infrastructure — the place just exists, and it just happens to fit?
|
||||
|
||||
My instinct: it should be invisible. The GTTR entry for the system already existed. The neighborhood fits because of authored cultural context. The player should feel like they *discovered* a real place, not like the simulation made them a personalized level. The magic only works if it feels like the world was always there.
|
||||
|
||||
---
|
||||
|
||||
## 5. Tensions and Unresolved Questions
|
||||
|
||||
**Tension 1: The GTTR sets expectations the simulation must exceed**
|
||||
|
||||
The diegetic insert window is brilliant. It also creates a contract. Every authored GTTR entry is a promise. If the simulation delivers on the letter of the promise (the place is industrial, it does have collective labor traditions) but not the spirit (it feels empty, the NPCs don't embody the culture), the player will feel cheated not by the generator but by the guide.
|
||||
|
||||
The test: read a GTTR entry, land, play for 30 minutes. Does the GTTR's description feel TRUE? If not, is that because the simulation hasn't run long enough, because the NPC density is too low, because cultural grammar tokens haven't been authored, or because the text overpromised?
|
||||
|
||||
**Tension 2: Archaeology frequency vs. simulation event rate**
|
||||
|
||||
Real archaeology requires real events. The background simulation needs to produce events worth leaving traces of at a high enough rate that exploration regularly produces discovery. This is a simulation design question, not a generation question — but it bottlenecks the "someone was here before me" feeling.
|
||||
|
||||
If background sim only produces economic numbers, not events with physical consequences, the world will feel like it has financial history but no human history.
|
||||
|
||||
**Tension 3: The galaxy map as the first impression of the universe — has it been designed?**
|
||||
|
||||
300 authored systems, full information from minute one, GTTR entries as the galaxy's voice. This is a great system. But the galaxy map screen itself — the first thing the player sees when they look at the universe — needs to carry emotional weight. Does it? Who is designing it? What does it FEEL like to look at?
|
||||
|
||||
This is the player experience question nobody else has asked yet.
|
||||
|
||||
**Tension 4: Cohesion at small/middle scale, variety at middle/large scale — this needs a player language**
|
||||
|
||||
The spatial design principle (cohesion small/middle, variety middle/large) is correct. But it needs a player-legible version. The player's experience of this principle is: "every neighborhood feels internally consistent and I can orient myself within it" AND "every new district I enter feels genuinely different from the last one."
|
||||
|
||||
Miri's Layer 1 (spatial grammar tokens) and Layer 2 (social pattern tokens) together deliver this without asset cost. A Frost bar and a Tide bar feel different through *space and behavior* before a single object is placed. That's the right implementation target.
|
||||
|
||||
**The question I want the next round to address:** At what distance (city block? district? system?) does the player start to feel "I'm in a different place" vs. "I'm still in the same place"? That's the variety boundary Jeroen described, and it needs to be grounded in a specific spatial experience, not just a design principle.
|
||||
|
||||
---
|
||||
|
||||
## Summary
|
||||
|
||||
The product owner's answers resolved most of my open questions in interesting ways. The four biggest shifts:
|
||||
|
||||
| My assumption | What was chosen | Why it's better (or not) |
|
||||
|---|---|---|
|
||||
| Cold orbital arrival | Warm diegetic GTTR arrival | Better: expectation vs. reality is more interesting than ignorance vs. reality |
|
||||
| Fabricated archaeology is fine | Real sim events only | Better: weight and integrity — but demands the sim produces worthy events |
|
||||
| Layered galaxy map | Full info from minute one | Better IF the map has visual rhythm and named stories — need to see the map design |
|
||||
| Generator makes spaces memorable | Relationships make spaces memorable | WAY BETTER — the NPC-driven generation hook is the game |
|
||||
|
||||
The piece I'm still worried about: **the galaxy map as emotional object.** 300 names is an asset. 300 visual dots is homework. The transition between those is a visual design problem that hasn't been addressed yet.
|
||||
@@ -0,0 +1,165 @@
|
||||
---
|
||||
title: "SW1-R3 — Ozzie: The Player Experience of the Generated Universe"
|
||||
author: Ozzie
|
||||
round: SW1-R3
|
||||
workshop: world-generation
|
||||
date: 2026-03-24
|
||||
---
|
||||
|
||||
# The Player Experience of the Generated Universe
|
||||
|
||||
*Concrete and declarative. This is how it feels.*
|
||||
|
||||
---
|
||||
|
||||
## 1. The Galaxy Map as Emotional Object
|
||||
|
||||
The player opens their insert and sees 300 dots.
|
||||
|
||||
The dots are not empty. Every dot is a name they've already encountered — in transit conversations, in news tickers, in NPC offhand comments. "My cousin works a refinery at Luyten's Star." "Commonwealth systems have better transit infrastructure." "I wouldn't go to GJ-699 alone." The names have been accumulating meaning since hour one.
|
||||
|
||||
The map is a promise index. Every dot is a place someone has told you about, and you haven't been there yet.
|
||||
|
||||
The GTTR entry is visible before you travel. You can browse. You can read what the guide says about a place you've heard the rumors about. You can compare what the guide says ("thriving collective market culture, strong labor solidarity") against what the trader you met said ("don't bother, the corporate acquisition gutted the middle district three years ago"). That gap — between what the guide says and what people who've been recently say — is already information before you set foot there.
|
||||
|
||||
The wonder is not "what is this unknown place." The wonder is "what IS this place I've heard things about, and is what I've heard true?"
|
||||
|
||||
The map works because the player is CHOOSING, not MENU-NAVIGATING. You go where you have a reason to go. Someone you know is from there. A news event happened there. A trade route you've been following terminates there. The universe is not random; it's a web of reasons to go somewhere. The player's insert carries that web.
|
||||
|
||||
**What makes it feel like a universe and not a game board:** The dots stay consistent. Van Maanen's Star is always in the same place. You learn where things are. The map becomes a memory palace over time — "I started here, I went there, I have history in that direction." You accumulate a personal geography of a place you live in.
|
||||
|
||||
---
|
||||
|
||||
## 2. The Arrival Cascade
|
||||
|
||||
**Stage 1 — Transit.** The player has decided to go somewhere. Charter flight, gate transit, smuggler route. During transit, the insert's GTTR window opens automatically. System stats. A planetary screenshot — generated from the authored heightmap and shader, giving the planet's actual surface character. And the guide entry: a voiced, opinionated piece of prose about what this place is.
|
||||
|
||||
The player reads. They form expectations. They think: I'm about to be here.
|
||||
|
||||
**Stage 2 — Arrival.** The method determines the first impression.
|
||||
|
||||
*Charter flight:* Port arrival. You come in at a transport hub. The first thing you see is infrastructure — other travelers, cargo handling, the commercial zone that exists specifically because transit happens here. It's busy. There's scale. You've arrived at the world's public face.
|
||||
|
||||
*Gate transit:* Station interior. The gate disgorges you into a station district — controlled, managed, institutional. Commission inspection checkpoints. Customs infrastructure. The world presents itself as a place with rules before it presents itself as a place with character.
|
||||
|
||||
*Smuggler route:* Low orbit in the dark. You're above the settlement before you're in it. If there's a nightside, you see lights below — the physical fact of habitation. If there's a dayside, you see geography. You arrive with overview before intimacy.
|
||||
|
||||
**Stage 3 — First three seconds on the ground.** This is where the GTTR cashes its check.
|
||||
|
||||
The guide said this place has collective labor culture. You step out and the first thing you notice is the lack of branding — no corporate facades, independent storefronts, workers moving in groups rather than alone. OR: the guide said collective labor culture, and you step out and see corporate signage everywhere, a security checkpoint, workers moving with their heads down. The gap is immediate. The guide was right once. Something changed.
|
||||
|
||||
Either way: you already have a story.
|
||||
|
||||
---
|
||||
|
||||
## 3. The GTTR as Contract — How the Gap Reads as History
|
||||
|
||||
The GTTR was written at a specific moment. The simulation has been running since the canonical starting state.
|
||||
|
||||
When the guide matches what the player finds: the place is stable. This is comfort. This is what "home" feels like at a place you've visited before, when it's still itself. Confidence that the universe is consistent and learnable.
|
||||
|
||||
When the guide diverges from what the player finds: the player is holding two points in time. The guide is the past. Their eyes are the present. The gap between them is history.
|
||||
|
||||
The gap is readable because it's built from real simulation events. The district the guide called thriving is faltering because a specific corporate acquisition happened — and the architectural evidence is there. The corporate facades are newer than the buildings they front. The older storefronts are still there, some of them rebranded, some abandoned. Workers congregate in the old spots out of habit but the character of the congregation has changed. You can SEE the before and the after without anyone telling you. The guide is a historical document. You've arrived in the present.
|
||||
|
||||
**The test:** At a place where simulation has produced significant drift from the guide's description, the player should be able to identify the cause from observation alone — without asking an NPC, without reading a newspaper. The space should tell the story.
|
||||
|
||||
When the gap is discovered through NPC conversation rather than observation, it's still good — "used to be different, before the transit strike," "the neighborhood changed when the Institute set up the monitoring station" — but spatial legibility is the gold standard. Space outlasts memory.
|
||||
|
||||
---
|
||||
|
||||
## 4. Environmental Archaeology from Simulation Events
|
||||
|
||||
There is no fabricated history. What the player finds was produced by the simulation. This means every piece of evidence is true.
|
||||
|
||||
**What they find:**
|
||||
|
||||
A memorial near a refinery access corridor. Fresh flowers. Someone left them recently. The memorial is three years old, but the grief is current. If the player asks: there was an accident. Real. Named. The simulation produced it. The NPCs who work here knew the person.
|
||||
|
||||
A half-completed building, construction abandoned mid-frame. The permits are still posted, dated two years back. The company that was building it dissolved — economic pressure, corporate restructuring, the regional downturn that followed the portal disruption three systems over. The building is an artifact of a specific economic moment. The city built around it anyway.
|
||||
|
||||
A bar that's been operating under four different names in the last decade. The signs are all slightly different vintage. The current owner bought it at a discount during the faltering period. The fixtures are old — the original owner's taste, Commonwealth-style, uncomfortable chairs, low lighting, close seating. The current owner hasn't changed them because it would cost money. But the current clientele is different, and the dissonance between the inherited space and the current use is its own kind of archaeology.
|
||||
|
||||
**What the player feels:**
|
||||
|
||||
The first time they find something and ask about it and get the REAL story — not flavor text, not a canned response, but an NPC who actually knows because it actually happened — the game changes for them. The world didn't look inhabited. It IS inhabited. The rubble is real rubble. The memorial is a real memorial. The simulation has been running, and it left these marks.
|
||||
|
||||
Quiet places have social archaeology even when they have no event archaeology. A bar that's never had an explosion still has: the regulars who know each other, the history between the bartender and the woman in the corner, the group that used to meet here before two of them had a falling out, the prices that haven't changed in four years because the owner is risk-averse. Social archaeology is generated continuously. It's always there.
|
||||
|
||||
---
|
||||
|
||||
## 5. The NPC-Driven Generation Moment
|
||||
|
||||
You've been traveling with someone. Not a named companion with authored dialogue — a generated person you kept running into, or a relationship that built across multiple sessions of the same region. They became a person to you across ordinary interactions. They mentioned home.
|
||||
|
||||
You can go there.
|
||||
|
||||
You arrive at their system. Their neighborhood generates from their data — their cultural background, their family's economic situation, their relationship network. The streets have the character you'd expect from everything you know about them. The building proportions, the spatial grammar of their home district, the density of the neighborhood — it fits. Not because the generator made something beautiful. Because it was made from them.
|
||||
|
||||
You find their family's address. It exists. You can knock.
|
||||
|
||||
This is invisible to you as a player. You don't see a notification saying "this neighborhood was generated because of your relationship with Sela." It just exists. It was always going to be here — every system always existed in the wiki, every district always had the shape that its cultural and economic data would produce. You happened to go here because Sela told you about it. The place has the character it has because of what Sela is. You feel the fit without knowing why.
|
||||
|
||||
That's the magic. The simulation made the world real before you arrived. Your relationship with Sela told you where to look.
|
||||
|
||||
**The related case — news-driven generation:** A Reach-wide news ticker reports a gas main explosion in a settlement three systems over. You can go there. It exists. When you arrive, the rubble is real — the simulation produced the explosion, the news reported it, the generator built the town so it could be visited. The news is the simulation's letter to the player: *this happened somewhere real. Go see.*
|
||||
|
||||
---
|
||||
|
||||
## 6. Return Visits
|
||||
|
||||
You come back somewhere you've been.
|
||||
|
||||
**What's changed:**
|
||||
|
||||
People have moved. The dock supervisor who knew you has transferred to another posting. Her replacement is newer, doesn't know you. You get a standard reception. But someone in the bar remembers you from last time, introduces you to the new supervisor as "someone worth talking to." Social capital persists in relationship networks, not in the protagonist's fame stat.
|
||||
|
||||
The neighborhood has aged. Construction completed on the building that was a frame last time. Or: the construction is still abandoned, and the ground has grown around it, and it's become a permanent fixture of the skyline. The simulation decided, in your absence.
|
||||
|
||||
The economy has moved. The trade route you helped establish is producing results — or failing, if the pressures went the wrong way. You can see which one.
|
||||
|
||||
**What the player feels:**
|
||||
|
||||
"The world ran while I was gone." This is the essential thing. Not "things changed because I did something" (though sometimes that's also true). But the primary feeling is: I was gone, and time passed, and the world didn't wait for me. That's a living world. That's the feeling.
|
||||
|
||||
**Consequence echo:**
|
||||
|
||||
When the player has done something here — economically, relationally, physically — the world has reacted in proportion. Not "you're famous." Proportional. A favor you did for someone three sessions ago propagated out one hop into their network. Someone who knows someone you helped greets you differently. The consequence is local, specific, traceable to what you actually did.
|
||||
|
||||
"I heard about what you did at the refinery." You know exactly what they're talking about. You were there.
|
||||
|
||||
---
|
||||
|
||||
## 7. The Scale Drop
|
||||
|
||||
The scale drop is not a single moment. It's a register — a feeling that can arrive from multiple directions simultaneously. When it arrives fully, the player understands what kind of game they're in.
|
||||
|
||||
**The physical drop:** The player is at a high vantage point. Maybe the port district overlooks the settlement below. Maybe the orbital view during smuggler-route arrival showed the city's actual size against the geography. The city is smaller than the mountains. The mountains are smaller than the planet. The planet is a dot in the GTTR screenshot. They are in one district, of one settlement, on one moon, in one system, in one cluster of the 300.
|
||||
|
||||
**The social drop:** Someone mentions a journey to a place the player has been treating as "nearby." A week on the ship. The player recalibrates. The distances are real. The economics of travel are real. The fact that this NPC has been in this system for three years without leaving is not apathy — it's the reality of the distances.
|
||||
|
||||
**The navigational drop:** The player opens their insert and looks at the galaxy map. They find their current system. They zoom out. They look at how far they are from where they started. They look at how many systems they've visited and how many they haven't. The map makes them small. Not as a humiliation — as a gift. The universe is big enough to get lost in.
|
||||
|
||||
The best version of the scale drop is when all three registers arrive at once: you're standing at a port overlook, and someone next to you mentions their sister has been waiting three months for the next charter, and you open your insert to check the route and see the full map and notice how small the cluster you've been treating as your whole world actually is.
|
||||
|
||||
That's when the player understands where they are. One person, in a place that extends in every direction, lived-in by millions of generated people who each have their own reasons for being where they are.
|
||||
|
||||
That's the game.
|
||||
|
||||
---
|
||||
|
||||
## Summary: The Seven Beats
|
||||
|
||||
| Beat | What happens | What the player feels |
|
||||
|---|---|---|
|
||||
| Galaxy map | 300 named, storied dots, full info, readable signal | Anticipation — a universe worth exploring |
|
||||
| GTTR arrival | Warm arrival through scouting window + contextual landing | Expectation formed, then tested against reality |
|
||||
| GTTR-as-contract | Guide was true then; simulation has moved | History — legible gap between past and present |
|
||||
| Environmental archaeology | Real simulation traces, social + event | This world is real. Someone was actually here. |
|
||||
| NPC-driven generation | Visiting where your person is from | Wonder — the simulation knew them before you did |
|
||||
| Return visits | NPC drift + consequence echo | Time passed. The world ran without me. |
|
||||
| Scale drop | Physical + social + navigational registers | One person. An enormous place. Worth exploring. |
|
||||
|
||||
The thread: **the universe is worth exploring because it was already real before you arrived.** The simulation built it. The wiki wrote its history. The NPCs have been living in it. You show up, and you find it — not as a tourist finding a designed attraction, but as a traveler finding an existing place.
|
||||
|
||||
That's the experience. That's what the generator has to produce.
|
||||
@@ -0,0 +1,120 @@
|
||||
# SW1 Interview Answers — Product Owner Decisions
|
||||
|
||||
**Date:** 2026-03-24
|
||||
**Interviewer:** Team Lead
|
||||
**Product Owner:** Jeroen
|
||||
|
||||
---
|
||||
|
||||
## Galaxy Level
|
||||
|
||||
**Q: Are the 300 systems fixed across playthroughs?**
|
||||
A: **Fixed galaxy, seeded drama.** Same 300+1 (Earth border-locked) systems, same wormhole routes. Internal economic/political state drifts via background simulation.
|
||||
|
||||
**Q: Cultural geography framework?**
|
||||
A: The 7 abstract heritage roots (Frost/Stone/Tide/Vine/Dust/Iron/Salt) are **deprecated** as generator inputs. The wiki was written using real-world cultural migration corridors — Commonwealth (North), Iberian/Latin American + Southern African (South), East Asian + South/Southeast Asian (East), Northern/Central European (West) — per `docs/design/cultural-migration-pressure.md`. The wave model is the backstory explanation, but per-system cultural data is already authored in the 301 wiki entries and systems.db.
|
||||
|
||||
**D-records D-104 and D-105 (heritage root grammar overlays) are STALE and need supersession.**
|
||||
|
||||
**Q: Galaxy map feel?**
|
||||
A: **Full information from start.** Inserts logically contain a 300-system star chart. No fog on the galaxy level.
|
||||
|
||||
---
|
||||
|
||||
## System / Location Profiles
|
||||
|
||||
**Q: How are per-planet/station/moon profiles populated?**
|
||||
A: **Extend the wiki.** Author per-planet profiles as wiki content for all systems. The generator reads from authored data, doesn't generate profiles.
|
||||
|
||||
**Q: Economic depth of system profiles?**
|
||||
A: **Full economic profile** (endgame target). Multiple industries, power players, historical disruptions. Every economic axis must cascade visibly to at least district and room level.
|
||||
|
||||
**Q: Settlement replayability?**
|
||||
A: NOT seed-based variation. Every run starts from the same wiki-authored canonical state. **Background simulation** (economic + sociological pressures on spare CPU cores) produces drift over time. Replayability comes from simulation trajectory differences, not seed differences. By the time the player reaches a location the second time, pressures will have changed things. Local painting algorithms work from the current situation, not a static seed.
|
||||
|
||||
---
|
||||
|
||||
## Topography
|
||||
|
||||
**Q: How deeply does topography constrain generation?**
|
||||
A: **Hard constraint.** Mountains block corridors, rivers create district boundaries, coastlines produce port districts. Geography creates spatial reasoning the player can exploit.
|
||||
|
||||
**Q: How are world maps created?**
|
||||
A: **Authored world maps for all planets and moons.** Topography is authored, not procedurally generated.
|
||||
|
||||
**Q: Does cultural heritage shape settlement topology?**
|
||||
A: **Historical layering yes, but NOT along the 7 heritage root axes.** The cultural axes that matter are the real-world corridor identities from the cultural-migration-pressure document. First cultural wave takes preferred terrain, later waves adapt.
|
||||
|
||||
---
|
||||
|
||||
## Arrival
|
||||
|
||||
**Q: What does the player see on arrival?**
|
||||
A: **Contextual by travel method.** Charter flight = port arrival. Gate transit = station interior. Smuggler route = low orbit in the dark. Orbital view is the default for normal transit.
|
||||
|
||||
**Q: Is arrival a scouting window?**
|
||||
A: **Yes — made diegetic.** An insert context window opens with system stats, a planetary screenshot, and the GTTR (Guide to the Reach) entry. The GTTR entry (already authored narrative) gets enhanced with statistics and art. Information asymmetry starts at arrival.
|
||||
|
||||
---
|
||||
|
||||
## Background Simulation & Content Spidering
|
||||
|
||||
**Q: Does the world live before the player arrives?**
|
||||
A: **Yes.** Full economic + social + political background simulation. Needs its own dedicated design workshop.
|
||||
|
||||
**Q: Environmental archaeology?**
|
||||
A: **Only from real simulation events.** No fabricated history. If there's rubble, the simulation produced the explosion. If there's a memorial, someone died in the simulation. Integrity preserved.
|
||||
|
||||
**Q: Generation hooks?**
|
||||
A: Two key hook types:
|
||||
1. **NPC-driven generation:** Meet someone from a distant planet (more than casually) → their house, family, friends, neighborhood get generated at that location. Their address becomes a real visitable place.
|
||||
2. **News-driven generation:** Reach-wide news reports events (gas main explosion in an east_reach town). That location must exist when visited. Sparse frequency to avoid disruption.
|
||||
|
||||
**Q: CPU load?**
|
||||
A: **Capped idle-time generation.** Background sim runs at capped load. Player's system stays quiet — no full-fan-blazing.
|
||||
|
||||
---
|
||||
|
||||
## Generated Spaces
|
||||
|
||||
**Q: Are rooms simulation primitives or visual backdrops?**
|
||||
A: **Full simulation primitives with LOD.** A visited bar needs: monthly turnover, cost, employee count, current staff and visitors. If the player BUYS the bar, deeper simulation activates. Economic success follows regional prosperity (prosperous/faltering/growing/stable). Depth scales with player engagement.
|
||||
|
||||
**Q: How do NPCs populate spaces?**
|
||||
A: **Hybrid with evolution.** Zone-function baselines (commercial zones get foot traffic). Any auto-generated ambient NPC can evolve into a narrative NPC through player interaction. No hard line between background and story characters.
|
||||
|
||||
---
|
||||
|
||||
## Spatial Design Principles
|
||||
|
||||
**Q: Do era transitions leave visible spatial scars?**
|
||||
A: **Context-dependent.** Sometimes spatial archaeology (when people wanted a clean break). Sometimes people keep building what they built. Dramatic shifts bias toward change. Sometimes people start building differently because of culture or taste. **Key principle: cohesion at small/middle scale (not messy), variety at middle/large scale (not predictable).**
|
||||
|
||||
---
|
||||
|
||||
---
|
||||
|
||||
## Round 2 Follow-up Answers
|
||||
|
||||
**Q: World map format?**
|
||||
A: **Annotated heightmaps** (grayscale heightmap PNG + metadata JSON per planet/moon, with rivers/coastlines/biome zones as overlay layers). Additionally, use a **planetary shader plugin** to generate visual screenshots of each planet (earthlike, jungle, desert, mars-like, ocean, etc.) for embedding in wiki pages and GTTR entries.
|
||||
|
||||
**Q: Heritage root D-records (D-104, D-105, D-101, D-107)?**
|
||||
A: **Superseded — clean break.** The 7 abstract roots are retired. New D-records will describe how real-world corridor identities (Commonwealth, Iberian/Latin American, East Asian, Germanic) map to room grammar, spatial tokens, and NPC behavior.
|
||||
|
||||
**Q: Simulation convergence / replayability?**
|
||||
A: **Reframed.** Three key points:
|
||||
|
||||
1. **Player agency is the primary replayability lever.** Who you create, what you do, where you go across 300+ systems already provides massive variety. The background sim is secondary variety, not the core mechanism.
|
||||
|
||||
2. **Equilibrium is signal, not failure.** A stable economy shows the effect of the player's choices (or non-choices). That's information, not boredom.
|
||||
|
||||
3. **The interconnected network IS the propagation mechanism.** Any event that tweaks core dials on any system — corporate disaster, portal closing, political shift, successful development effort — propagates and rebalances through the trade/political network. Corporate disasters are ONE entropy source, not THE entropy source. Bulk import/export lists per system inform both simulation (trade flows) and content (what's on store shelves). Set up the propagation properly and emergence follows naturally.
|
||||
|
||||
---
|
||||
|
||||
## Process Notes
|
||||
|
||||
- Zone type families (Interior/Urban/Natural) are implementation detail for sub-workshop 2, not endgame feature decisions.
|
||||
- The background simulation system needs its own dedicated design workshop. Design brief: model bulk trade flows between systems with corporate facility dependencies, political pressure, and disaster injection. Central challenge is not "keep it chaotic" but "set up propagation properly."
|
||||
- Heritage root D-records (D-104, D-105, D-101, D-107) superseded — flagged for Qatux.
|
||||
@@ -0,0 +1,298 @@
|
||||
---
|
||||
title: "SW1 Round 1 — Consolidated Notes"
|
||||
author: qatux
|
||||
workshop: world-generation
|
||||
sub-workshop: 1
|
||||
round: 1
|
||||
created: 2026-03-24
|
||||
status: ready-for-review
|
||||
---
|
||||
|
||||
# SW1 Round 1 — Consolidated Notes
|
||||
|
||||
**Prepared by:** Qatux
|
||||
**Source files:** gestalt-sw1r1.md, miri-sw1r1.md, nigel-sw1r1.md, ozzie-sw1r1.md, tyre-sw1r1.md
|
||||
**Date:** 2026-03-24
|
||||
|
||||
---
|
||||
|
||||
## ⚠️ CRITICAL FLAG: Station-Only Recommendations
|
||||
|
||||
**Both Gestalt (Q4) and Tyre (Q1) independently recommend station-only scope for v0.2.**
|
||||
|
||||
> Gestalt: "Recommendation: A (station only) with explicit deferral of everything else."
|
||||
> Tyre: "My recommendation: Option A for v0.2 core, with Urban as a fast-follow."
|
||||
|
||||
The product owner has explicitly rejected this framing as a cop-out that avoids the hard questions. The workshop must address how **one pipeline handles all 5 zone types**, not whether to defer 4 of them.
|
||||
|
||||
This is the primary tension Round 2 must resolve. Every recommendation below that depends on "station only scope" should be read with this flag in mind. Gestalt's systems questions and Tyre's architecture questions remain valid — the scope assumption underneath them does not.
|
||||
|
||||
---
|
||||
|
||||
## Summary of All Questions by Theme
|
||||
|
||||
25 questions total across 5 agents. Grouped into 6 thematic areas below.
|
||||
|
||||
---
|
||||
|
||||
### Theme 1: Zone Scope — Which Zone Types and When
|
||||
|
||||
*The most architecturally load-bearing set of questions. Two agents recommend station-only (flagged above).*
|
||||
|
||||
| Question | Agent | Recommendation |
|
||||
|---|---|---|
|
||||
| What SettingType(s) ship in v0.2? | Tyre Q1 | ⚠️ Station only (flagged) |
|
||||
| What zone types does v0.2 actually need to generate? | Gestalt Q4 | ⚠️ Station only (flagged) |
|
||||
| What is the replayability floor — what MUST be different every run? | Nigel Q4 | Zone arrangement + triangle topology + NPC identity (C) |
|
||||
|
||||
**Convergence:** Gestalt and Tyre reach the same station-only conclusion from different directions — Gestalt from scope risk ("5 half-working zone types"), Tyre from implementation cost ("each SettingType is essentially a separate generator"). The convergence makes this a substantive recommendation, not a coincidence.
|
||||
|
||||
**The hard question for Round 2:** Given that station-only is not acceptable, what does a single pipeline look like that handles all 5 zone types at different fidelity levels? Tyre's cost table (Station: 2–3 weeks; +Urban: 4–6 weeks total; +Wilderness: 7–10 weeks) is the starting point for negotiating a multi-zone path.
|
||||
|
||||
---
|
||||
|
||||
### Theme 2: Generator Algorithm and Pipeline Architecture
|
||||
|
||||
*Tyre-heavy. Most questions have clear technical recommendations with little disagreement.*
|
||||
|
||||
| Question | Agent | Recommendation |
|
||||
|---|---|---|
|
||||
| What building/room generation algorithm? | Tyre Q2 | BSP + template stamping for special rooms (B) |
|
||||
| 2D TileMapLayer → 3D migration — when? | Tyre Q3 | Generate 3D-ready data now, keep 2D renderer temporarily (C) |
|
||||
| How detailed is Phase 2 chunk fill in v0.2? | Tyre Q4 | Walls + floors + doors + basic objects (B) |
|
||||
| Full Phase 1 skeleton or simplified bootstrap? | Tyre Q5 | Simplified random block assignment, guarantee audit as warning-only (B) |
|
||||
|
||||
**Convergence:** No agent disputes Tyre's algorithm recommendations. BSP determinism aligns with D-010 requirements. Tyre's "generate 3D-ready data, render 2D temporarily" approach (Q3) is elegant — it decouples generation from rendering and avoids double work.
|
||||
|
||||
**Tension:** Tyre's Phase 1 recommendation (simplified, no guarantees) creates potential friction with Nigel's replayability floor (zone arrangement must differ visibly per run). A guarantee-free Phase 1 may not produce the zone cluster variety Nigel requires. Flagged for Round 2.
|
||||
|
||||
---
|
||||
|
||||
### Theme 3: Cultural Identity in Generation
|
||||
|
||||
*Miri-heavy. Requires an upstream product decision before authoring can begin.*
|
||||
|
||||
| Question | Agent | Recommendation |
|
||||
|---|---|---|
|
||||
| How many heritage roots to author for v0.2? | Miri Q1 | Roots present in starting district blend only (B) |
|
||||
| Does heritage influence Phase 1 layout or Phase 2 surface only? | Miri Q2 | Lightweight Phase 1 numeric targets per root (B) — extends D-104 |
|
||||
| How does cultural mixing work at district boundaries? | Miri Q3 | Junction archetypes for urban hubs (C), weighted blend for rural/wilderness (B) |
|
||||
| Does cultural naming use generative grammar or flat lists? | Miri Q4 | Grammar for infrastructure, lists for establishments (C) |
|
||||
| How does corridor position map to heritage root probability weights? | Miri Q5 | Corridor probability table (B) |
|
||||
|
||||
**Convergence:** Miri's Q2 (lightweight Phase 1 cultural targets) and Ozzie's Q1 (zone identity legible in 3 seconds) are solving the same problem from different angles. Miri argues for spatial-structural legibility; Ozzie argues for visual-architectural legibility. Both require cultural constraints to influence tile placement at generation time, not just surface materials. Ozzie's Q5 makes this explicit: "cultural fingerprint visible" is the #1 priority for screenshot moments.
|
||||
|
||||
**Upstream dependency flagged by Miri:** What is the heritage root blend of the starting district (Sova Transit / Van Maanen's Star)? This is a content decision, not a worldbuilding derivation. Without it, Q1, Q2, and Q3 authoring scope cannot be determined. Miri offers a working hypothesis (Iron/Stone blend with Tide undertow) but defers to Jeroen.
|
||||
|
||||
**Tension:** Miri's Phase 1 cultural targets (Q2 recommendation B) add parameters to the same Phase 1 block planning that Tyre is already calling a constraint-solving challenge. Tyre's Phase 1 assessment does not mention cultural parameters. This gap needs to be addressed — how do 2-3 numeric targets per heritage root interact with the guarantee tier system?
|
||||
|
||||
---
|
||||
|
||||
### Theme 4: Tycoon Integration and Economic Wiring
|
||||
|
||||
*Gestalt-heavy. These questions define what "functional" generation means for the core gameplay loop.*
|
||||
|
||||
| Question | Agent | Recommendation |
|
||||
|---|---|---|
|
||||
| What does a "functional" room need to provide for the tycoon loop? | Gestalt Q1 | Function-tagged (B) — rooms carry interaction-type flags, not full simulation |
|
||||
| How does the tycoon's starting business relate to generated space? | Gestalt Q2 | Guarantee-driven (B) — D-097 tier system ensures buyable commercial zone exists |
|
||||
| Do NPC schedules follow zone type or triangle assignment? | Gestalt Q3 | Hybrid (C) — zone baseline foot traffic + triangle override for key NPCs |
|
||||
| Does the player ever modify generated space? | Gestalt Q5 | Static for v0.2 (A), owned-premise modification as first post-v0.2 enhancement (B) |
|
||||
|
||||
**Convergence:** Gestalt Q3 (hybrid zone baseline + triangle override for NPCs) and Ozzie Q4 (zone baseline as foundation, time-of-day as simulation layer, narrative state as override) are structurally identical recommendations arrived at independently. Both agents want: ambient NPC behavior driven by zone type, narrative/story events override locally. This is a strong convergence — treat as near-settled.
|
||||
|
||||
**Note on Gestalt Q2:** Recommending the guarantee tier system (D-097) ensures a buyable commercial zone exists is a clean architectural solution. The product owner should confirm whether the guarantee system should be extended with this Tier 1 entry for v0.2.
|
||||
|
||||
---
|
||||
|
||||
### Theme 5: Replayability — What Must Differ Per Run
|
||||
|
||||
*Nigel-heavy. These questions set the acceptance criteria for the generator.*
|
||||
|
||||
| Question | Agent | Recommendation |
|
||||
|---|---|---|
|
||||
| Is the world per-run or persistent? | Nigel Q1 | Per-save persistent (B) — world fixed within save, new game = new seed |
|
||||
| Is spatial anti-metagaming structural or social? | Nigel Q2 | Cultural templates constrain, seed randomizes within (D) |
|
||||
| Does social site adjacency vary per seed? | Nigel Q3 | Zone clusters vary per seed within cultural constraints (C) |
|
||||
| What's the replayability floor for v0.2? | Nigel Q4 | Zone arrangement + triangle topology + NPC identity (C) |
|
||||
| How much does era layering contribute to variety? | Nigel Q5 | Era mix seeded per district + weighted by world economic state (B+C) |
|
||||
|
||||
**Note on Nigel Q1 (per-run vs persistent):** This is architecturally load-bearing for save file design and is uncontested — no other agent addresses it. Needs product owner confirmation before implementation begins.
|
||||
|
||||
**Tension with Tyre Q5:** Nigel's replayability floor (Q4, option C) requires zone cluster adjacency to differ visibly. Tyre's Phase 1 recommendation (Q5, option B — simplified, no guarantees) may produce skeletons where zone arrangement is too similar between seeds. Specifically: if Phase 1 is "random block assignment" without guidance, cultural templates can't constrain the arrangement (Nigel Q2 rec D). These two recommendations are in latent conflict.
|
||||
|
||||
**Nigel Q2 is aligned with Miri Q2:** Nigel wants cultural templates to constrain spatial arrangement while seed randomizes within. Miri wants lightweight Phase 1 numeric targets per heritage root. These are the same architectural request from different angles — Nigel from replayability, Miri from cultural legibility.
|
||||
|
||||
---
|
||||
|
||||
### Theme 6: Spatial Experience and Sense of Place
|
||||
|
||||
*Ozzie-heavy. These questions define the experiential quality bar for generated spaces.*
|
||||
|
||||
| Question | Agent | Recommendation |
|
||||
|---|---|---|
|
||||
| Does zone type communicate visually in 3 seconds? | Ozzie Q1 | Distinct architectural vocabulary per zone (C), cultural layer later (D) |
|
||||
| Does exploration feel like discovery or corridor management? | Ozzie Q2 | Zone anchor landmark (C) + dead ends earn their keep (D) |
|
||||
| How visible are upper floors / z-levels? | Ozzie Q3 | External building silhouette (B) for MVP, cutaway fade (C) as premium |
|
||||
| What NPC density makes a space feel inhabited? | Ozzie Q4 | Zone baselines (B) + time-of-day rhythm (C) + narrative state override (D) |
|
||||
| Can we design screenshot moments deliberately? | Ozzie Q5 | Cultural fingerprint (C) > environmental story clusters (D) > scale contrast (B) |
|
||||
|
||||
**Convergence:** Ozzie's Q1 (3-second zone legibility via distinct architectural vocabulary) and Miri's Q2 (heritage root at Phase 1) are the same architectural requirement stated from experience (Ozzie) and systems (Miri) perspectives. Architectural vocabulary IS cultural heritage made spatial. These should be treated as one design requirement.
|
||||
|
||||
**Ozzie Q3 note:** Upper floor silhouette (B) is called out as a cheap but high-impact visual — "you're walking through a narrow corridor and there's a 6-storey block above you." This aligns with D-148 (30° Camera3D) giving visibility of building fronts and height. No other agent addresses z-level visual treatment, so this is Ozzie's uncontested recommendation.
|
||||
|
||||
---
|
||||
|
||||
## Convergence Map
|
||||
|
||||
Where multiple agents independently reached the same conclusion:
|
||||
|
||||
| Topic | Agents | Shared Conclusion |
|
||||
|---|---|---|
|
||||
| Station-only for v0.2 | Gestalt, Tyre | ⚠️ FLAGGED — both recommend, both wrong per PO |
|
||||
| Zone baseline as NPC behavior foundation | Gestalt Q3, Ozzie Q4 | Ambient foot traffic = zone type; narrative overrides locally |
|
||||
| Cultural identity must be spatially expressed | Miri Q2, Ozzie Q1, Ozzie Q5 | Architecture must carry heritage, not just surface materials |
|
||||
| Cultural templates constrain, seed randomizes within | Nigel Q2, Miri Q2 | Same architectural request: heritage in Phase 1, not just Phase 2 |
|
||||
| Generate 3D-ready data now | Tyre Q3 | No other agent disputes; aligns with D-148/D-149 direction |
|
||||
|
||||
---
|
||||
|
||||
## Tensions Map
|
||||
|
||||
Where agents disagree or produce incompatible recommendations:
|
||||
|
||||
| Tension | Agents | Description |
|
||||
|---|---|---|
|
||||
| Zone scope vs product owner | Gestalt Q4, Tyre Q1 vs Jeroen | Station-only vs all 5 zone types — must be resolved in Round 2 |
|
||||
| Phase 1 simplicity vs Phase 1 cultural parameters | Tyre Q5, Miri Q2 | Tyre wants minimal Phase 1; Miri wants cultural numeric targets in Phase 1 — additive but uncosted |
|
||||
| Phase 1 simplicity vs replayability floor | Tyre Q5, Nigel Q4 | Guarantee-free Phase 1 may not produce zone variety Nigel requires |
|
||||
|
||||
---
|
||||
|
||||
## Tyre's Feasibility Cheat Sheet — Summary
|
||||
|
||||
### What's Already Built
|
||||
- `DistrictSkeleton` full type hierarchy (579 lines) in `server/src/simulation/generator.rs`
|
||||
- Chunk streaming with load/unload at `chunk_streaming.rs`
|
||||
- Movement + walkability (`WalkabilityMap`, `TileKind`, `ChunkCoord` with z)
|
||||
- Tile renderer (placeholder — colored rectangles)
|
||||
- Dual-scale grid (0.5m sim / 1m visual, D-066)
|
||||
- 3D camera (D-148) and 3D character system (D-149, Sprint 28)
|
||||
|
||||
### What Needs to Be Built (not stubbed)
|
||||
- Phase 1 generation algorithm (no logic exists — only output shape)
|
||||
- Phase 2 chunk fill (tile-level fill logic)
|
||||
- ZonePalette data and heritage→material mapping
|
||||
- GuaranteeAuditResult (stub string)
|
||||
- MobileChunk structs (D-108)
|
||||
|
||||
### Cost Tiers
|
||||
| Feature | Effort |
|
||||
|---|---|
|
||||
| Template-stamped room generator | 2–3 days |
|
||||
| Corridor carving between rooms | 1–2 days |
|
||||
| Tile palette → 3D mesh mapping | 2–3 days |
|
||||
| Single-z-level GridMap rendering | 2–3 days |
|
||||
| BSP room layout | 2 weeks |
|
||||
| Full Phase 1 with Tier 1 guarantees | 3–4 weeks |
|
||||
| WFC or grammar-based interiors | 2–3 weeks |
|
||||
| Multi-z-level cutaway rendering | 2–3 weeks |
|
||||
| Organic layout mode | 1–2 weeks |
|
||||
| Full ZonePalette with cultural modifiers | 2–3 weeks (asset-dominated) |
|
||||
| 2D→3D renderer migration | 2–4 weeks (in progress) |
|
||||
|
||||
### Reference Implementations — Priority
|
||||
- **CityCrafter3D** — HIGH (study algorithm, not code; server-side)
|
||||
- **GridMapLayer** — HIGH (client rendering upgrade path)
|
||||
- **Chunk Manager, RetroTerrain, PathMesh3D** — MEDIUM (specific techniques)
|
||||
- **Spatial Gardener, DeformableMesh, SunshineClouds** — LOW (future)
|
||||
|
||||
---
|
||||
|
||||
## Proposed Interview Clusters for Product Owner
|
||||
|
||||
The 25 questions across 5 agents can be consolidated into **6 interview clusters**. Within each cluster, questions share the same product-level decision.
|
||||
|
||||
---
|
||||
|
||||
### Cluster A: Zone Scope — The Pipeline Question
|
||||
|
||||
*Pre-requisite for everything else. Cannot proceed without an answer.*
|
||||
|
||||
1. **All 5 zone types are in scope for v0.2. Given Tyre's cost estimates (station 2–3 weeks, station+urban 4–6 weeks, station+urban+wilderness 7–10 weeks), what is the v0.2 zone scope?** The question is not "station only vs not" — it's "which multi-zone path and at what fidelity?"
|
||||
2. **What does "minimum viable multi-zone" look like?** Is it: one zone fully working + four zones as spatial stubs that prove the pipeline handles them? Or all five at equal depth?
|
||||
|
||||
*Sources: Gestalt Q4, Tyre Q1. Flagged per PO direction.*
|
||||
|
||||
---
|
||||
|
||||
### Cluster B: Starting Location — The Content Unlock
|
||||
|
||||
*Pre-requisite for authoring work (heritage roots, naming, cultural identity).*
|
||||
|
||||
3. **What is the heritage root blend of the starting district (Sova Transit / Van Maanen's Star)?** Miri's working hypothesis: Iron/Stone blend with Tide undertow. PO confirmation needed.
|
||||
4. **Is Van Maanen's Star a station/port or does it have accessible exterior zones?** Affects whether the tycoon's starting experience is interior-only or includes urban/industrial context.
|
||||
|
||||
*Sources: Miri upstream dependency, Gestalt Q4, Tyre Q1.*
|
||||
|
||||
---
|
||||
|
||||
### Cluster C: Cultural Identity in Architecture
|
||||
|
||||
*Informs Phase 1 architecture and authoring scope.*
|
||||
|
||||
5. **Does heritage root influence spatial geometry (Phase 1 layout targets) or only surface materials (Phase 2)?** Miri recommends lightweight Phase 1 numeric targets; Tyre's Phase 1 assessment doesn't include them. Adding them is low cost but needs confirmation.
|
||||
6. **How do cultural boundaries work at district edges?** Junction archetypes for urban hubs (Miri rec C) vs weighted blends (Miri rec B) vs hard cuts.
|
||||
7. **Corridor position → heritage root — hand-authored per system or derived from corridor probability table?** Miri recommends a one-time corridor table (B) enabling procedural heritage assignment anywhere in the Reach.
|
||||
|
||||
*Sources: Miri Q1, Q2, Q3, Q5.*
|
||||
|
||||
---
|
||||
|
||||
### Cluster D: Tycoon Wiring and NPC Behavior
|
||||
|
||||
*Determines what "functional space" means and how NPCs populate it.*
|
||||
|
||||
8. **Are generated rooms cosmetic (art), function-tagged (interaction flags), or fully simulated (demand curves)?** Gestalt recommends B (function-tagged) as the v0.2 minimum. This is the crux question — it determines whether generated spaces are art assets or simulation primitives.
|
||||
9. **How does the tycoon's starting business connect to generated space?** Guarantee tier system ensures buyable commercial zone (Gestalt rec B), or tycoon just picks from what spawns?
|
||||
10. **Do NPC schedules follow zone function, triangle assignment, or both?** Gestalt and Ozzie independently recommend the hybrid: zone baseline + triangle override.
|
||||
|
||||
*Sources: Gestalt Q1, Q2, Q3; Ozzie Q4.*
|
||||
|
||||
---
|
||||
|
||||
### Cluster E: Replayability Floor
|
||||
|
||||
*Sets acceptance criteria for the generator — what "working" means.*
|
||||
|
||||
11. **Is the world per-save persistent or does it regenerate per run?** Nigel recommends per-save persistent (B). Architecturally load-bearing for save design. Currently uncontested.
|
||||
12. **What is the minimum run-to-run difference for v0.2?** Nigel recommends C: zone arrangement + triangle topology + NPC identity all differ. This sets the acceptance test for the generator spike.
|
||||
13. **Does era layering (CorporateMerger, OrganicGrowth, etc.) contribute to run-to-run variety?** Nigel recommends seeding era distributions per district + weighting by world economic state. Cheap lever, high return.
|
||||
|
||||
*Sources: Nigel Q1, Q4, Q5.*
|
||||
|
||||
---
|
||||
|
||||
### Cluster F: Spatial Experience Quality Bar
|
||||
|
||||
*Defines what "feels like a place" means — experiential acceptance criteria.*
|
||||
|
||||
14. **Can a player identify zone type from visual shape alone in 3 seconds?** Requires distinct architectural vocabulary per zone type (not just different tile colors). Ozzie Q1, aligned with Miri Q2.
|
||||
15. **Does every location have one "money shot" — a zone anchor landmark the player will encounter?** Ozzie Q2 recommendation C. Low implementation cost, high perceptual impact.
|
||||
16. **Are upper floors visible as building mass above the player?** External silhouette without revealing interiors (Ozzie Q3, option B). Cheap, communicates scale and habitation.
|
||||
|
||||
*Sources: Ozzie Q1, Q2, Q3, Q5.*
|
||||
|
||||
---
|
||||
|
||||
## Open Questions Not Yet Addressed
|
||||
|
||||
The following questions were raised by agents but have no current recommendation to evaluate — they represent gaps in the current knowledge base:
|
||||
|
||||
- **Q-??**: How does the server-side generator handle exterior terrain height variation (for rural/wilderness zones)? Tyre's cheat sheet notes RetroTerrain crashes at 1000×1000 with no chunking — no recommendation exists for terrain generation algorithm.
|
||||
- **Q-??**: What is the wire format for transmitting large generated worlds? Tyre flagged this as a protocol optimization (~1 day) but it's unaddressed. Should it be scoped into v0.2?
|
||||
- **Q-??**: Does `MobileChunk` (D-108) enter v0.2 scope? Tyre lists it as "stubbed, needs implementation" but no agent has scoped the work.
|
||||
|
||||
---
|
||||
|
||||
*Notes produced by Qatux from 5 agent outputs. Round 2 design deferred pending product owner review of these clusters.*
|
||||
@@ -0,0 +1,436 @@
|
||||
---
|
||||
title: "SW1 Round 1b — Consolidated Notes (Endgame Vision)"
|
||||
author: qatux
|
||||
workshop: world-generation
|
||||
sub-workshop: 1
|
||||
round: 1b
|
||||
created: 2026-03-24
|
||||
status: ready-for-review
|
||||
supersedes: sw1-round1-notes.md (for scope framing)
|
||||
---
|
||||
|
||||
# SW1 Round 1b — Consolidated Notes
|
||||
|
||||
**Prepared by:** Qatux
|
||||
**Source files:** gestalt-sw1r1b.md, miri-sw1r1b.md, nigel-sw1r1b.md, ozzie-sw1r1b.md, tyre-sw1r1b.md
|
||||
**Date:** 2026-03-24
|
||||
**Framing:** Endgame vision. No v0.2 scope constraints. Station-only concern is resolved by this round — see Pipeline Architecture section.
|
||||
|
||||
---
|
||||
|
||||
## ⚠️ STALENESS ALERT: Heritage Root D-Records vs. Actual World Content
|
||||
|
||||
**Flagged by team lead during workshop. Requires product owner resolution before cultural generation work proceeds.**
|
||||
|
||||
### What the D-records say
|
||||
|
||||
D-104, D-105, D-107, and D-101 (all from the Generator Architecture Workshop, 2026-02-27) build the cultural identity system around **7 abstract heritage roots**: Frost, Stone, Tide, Vine, Dust, Iron, Salt. These records define:
|
||||
|
||||
- D-104: Heritage Grammar Overlay — "visual grammar of a Frost community versus a Tide community must be apparent to the observant player without a label." Heritage overlay applied at Phase 2 chunk fill.
|
||||
- D-105: Non-Urban Informal Zone Typology — canonical mapping of informal zone types to heritage roots ("How you hide in a Frost community is architecturally different from how you hide in a Dust community").
|
||||
- D-107: Trauma Events — trauma amplifies the heritage root baseline (not transforms it).
|
||||
- D-101: ZonePalette — modifier axis A = heritage root.
|
||||
|
||||
### What the wiki and world content actually use
|
||||
|
||||
`docs/design/cultural-migration-pressure.md` (authored by Paula, 2026-03-14) — the governing reference for all 300 system wiki pages — defines cultural identity using **real-world cultural corridors**:
|
||||
|
||||
| Corridor | Primary cultural inflection |
|
||||
|---|---|
|
||||
| North reach | British Commonwealth diaspora (Australian, Canadian, South African, Indian, Nigerian) |
|
||||
| South reach | Iberian/Latin American (Portuguese, Spanish, Brazilian) + Southern African (Zulu, Afrikaans) |
|
||||
| East reach | East Asian and Southeast Asian (Chinese, Japanese, Korean, Vietnamese, Indonesian, Filipino) |
|
||||
| West reach | Northern/Central European (German, Scandinavian, Dutch, Polish, Czech) + Russian successor states |
|
||||
|
||||
The wiki pages for 300+ systems are authored against these corridors. The abstract 7-root system (Frost/Tide/etc) does not appear in `cultural-migration-pressure.md` or in wiki content.
|
||||
|
||||
### Why this is a conflict
|
||||
|
||||
The generator architecture (D-104, D-105) assumes cultural identity is expressed via 7 abstract roots that are spatially legible at a glance. The world content assumes cultural identity is expressed via real-world heritage corridors. These are different things.
|
||||
|
||||
An agent trying to implement "Frost community visual grammar" per D-104 has no mapping to actual world content — no system in `systems.db` or the wiki has a "Frost" heritage tag. An agent trying to express "Commonwealth heritage architecture" per `cultural-migration-pressure.md` has no D-record to reference.
|
||||
|
||||
D-128 ("culture implicit in starting location — Van Maanen's Star equals Van Maanen's Star culture") leaves this unresolved: it says culture derives from location, but does not specify whether Van Maanen's Star culture is described by an abstract root, a real-world corridor, or both.
|
||||
|
||||
Miri's Round 1b Q1 (wave chronology as the root authored input for cultural generation) implicitly assumes the real-world corridor model — her wave chronology maps to settlement patterns of real cultures, not to the 7 abstract roots.
|
||||
|
||||
### The three possible resolutions
|
||||
|
||||
**Option A — Abstract roots are a translation layer.** The 7 abstract roots are metaphors that map onto real-world cultural patterns. Iron = Commonwealth (institutional, procedural, labor-focused). Tide = Iberian/LatAm (relational, communal gathering). Frost = Northern European/Scandinavian (individual space, cold reserve). The D-records remain valid if the translation table is authored. This is Miri's implicit assumption in Round 1b.
|
||||
|
||||
**Option B — Abstract roots are superseded.** The real-world corridor system replaces the 7 abstract roots entirely. D-104, D-105, and related records need amendment to reference the corridor system. The generator produces Commonwealth-heritage visual grammar, not Frost-heritage grammar.
|
||||
|
||||
**Option C — Two parallel systems, different levels.** Abstract roots describe *social pattern* (gathering behavior, privacy norms, threshold character — Miri Q5 Layers 1 and 2). Real-world corridors describe *material culture* (naming conventions, architectural vocabulary, object selection — Miri Q5 Layer 3). The two systems operate at different levels of the cascade and don't conflict.
|
||||
|
||||
### D-records requiring attention
|
||||
|
||||
| Record | Status | Issue |
|
||||
|---|---|---|
|
||||
| D-104 (Heritage Grammar Overlay) | **Stale — needs amendment or supersession** | Built around 7 abstract roots; no mapping to actual world content |
|
||||
| D-105 (Non-Urban Informal Zone Typology) | **Stale — needs amendment** | Heritage root correlations reference Frost/Dust/etc; no link to corridor system |
|
||||
| D-107 (Trauma Events as EraModification) | **Cross-reference stale** | References D-104 as "heritage baseline" — inherits staleness |
|
||||
| D-101 (ZonePalette Modifier System) | **Potentially stale** | Modifier axis A = heritage root — which root framework? |
|
||||
|
||||
**No work should begin on heritage root authoring (Miri Q1, Round 1 recommendation B) until the product owner resolves which framework is canonical.**
|
||||
|
||||
---
|
||||
|
||||
## How This Round Differs from Round 1
|
||||
|
||||
Round 1 was inadvertently scoped to district/room level. Round 1b reframes to the full galaxy-to-room cascade. The pipeline has 8 levels:
|
||||
|
||||
```
|
||||
1. Galaxy — 300 systems, topology, cultural corridors
|
||||
2. System profile — wealth, governance, atmosphere, biomes, cultural identity
|
||||
3. Topography — terrain, terrain effect on settlement placement
|
||||
4. Arrival/Gateway — inbound experience at system and location
|
||||
5. Content spidering — how generation unfolds as the player moves
|
||||
6. Settlement — city/town/outpost placement, district composition
|
||||
7. District — neighborhood layout, Phase 1 + Phase 2 generation
|
||||
8. Room — interiors, furniture, cultural grammar at intimate scale
|
||||
```
|
||||
|
||||
All questions below are organized by the level they primarily address.
|
||||
|
||||
---
|
||||
|
||||
## Level 1: Galaxy
|
||||
|
||||
*Questions about what the galaxy itself is, how it's structured, and what it promises the player.*
|
||||
|
||||
| Agent | Question | Recommendation |
|
||||
|---|---|---|
|
||||
| Miri Q1 | Heritage roots — origin worlds with diffusion, or universal distribution with corridor weights? | **D+C**: Wave chronology (authored) → corridor cultural identity (derived) → heritage probability per system (generated) |
|
||||
| Nigel Q1 | Does the galaxy topology regenerate between runs? | **A**: Fixed canonical 300 systems, fixed wormhole topology. Internal state (faction control, economy, NPC triangles) seeded per run. |
|
||||
| Ozzie Q1 | Is the galaxy map a wonder or a menu? | **D**: Layered and unlockable — starts as bare geography + economics, faction and mystery layers unlock through play |
|
||||
| Ozzie Q5 | When does the player feel the scale for the first time? | **C+D**: Designed "you are here" zoom moment (camera pulls back to show how small you are) + NPC social scale texture (someone mentions a weeks-long journey to a place you treated as nearby) |
|
||||
|
||||
**Convergence — Fixed galaxy, seeded situation:**
|
||||
Nigel and Miri agree: the galaxy as a *place* should be canonical and learnable. What varies per run is the situation inside that fixed map. Nigel: "The Settled Reach as a place should be canonical and learnable. The replayability comes from the situation inside that fixed map." This framing resolves the galaxy-topology question cleanly.
|
||||
|
||||
**Convergence — Galaxy map as earned knowledge:**
|
||||
Ozzie's unlockable map layers and Nigel's fixed-topology-but-seeded-internal-state are the same design idea at different levels. The galaxy earns its scale through the player's experience, not through declaration. Neither agent advocates for "show everything at once."
|
||||
|
||||
**Upstream dependency:**
|
||||
Miri's recommendation (wave chronology → corridor identity → heritage probability) requires the wave chronology to be authored. This is a worldbuilding document, not a generator parameter — but it must exist before corridor cultural identities can be derived, and corridor identities must exist before per-system heritage weights can be generated. **The wave chronology is the root authored input for the entire cultural cascade.**
|
||||
|
||||
---
|
||||
|
||||
## Level 2: System Profile
|
||||
|
||||
*Questions about what a system is made of and what cascades from its profile downward.*
|
||||
|
||||
| Agent | Question | Recommendation |
|
||||
|---|---|---|
|
||||
| Gestalt Q1 | What are the economic axes of a system profile, and which cascade visibly? | **C** (full: multiple industries, power players, historical disruptions) as endgame; **B** (dual axis: aggregate wealth + wealth-holder) as minimum viable |
|
||||
| Miri Q2 | Does the physical environment modulate how heritage roots express themselves? | **C+D**: Continuous axis modulation (environment shifts heritage expression along numeric parameters) + tension markers when heritage is in conflict with environment |
|
||||
|
||||
**The cascade rule (from Gestalt):** Every economic axis on the system profile should produce 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, cut it — it's database weight.
|
||||
|
||||
**Miri's extension:** The same cascade principle applies to cultural identity. Heritage root + environment type = cultural register. This produces variety beyond 7 roots: same root, different environment, different expression. A Frost community on an ice world is consonant; a Frost community on a tropical world is in tension — and that tension is spatially legible (walls everywhere, shade corridors, territorial marking).
|
||||
|
||||
**Tension:** No other agent explicitly addresses the environment × heritage modulation. This is Miri's contribution alone. It's not contested but it introduces a continuous parameter system that needs costing at implementation time — see Tyre's Layer 2 assessment for the general approach.
|
||||
|
||||
---
|
||||
|
||||
## Level 3: Topography
|
||||
|
||||
*Questions about whether physical terrain shapes the world or merely decorates it.*
|
||||
|
||||
| Agent | Question | Recommendation |
|
||||
|---|---|---|
|
||||
| Gestalt Q2 | Does topography constrain settlement placement or decorate it? | **C**: Hard constraint — rivers create district boundaries, mountains block corridors, coastlines produce port districts automatically |
|
||||
| Nigel Q2 | Does regional topography cascade into settlement form? | **C** as principle, **D** as long-term target; **B** (resource-driven placement) as practical starting point |
|
||||
| Tyre Q2 | How deep does planetary topography go? | **A** (abstract tags) to start; **B** (noise-based regional heightmap ~1km resolution) as the enrichment that makes world maps meaningful |
|
||||
|
||||
**Strong convergence — topography as causal, not decorative:**
|
||||
Gestalt and Nigel reach the same conclusion from different angles. Gestalt: "Cosmetic topography produces no decisions." Nigel: "Geographic causality is the replayability multiplier that operates automatically." Both argue that if terrain determines settlement form, a single seed variation at the geographic tier cascades all the way to NPC relationships — without the generator explicitly engineering that variety.
|
||||
|
||||
**Tension — implementation depth:**
|
||||
Tyre's A (abstract tags) is sufficient for district generation at ground level. The 30° camera means the player never sees a heightmap — they see whether they're in a coastal, mountain, or plains environment, which is communicated by SettingType and palette. Gestalt and Nigel's *design principle* (topography as hard constraint) is universally agreed; Tyre is clarifying that the *minimum viable implementation* of that principle is tag-based, not heightmap-based. The design intent and the implementation path are compatible.
|
||||
|
||||
**When does the depth matter?** Tyre's assessment: B (noise heightmap) becomes valuable when a world map or minimap shows the region. "There's a mountain range to the west, a river delta to the south." This is a navigation/exploration feature, not a generation prerequisite. Ozzie's Q5 (scale drop moment) connects here — the "you are here" zoom works better with real geographic context visible at the regional level.
|
||||
|
||||
---
|
||||
|
||||
## Level 4: Arrival and Gateway
|
||||
|
||||
*Questions about the first impression of every new location — the moment that sets what a place will mean to the player.*
|
||||
|
||||
| Agent | Question | Recommendation |
|
||||
|---|---|---|
|
||||
| Gestalt Q3 | What does the arrival experience need to guarantee? | **C**: Arrival as information front-load — 3-5 legible signals about location profile before any NPC dialogue |
|
||||
| Nigel Q3 | Do wormhole gateways create different first impressions per seed? | **C** for generator (seeded gate positions within zone-type constraints), **D** as design goal (player chooses which gate, each gate is a distinct social chokepoint) |
|
||||
| Ozzie Q2 | What does the player see when they arrive? | **D**: Contextual by travel method. **C** (orbital view) as default for normal transit — the planet fills half the viewport before you land. |
|
||||
|
||||
**Convergence — arrival as high-value information moment:**
|
||||
Three agents address the arrival experience independently and all conclude it must be meaningful. Gestalt frames it as information front-load. Nigel frames it as replayability surface. Ozzie frames it as the "promise delivery" moment. These are the same argument: arrival is the moment the world earns its scale. Wasted arrivals are wasted opportunities.
|
||||
|
||||
**Gestalt's "arrival signal slots" concept:**
|
||||
Each slot maps to an observable feature (guard density, commercial sprawl into arrival area, maintenance condition, faction signage, crowd composition) that encodes the location's profile. The skilled player reads more from the geometry than the unskilled player — information asymmetry expressed spatially.
|
||||
|
||||
**Nigel's gate-as-chokepoint concept:**
|
||||
Gateways as social chokepoints produce different starting knowledge states. Player A uses the commercial gate, Player B uses the industrial gate — different first NPCs, different first triangles, different starting social information. This is a replayability surface that doesn't require any topology to change.
|
||||
|
||||
**Ozzie's orbital view as default:**
|
||||
The orbital view — planet filling half the viewport, settlements visible before landing — is the designed arrival beat that makes the world feel like it has geography before the player enters it. "Survey, then commit." Connects to Ozzie's Q5: this is also where the scale drop moment happens.
|
||||
|
||||
---
|
||||
|
||||
## Level 5: Content Spidering
|
||||
|
||||
*Questions about how generation unfolds as the player moves through the world — the LOD/simulation-tier generation question.*
|
||||
|
||||
| Agent | Question | Recommendation |
|
||||
|---|---|---|
|
||||
| Nigel Q4 | Does the world live before the player arrives? | **B** (seeded historical state) for initial implementation; **C** (background simulation with meaningful outcomes) as endgame target; **D** (full pre-history simulation) as philosophical north star |
|
||||
| Ozzie Q3 | Does the world feel pre-existing or generated-as-you-walk? | Environmental archaeology **first** (D) — prop placement tells stories of pre-player history — then NPC knowledge (B), visual sightlines (A), economic activity (C) |
|
||||
| Tyre Q3 | Offline, on-demand, or progressive generation? | **D** (progressive): Layer 1 pre-gen at game start, Layer 2 on system visit, Layers 3-7 on district approach. Generation always hidden behind diegetic transitions. |
|
||||
| Tyre Q5 | What exists at each distance from the player in the galaxy? | `systems.db` metadata for all 300 → LocationProfiles for 1-3 hops → Phase 1 skeletons for adjacent systems → Phase 2 fill for current district |
|
||||
|
||||
**Strong convergence — progressive generation, hidden behind transit:**
|
||||
Tyre's architecture (progressive, diegetic) and Nigel's design goal (world lives before you arrive) are architecturally aligned. Tyre's model: generation happens during transit loading, never as a visible pause. Nigel's model: when the player arrives, the location has a history. The progressive architecture is the mechanism that makes Nigel's goal possible — location profiles and Phase 1 skeletons are generated during transit, and seeded historical state (Nigel B) can be computed at the same time.
|
||||
|
||||
**Ozzie's environmental archaeology:**
|
||||
The world feels pre-existing not through generation depth but through evidence. The crashed cargo loader with personal effects still inside. The memorial with fresh flowers. The barricaded doorway with scratches on the frame. Ozzie prioritizes this (D) above visual sightlines (A) because it's more visceral: "that's the moment the player stops thinking 'I'm in a generated space' and starts thinking 'someone was here before me.'" This is primarily a Phase 2 fill / object placement feature — prop groups that imply pre-player events.
|
||||
|
||||
**The "does the world live before you arrive" question (Nigel Q4):**
|
||||
Nigel flags this as the most architecturally load-bearing question in the whole workshop. The D-097 simulation tier system already has the skeleton. The question is whether background tier advancement produces *meaningfully different states* on first player visit. This needs a product commitment before architecture decisions lock.
|
||||
|
||||
---
|
||||
|
||||
## Level 6: Settlement
|
||||
|
||||
*Questions about what settlements are, where they go, and how their history drives their physical form.*
|
||||
|
||||
| Agent | Question | Recommendation |
|
||||
|---|---|---|
|
||||
| Gestalt Q4 | Atom of settlement identity — single tag, type+power, or type+power+era? | **C** (type + power structure + era layering) as endgame minimum; **D** (full profile) as ideal |
|
||||
| Miri Q3 | Does long-stable cultural blending produce irreducible hybrid identity? | **B** (named hybrid archetypes for common blends) + **C** (simulated coherence timer) + **D** (trauma as hybrid accelerant, connects to D-107) |
|
||||
| Miri Q4 | Does heritage root shape where communities form? | **C** (historical layering — first wave takes preferred terrain, later waves adapt) + **B** (cultural pressure score as output, feeds NPC behavior) |
|
||||
| Nigel Q5 | Does each settlement have a seeded developmental biography? | **C**: 4-6 parameters (founding reason, peak period, current trajectory, heritage at founding vs today, disruption event) drive era distribution, faction strength, NPC mix, triangle topology |
|
||||
| Tyre Q1 (Layer 2) | How do Location Profiles get populated? | **B**: Hybrid — generated baseline + hand-authored overrides for ~30-40 narrative-notable systems |
|
||||
|
||||
**Strong convergence — settlement as legible history:**
|
||||
Gestalt Q4, Nigel Q5, and Miri Q3+Q4 are all arguing the same point at different levels of detail. A settlement needs more than a type tag — it needs a historical trajectory that is spatially legible. The player should be able to read a settlement's biography from its physical form.
|
||||
|
||||
- Gestalt: "Every era transition in a settlement's history should leave at least one spatially visible scar."
|
||||
- Nigel: "The player who knows how to read settlement biographies has acquired cultural competence — a durable skill that makes them better at the game without making the game easier."
|
||||
- Miri: "Architecture is the community's argument with its environment."
|
||||
|
||||
**Nigel's settlement biography seed resolves Gestalt's era layering question:**
|
||||
In Round 1, era distributions were seeded independently per district (Nigel R1 Q5, option B+C). Nigel R1b Q5 supersedes this: era distributions should flow from the settlement biography. A "declining mining hub" settlement produces high Decay + EmergencyExtension blocks in industrial zones, OrganicGrowth in residential (workers who stayed), InstitutionalIncursion in commercial (corporate attempts to buy in). Every block's EraCause is legible to a player who understands the biography — even if the biography is never stated explicitly.
|
||||
|
||||
**Miri's hybrid identity formation (Q3):**
|
||||
This is uncontested — no other agent addresses it. Stable cultural blends (200+ years within ±10% variance) accumulate hybrid markers that belong to neither parent culture. This produces the setting's most interesting named places: communities with irreducible identities that are theirs alone. D-107's trauma event system becomes a cultural forge when connected here.
|
||||
|
||||
**Tyre's Layer 2 gap (Location Profiles):**
|
||||
The biggest structural gap in the entire pipeline. `systems.db` has 300 systems with rich attributes; there are no individual planet/station/moon records. Everything from Layer 3 downward depends on this. Tyre recommends hybrid approach: grammar-based generation for the majority, hand-authored profiles for ~30-40 narrative-notable systems (already tagged in `systems.db`). **This is the critical path bottleneck.**
|
||||
|
||||
---
|
||||
|
||||
## Level 7: District
|
||||
|
||||
*The existing DistrictSkeleton level — Phase 1 and Phase 2. Carried forward from Round 1, now enriched by settlement biography.*
|
||||
|
||||
Round 1b agents mostly addressed levels above district. The key additions at district level from this round:
|
||||
|
||||
- **Settlement biography drives district era distribution** (Nigel Q5 — see above). Districts no longer need independent era seeding; they inherit from settlement biography.
|
||||
- **Zone cluster adjacency varies per seed** (Nigel R1 Q3 — carried forward). Zone clusters are coherent (commercial clusters together, industrial clusters together); which cluster is adjacent to which varies per seed.
|
||||
- **Guarantee system applies to all zone types** (Tyre Q4 — see Pipeline Architecture below). Tier 1 guarantees (Social Hub, Informal Zone, Encounter Corridor) apply to ALL inhabited districts regardless of SettingType. Phase 1 is zone-agnostic.
|
||||
|
||||
**Return visits (Ozzie Q4):**
|
||||
|
||||
| Option | Description |
|
||||
|---|---|
|
||||
| B. NPC drift | Characters have moved, aged, formed new relationships. Social fabric has shifted. |
|
||||
| D. Consequence echo | The world has reacted to what the player did. People remember. Consequences have propagated. |
|
||||
|
||||
Ozzie's recommendation (B+D as minimum, C/economic change if simulation supports it) defines the experiential test for whether the world is a stage set or a living place. The first time a player returns to a location and someone says "I heard about what you did at the refinery" — that's the moment the simulation proves itself.
|
||||
|
||||
---
|
||||
|
||||
## Level 8: Room
|
||||
|
||||
*Cultural and economic identity at the intimate scale — the terminus of the cascade.*
|
||||
|
||||
| Agent | Question | Recommendation |
|
||||
|---|---|---|
|
||||
| Gestalt Q5 | How deeply does economic context cascade into room interiors? | **D** (full cascade) as endgame target — every room is an information puzzle about its inhabitant's economic position, factions, heritage, and operational state |
|
||||
| Miri Q5 | What design tokens carry cultural identity at room level? | **B** as baseline (Layers 1+2: spatial grammar tokens + social pattern tokens — zero asset cost), **C** as enrichment (adds Layer 3: object selection tokens per heritage root) |
|
||||
|
||||
**Convergence — rooms as information puzzles:**
|
||||
Gestalt Q5 and Miri Q5 converge on the same proposition: a room that only tells the player its function (this is an office) gives them nothing. A room that signals economic position, cultural heritage, and operational state gives them a decision. "Every room a player enters should contain at least one observable signal they couldn't have predicted from the exterior."
|
||||
|
||||
**Miri's token framework — three layers:**
|
||||
|
||||
| Layer | Tokens | Asset Cost | Cultural Signal |
|
||||
|---|---|---|---|
|
||||
| 1. Spatial grammar | `privacy_default`, `sightline_character`, `gathering_orientation`, `threshold_character` | **Zero** — derived from heritage root | Space *feels* culturally specific before any object is seen |
|
||||
| 2. Social pattern | `stranger_distance`, `group_size_prior`, `noise_level_prior`, `eye_contact_norm` | **Zero** — drives NPC behavior | Room *behaves* culturally specific |
|
||||
| 3. Object selection | Wall objects, surface materials, lighting character — per heritage root authored lists | **Asset cost** — one list per root | Room *reads* culturally specific |
|
||||
|
||||
Layers 1+2 cost nothing and deliver the essential cultural read. A Frost bar and a Tide bar feel different before a single object is placed. Layer 3 is the enrichment layer — add per heritage root as authoring bandwidth allows.
|
||||
|
||||
**The cascade test:**
|
||||
Gestalt's proposed test: "Can a skilled player stand in a room and read backward from the furniture to the system's power structure?" If yes, the cascade is working. If not, the generator is producing art assets, not simulation primitives.
|
||||
|
||||
---
|
||||
|
||||
## Pipeline Architecture: How 5 Zone Types Share One Pipeline
|
||||
|
||||
*This is the answer to the Round 1 flag. Tyre Q4 is the key analysis.*
|
||||
|
||||
**Resolution:** Phase 1 (skeleton generation) is **zone-agnostic**. Phase 2 (chunk fill) diverges by zone type family. Three families, not five independent generators.
|
||||
|
||||
| What's shared (all zone types) | Notes |
|
||||
|---|---|
|
||||
| Phase 1 skeleton structure (4×4 blocks, zoning, social sites) | Block grid works for Station, Urban, Agricultural, Wilderness. *Block meaning* changes, *structure* doesn't. |
|
||||
| Guarantee audit system (D-097) | Tier 1 guarantees apply to ALL inhabited districts regardless of SettingType |
|
||||
| ZonePalette + modifier system | Base palette per SettingType, modifiers apply identically |
|
||||
| ChunkMutations / DamageOverlay | Post-generation modification is setting-agnostic |
|
||||
| Social site placement mechanism | Site template pool is constrained by SettingType; placement mechanism is shared |
|
||||
| Chunk streaming | Already setting-agnostic |
|
||||
|
||||
| What diverges (per zone type family) | Family members | Cost per family |
|
||||
|---|---|---|
|
||||
| Phase 2 fill algorithm | **Interior:** Station, Orbital, Specialized | 2-4 weeks |
|
||||
| Phase 2 fill algorithm | **Urban:** Urban, Industrial, Maritime/port | 2-4 weeks |
|
||||
| Phase 2 fill algorithm | **Natural:** Wilderness, Agricultural, Water | 2-4 weeks |
|
||||
| Tile palette data | All SettingTypes | 1-2 weeks per type (asset-dominated) |
|
||||
| Height/terrain treatment | Station (flat), Urban (building heights), Natural (heightmap) | 1-3 weeks per family |
|
||||
|
||||
**Total endgame generation engineering:**
|
||||
- Phase 1 (once): 3-5 weeks
|
||||
- Phase 2 (3 families): ~9 weeks + per-type customization (~3-4 weeks)
|
||||
- Location Profile grammar (Layer 2): 3-4 weeks
|
||||
- Settlement generation (Layer 6): 3-5 weeks
|
||||
- Content spidering pipeline (Layer 5): 2-3 weeks
|
||||
- **Total: ~20-30 weeks** depending on topography depth
|
||||
|
||||
**Critical path: Layer 2 → Layer 6 → Layer 7.** Everything else is either already built (Layer 1), cheap (Layer 3A, Layer 4), or parallelizable (Layer 5, Layer 8). The three critical layers are sequential.
|
||||
|
||||
---
|
||||
|
||||
## What's Already Built (Tyre's Inventory)
|
||||
|
||||
| Layer | Status | Notes |
|
||||
|---|---|---|
|
||||
| Layer 1: Galaxy (300 systems) | **Built** | `systems.db` (7 tables), 300+ wiki pages, star map algorithm, `generate-star-map.py`, gate topology data, cultural data |
|
||||
| Layer 2: Location Profiles | **GAP** | Biggest structural gap. `systems.db` has system-level data; no individual planet/station records exist |
|
||||
| Layer 3: Topography | **Not built** | Solution space understood. Abstract tags = days. Noise heightmap = 3-5 weeks. |
|
||||
| Layer 4: Gateways | **Partially designed** | D-093, D-095 define lore. Horizon station = Station district. Gate-specific templates needed. |
|
||||
| Layer 5: Content spidering | **Architecture designed** | Simulation tiers (D-026) built. Streaming built. Generation hooks not built (TODO in code). |
|
||||
| Layer 6: Settlement | **Not built** | Missing bridge between topography and districts |
|
||||
| Layer 7: District → Building | **Data model built (579 lines)** | Phase 1 + Phase 2 algorithms not implemented |
|
||||
| Layer 8: 2D → 3D rendering | **In progress** | Generate 3D-ready data now; 2D renderer filters z > 0 |
|
||||
|
||||
**The pipeline has bookends:** Layer 1 (galaxy dataset) is mature. Layer 7's data model (district skeleton) is mature. The middle — Layers 2, 3, 5, 6, and Phase 1/2 algorithms for Layer 7 — needs to be built.
|
||||
|
||||
---
|
||||
|
||||
## Convergence Map
|
||||
|
||||
| Topic | Agents | Shared Conclusion |
|
||||
|---|---|---|
|
||||
| Fixed galaxy, seeded internal state | Nigel Q1, Miri Q1 | Galaxy is canonical and learnable; situation (faction, economy, NPC triangles) varies per run |
|
||||
| Topography must be causal, not decorative | Gestalt Q2, Nigel Q2 | Terrain must cause settlement form to produce decisions; cosmetic topography is dead design space |
|
||||
| Arrival = information front-load | Gestalt Q3, Nigel Q3, Ozzie Q2 | Every arrival is a once-per-location signal moment; 3-5 legible reads before any NPC dialogue |
|
||||
| Settlement = legible history | Gestalt Q4, Nigel Q5, Miri Q3/Q4 | A settlement's physical form must express its biographical trajectory; players read history spatially |
|
||||
| Progressive generation, hidden behind transit | Tyre Q3, Nigel Q4 | Generation happens during diegetic transitions; player never sees "generating..." after game start |
|
||||
| Rooms as information puzzles | Gestalt Q5, Miri Q5 | Every room must contain at least one signal the player couldn't have predicted from the exterior |
|
||||
| Zone families (Phase 2 diverges, Phase 1 shared) | Tyre Q4 | Phase 1 is zone-agnostic; 3 Phase 2 families (Interior/Urban/Natural) cover all 5+ zone types |
|
||||
|
||||
---
|
||||
|
||||
## Tensions Map
|
||||
|
||||
| Tension | Agents | Description |
|
||||
|---|---|---|
|
||||
| Topography depth | Gestalt Q2, Nigel Q2 vs Tyre Q2 | Design goal (hard constraint) agreed; Tyre notes tags are sufficient for district generation. Value of heightmaps is the world map experience, not ground-level gameplay. |
|
||||
| Background sim fidelity | Nigel Q4 (C: meaningful evolution) vs current architecture | D-097 supports background tiers; whether they produce *meaningfully different* first-visit states requires a product commitment. Most architecturally load-bearing open question. |
|
||||
| Cultural cascade depth at room | Gestalt Q5 (full cascade, endgame) vs Miri Q5 (Layers 1+2 as baseline) | Compatible in direction (both want full cascade eventually); differ on minimum viable for cultural room identity. Miri's Layers 1+2 answer: zero asset cost, sufficient cultural read. |
|
||||
|
||||
---
|
||||
|
||||
## Upstream Dependencies
|
||||
|
||||
Dependencies that must be resolved before downstream questions can be answered, in order:
|
||||
|
||||
1. **Wave chronology** (Miri Q1) — authored worldbuilding document. Root input for the entire cultural cascade. Without it, corridor identities cannot be derived, heritage probability tables cannot be authored, and Miri's heritage root authoring scope cannot be scoped. **Blocks: everything in cultural generation.**
|
||||
|
||||
2. **Heritage root blend of starting district** (Miri upstream dep, carried from R1) — Sova Transit / Van Maanen's Star. Still requires product owner confirmation. Miri's working hypothesis: Iron/Stone blend with Tide undertow. **Blocks: heritage root authoring, naming system authoring.**
|
||||
|
||||
3. **Location Profile grammar commitment** (Tyre Q1/Layer 2) — the biggest structural gap. The grammar that maps system attributes to planet/station profiles is the critical design work. **Blocks: Layers 3-7 producing meaningful output.**
|
||||
|
||||
4. **Background simulation fidelity commitment** (Nigel Q4) — does the world live before the player arrives in a meaningful way? Answer shapes whether the content spidering pipeline needs to simulate historical evolution or just serve seeded static state. **Blocks: Layer 5 architecture decisions.**
|
||||
|
||||
5. **Zone type family confirmation** (Tyre Q4) — are the three families (Interior, Urban, Natural + Transitional as hybrid) the right grouping? **Blocks: Phase 2 implementation strategy and asset pipeline.**
|
||||
|
||||
---
|
||||
|
||||
## Proposed Interview Clusters for Product Owner
|
||||
|
||||
Six clusters, organized by pipeline level. Cluster 1 is prerequisite for all others.
|
||||
|
||||
---
|
||||
|
||||
### Cluster 1: Galaxy Identity and Cultural Foundation
|
||||
|
||||
*Prerequisite for authoring work. Must be answered first.*
|
||||
|
||||
1. **Is the galaxy map canonical and fixed, with internal state seeded per run?** (The 300 systems, their names, and wormhole topology are learnable across playthroughs; faction control, economy, and NPC triangles vary.) Nigel and Miri both assume yes — confirm.
|
||||
|
||||
2. **How does the cultural geography of the galaxy derive from settlement history?** Miri proposes a wave chronology: the galaxy was settled in waves, each carrying a dominant cultural pattern. Corridor cultural identity is derived from wave history, not hand-authored per system. Confirm the wave model as the setting framework, or specify the alternative.
|
||||
|
||||
3. **What does the galaxy map reveal at start vs unlock through play?** Ozzie recommends: economic signal and bare geography at start; faction presence, reputation, and mystery layers unlock through play. The map rewards engagement with the world.
|
||||
|
||||
---
|
||||
|
||||
### Cluster 2: System Profile and Economic Cascade
|
||||
|
||||
4. **What are the economic axes of a system profile?** Gestalt proposes minimum viable = dual axis (aggregate wealth + wealth holder: who is rich — individuals, corporations, government, or nobody). Full endgame = multiple industries, multiple power players, historical disruptions. Which is the design commitment?
|
||||
|
||||
5. **Does physical environment modulate cultural expression?** A Frost community on an ice world vs a Frost community on a tropical world — same heritage root, different expression because the environment is in tension with the culture. Miri proposes continuous axis modulation. Confirm whether this interaction is in scope and at what fidelity.
|
||||
|
||||
6. **How do Location Profiles get populated?** Tyre identifies this as the biggest structural gap. Hybrid approach: grammar-based generation for the majority of the 300 systems; hand-authored profiles for ~30-40 narrative-notable systems already tagged in `systems.db`. Confirm approach and identify who authors the grammar.
|
||||
|
||||
---
|
||||
|
||||
### Cluster 3: Geography and Where Settlements Form
|
||||
|
||||
7. **Does topography constrain settlement placement or decorate it?** Gestalt argues for hard constraint — rivers create natural district boundaries, mountains block corridors, coastlines produce port districts. Nigel agrees: geographic causality is the replayability multiplier that operates automatically. The implementation starts with abstract tags (cheap, Tyre says sufficient for district generation) and enriches to a noise heightmap when the world map becomes a player-facing feature.
|
||||
|
||||
8. **Does heritage root influence where communities form?** Miri proposes: cultural preferences are probability weights, not hard constraints. Off-preference settlement generates a `cultural_pressure_score` that feeds into NPC behavior. Historical layering: first wave takes preferred terrain, subsequent waves adapt. This produces stratified communities with built-in cultural tension.
|
||||
|
||||
---
|
||||
|
||||
### Cluster 4: Arrival and First Impressions
|
||||
|
||||
9. **What does the arrival experience guarantee?** Gestalt proposes "arrival signal slots" — specific observable features (security density, commercial sprawl, faction signage, maintenance condition, crowd composition) that are set by the location profile and legible to the observant player. How many signals, and which are mandatory?
|
||||
|
||||
10. **Is the orbital view the default arrival experience for planetary locations?** Ozzie: the planet fills half the viewport before the player commits to landing. They see the geography, can identify settlements, feel the scale. "Survey, then commit." How the player traveled determines what they see — but the orbital view should be the designed default.
|
||||
|
||||
11. **Do wormhole gateways produce different first impressions per seed?** Nigel proposes: gate placement seeded within zone-type constraints (gate must open onto a transit or commercial zone, but which zone per seed). Two players through the same gate topology have different arrival contexts — different first NPCs, different first social information.
|
||||
|
||||
---
|
||||
|
||||
### Cluster 5: Settlement Biography and World History
|
||||
|
||||
12. **What is the atom of settlement identity?** Gestalt proposes: type + power structure + era layering as the endgame minimum. A corporation-controlled port and a guild-controlled port are genuinely different games; add era history and every era transition leaves a spatially visible scar. Confirm.
|
||||
|
||||
13. **Does each settlement have a seeded developmental biography?** Nigel proposes: 4-6 parameters (founding reason, peak period, current trajectory, dominant heritage at founding vs today, disruption event) that drive era distributions, faction strength, NPC mix, and triangle topology. The biography makes settlement variety coherent rather than arbitrary. Confirm whether biography is the generation mechanism or whether era parameters remain independently seeded.
|
||||
|
||||
14. **Does the world live before the player arrives?** The most architecturally load-bearing question (Nigel Q4). Options: (B) seeded historical state — each location generates with a developmental biography, doesn't evolve until player visits; (C) background simulation — unvisited locations advance in fidelity-reduced form over in-game time, producing different states depending on when the player arrives. The D-097 simulation tier system supports both; only B is achievable in near term. Confirm which is the design commitment.
|
||||
|
||||
---
|
||||
|
||||
### Cluster 6: Room Identity and the Cascade Terminus
|
||||
|
||||
15. **How deeply does economic context cascade into room interiors?** Gestalt proposes D (full cascade) as the endgame target: every room is an information puzzle about its inhabitant's economic position, faction affiliations, heritage, and operational state. The test: "Can the skilled player read backward from the furniture to the system's power structure?" Confirm this as the design principle.
|
||||
|
||||
16. **What is the minimum viable cultural room identity?** Miri proposes Layers 1+2 (spatial grammar + NPC behavior tokens) as the baseline — zero asset cost, delivers the essential cultural read. A Frost bar feels different before any objects are placed. Layer 3 (object lists per heritage root) adds enrichment per root as authoring bandwidth allows. Confirm the baseline.
|
||||
|
||||
---
|
||||
|
||||
*Notes produced by Qatux from 5 agent Round 1b outputs. These 16 product owner questions represent the full endgame vision. Prioritization and v0.2 scoping against this vision is the next workshop agenda.*
|
||||
@@ -0,0 +1,578 @@
|
||||
---
|
||||
title: "SW1-R2 — Consolidated Round 2 Notes"
|
||||
author: qatux
|
||||
round: SW1-R2
|
||||
workshop: world-generation
|
||||
date: 2026-03-24
|
||||
status: complete
|
||||
---
|
||||
|
||||
# World Generation Workshop — Round 2 Consolidated Notes
|
||||
|
||||
**Purpose:** Synthesise the 5 Round 2 agent outputs. Each agent cross-read the R1b outputs against
|
||||
the product owner interview answers and identified consequences, tensions, and new questions.
|
||||
|
||||
**Source files read:**
|
||||
- `gestalt-sw1r2.md` ✓
|
||||
- `miri-sw1r2.md` ✓
|
||||
- `nigel-sw1r2.md` ✓
|
||||
- `ozzie-sw1r2.md` ✓
|
||||
- `tyre-sw1r2.md` ✓
|
||||
|
||||
---
|
||||
|
||||
## ⚠️ STALE D-RECORDS — ACTION REQUIRED
|
||||
|
||||
The following D-records conflict with the product owner interview answers and must be superseded:
|
||||
|
||||
| D-record | Title | Conflict |
|
||||
|----------|-------|---------|
|
||||
| **D-104** | Heritage grammar overlays (abstract roots) | Heritage roots (Frost/Stone/Tide/Vine/Dust/Iron/Salt) explicitly deprecated. Real-world cultural corridors are canonical. |
|
||||
| **D-105** | Heritage grammar overlays (cont.) | Same as D-104. |
|
||||
| **D-101** | ZonePalette modifier system | Modifier axis A = `HeritageRoot` type — needs remapping to cultural_corridor + founding_culture. |
|
||||
| **D-107** | (Likely references heritage roots) | Requires audit. |
|
||||
|
||||
**Resolution confirmed by PO (R1 + R2 follow-up):** Clean break. All four records superseded.
|
||||
The 7 abstract roots are retired. New D-records will describe how real-world corridor identities
|
||||
(Commonwealth, Iberian/Latin American, East Asian, Germanic) map to room grammar, spatial tokens,
|
||||
and NPC behavior.
|
||||
|
||||
**Note from Miri (R2):** Supersession should be paired with new D-records covering:
|
||||
- Room grammar parameterisation per cultural corridor (after wiki cross-check with Paula/Mellanie)
|
||||
- Attenuation tier specification (cultural_corridor × heritage_persistence × hop_distance → tier)
|
||||
- Object list authoring per founding_culture and industrial corridor
|
||||
|
||||
---
|
||||
|
||||
## 1. Key Product Owner Decisions and Agent Synthesis
|
||||
|
||||
### 1.1 Fixed canonical galaxy, seeded by simulation drift — not by seed parameters
|
||||
|
||||
**PO decision:** 300+1 fixed systems, same wormhole routes every run. Internal state drifts via
|
||||
background simulation, not via seed. Same canonical starting state every run.
|
||||
|
||||
**Agent synthesis:**
|
||||
- **Nigel:** R1b Q1 (fixed canonical galaxy) confirmed; mechanism changed completely. Seed-based
|
||||
internal state variation explicitly rejected. Entire replayability framework shifts: variety comes
|
||||
from simulation trajectories, not from starting parameters. Player knowledge of canonical starting
|
||||
states is durable — veterans know what Van Maanen's Star looks like on day 1. This is a feature
|
||||
(learnable world), but the metagaming surface concentrates in early-game geography.
|
||||
- **Gestalt:** Generator's job is to produce canonical state reliably, not produce variety. Variety
|
||||
is the simulation's job. "Generation quality" now means correctness and internal consistency, not
|
||||
seed variety. The generator can be fully deterministic and stable.
|
||||
- **Ozzie:** Confirmed. The GTTR arrival window (expectation set by authored text) pairs with
|
||||
simulation-driven reality. The gap between GTTR description and current state IS the archaeology.
|
||||
|
||||
### 1.2 Topography: hard constraint, authored not procedural
|
||||
|
||||
**PO decision:** Mountains block corridors, rivers create district boundaries, coastlines produce
|
||||
port districts. Authored world maps for all planets and moons (not procedurally generated heightmaps).
|
||||
|
||||
**Agent synthesis:**
|
||||
- **Nigel:** Confirmed as hard constraint; geography is stable across runs. Players learn the terrain.
|
||||
Replayability comes from simulation state at those fixed locations, not from layout variation.
|
||||
- **Gestalt:** This is architecturally simpler for the generator (no terrain generation algorithm)
|
||||
but shifts authoring load. Format of authored world maps is unspecified — this is a load-bearing
|
||||
gap (see section 3 below).
|
||||
- **Miri:** Authored topography + wiki cultural data = the generator gets high-quality inputs at
|
||||
Layers 1-3. Cultural territory preferred terrain (first wave takes preferred terrain, later waves
|
||||
adapt) is now derivable from authored world maps + cultural-migration-pressure.md together.
|
||||
|
||||
### 1.3 Heritage roots deprecated — real-world corridors canonical
|
||||
|
||||
**PO decision:** 7 abstract roots (Frost/Stone/Tide/Vine/Dust/Iron/Salt) deprecated as generator
|
||||
inputs. Cultural data already in 301 wiki entries and systems.db uses real-world corridor identities.
|
||||
|
||||
**Agent synthesis (most detailed from Miri):**
|
||||
- **Miri:** Full translation table provided (abstract root → corridor equivalent). The mechanisms
|
||||
R1b proposed survive intact — only the vocabulary changes. Room grammar now parameterised by:
|
||||
- Layer 1 (spatial): cultural_corridor identity
|
||||
- Layer 2 (social): cultural_corridor × attenuation_tier
|
||||
- Layer 3 (objects): founding_culture × industrial_corridor × biography_trajectory
|
||||
Four bar descriptions authored (Commonwealth, Iberian/LatAm, East Asian, Germanic/Scandinavian)
|
||||
as concrete room grammar targets.
|
||||
- **Gestalt:** The mapping from corridor identity to spatial grammar tokens is the missing authoring
|
||||
artifact. No document yet connects cultural-migration-pressure.md to generator room parameters.
|
||||
Miri's bar descriptions are a strong first draft but need validation against the 301 wiki entries.
|
||||
- **Nigel:** Settlement biography concept (R1b Q5) is superseded in its seed-variation framing.
|
||||
Survives as canonical authored content: founding biography is wiki content (Miri/Paula territory),
|
||||
not a seeded generator parameter.
|
||||
|
||||
### 1.4 Location profiles wiki-authored, topography authored
|
||||
|
||||
**PO decision:** Generator reads from authored data, doesn't generate profiles. Every planet and
|
||||
moon gets authored profiles. Same approach for world maps.
|
||||
|
||||
**Agent synthesis:**
|
||||
- **Gestalt:** Architectural framing — the generator is now a "reader-and-filler":
|
||||
|
||||
| Layer | Source | Generator role |
|
||||
|-------|--------|----------------|
|
||||
| Galaxy (300 systems) | systems.db — built | Read only |
|
||||
| Location profiles | Wiki — authoring pipeline | Read only |
|
||||
| Topography | Authored world maps — format TBD | Read only |
|
||||
| Arrival | Template from location type + GTTR entry | Template stamp |
|
||||
| Content spidering | LOD/sim tier cascade | Trigger + manage |
|
||||
| Settlement placement | Authored topography + wiki economics | Constraint placement |
|
||||
| District skeleton | Existing data model | Full generation |
|
||||
| Rooms | Full simulation primitives | Full generation |
|
||||
|
||||
Generator is richly authored at top, generative at bottom. This is the right architecture:
|
||||
cultural and geographic character too important for procedural approximation.
|
||||
|
||||
### 1.5 Rooms as full simulation primitives with LOD
|
||||
|
||||
**PO decision:** A visited bar needs monthly turnover, cost, employee count, current staff and
|
||||
visitors. Depth scales with player engagement. Economic success follows regional prosperity.
|
||||
|
||||
**Agent synthesis:**
|
||||
- **Gestalt:** "Any ambient NPC can evolve" + "rooms are full simulation primitives" together
|
||||
collapse the ambient/narrative NPC distinction. Every generated NPC needs a minimum data bundle
|
||||
sufficient to be an interesting person. The distinction between "real" and "filler" NPCs cannot
|
||||
hold if any filler NPC can become narrative. Required minimum bundle: cultural background, economic
|
||||
role, relationship network seed, behavioral tell config, enough data for a triangle to form.
|
||||
- **Ozzie:** Confirmed. The NPC-driven generation hook is "the game" — "the space becomes meaningful
|
||||
by proxy." Spaces are memorable because of what happened there, not because the generator made
|
||||
them notable.
|
||||
|
||||
### 1.6 Replayability from simulation drift, not seed variation
|
||||
|
||||
**PO decision:** NOT seed-based variation. Replayability from simulation trajectory differences.
|
||||
Background simulation (economic + social + political) runs on spare CPU cores.
|
||||
|
||||
**Agent synthesis:**
|
||||
- **Nigel:** This is a stronger replayability model IF the simulation stays genuinely variable.
|
||||
Primary concern: simulation convergence risk (see section 4). Identifies 6 replayability surfaces
|
||||
under the new model: simulation trajectory, NPC-driven generation, news-driven generation, economic
|
||||
propagation, exploration order, social evolution.
|
||||
- **Gestalt:** Generator's job changes: produce canonical state reliably. Variety is simulation's
|
||||
domain. Important architectural consequence: two playthroughs diverge based on (1) when player
|
||||
visits each location, (2) what player does at each location, (3) which NPC relationships they
|
||||
develop, (4) which news events fire.
|
||||
|
||||
### 1.7 NPC-driven and news-driven generation hooks
|
||||
|
||||
**PO decision:** (1) Know someone from a distant planet → their house, family, friends, neighborhood
|
||||
generate at that location. (2) News reports an event in a town → that town must exist when visited.
|
||||
Sparse frequency on news-driven.
|
||||
|
||||
**Agent synthesis:**
|
||||
- **Ozzie:** "THAT'S THE GAME. That's the moment." The NPC-driven hook means every generated space
|
||||
carries potential significance from the moment you enter it. You can't know yet whether the person
|
||||
at the corner table will matter — any ambient NPC can evolve. The magic requires invisibility:
|
||||
player should feel they discovered a real place, not that the simulation made them a personalised
|
||||
level. *Open question: does the player know this is happening?* (Ozzie's instinct: invisible.)
|
||||
- **Nigel:** NPC-driven generation creates unique per-run social geographies — run 1 befriends a
|
||||
dock worker, so Tau Ceti's docking district generates in detail; run 2 befriends a merchant,
|
||||
different district generates. "The player's social map shapes the generated world." Risk: NPC
|
||||
locality bias — if certain NPC archetypes are always most useful to befriend, the same parts of
|
||||
the world always generate in detail.
|
||||
- **Gestalt:** Both hooks mean generation is socially-triggered and narratively-triggered, not just
|
||||
player-location-driven. This requires coordination between the generation pipeline and
|
||||
narrative/social simulation layers that don't currently exist in the architecture.
|
||||
|
||||
### 1.8 Environmental archaeology from real simulation events only
|
||||
|
||||
**PO decision:** No fabricated history. If there's rubble, the simulation produced the explosion.
|
||||
If there's a memorial, someone died in the simulation.
|
||||
|
||||
**Agent synthesis:**
|
||||
- **Gestalt:** Right design position (integrity > atmosphere) but demands the simulation produce
|
||||
enough traces organically. Pre-play simulation run must produce enough events before player's
|
||||
first move to seed the world with readable history. The background sim workshop must answer:
|
||||
how much pre-play simulation time is needed to make a world feel lived-in?
|
||||
- **Nigel:** Settles the settlement biography question — no seeded historical scars. Raises the bar
|
||||
for simulation: must produce interesting events that leave observable traces, at sufficient
|
||||
frequency. Social archaeology (web of relationships visible through NPC behaviour) may be more
|
||||
reliable than event archaeology — generated continuously, not episodically.
|
||||
- **Ozzie:** Quiet-but-inhabited is fine IF the NPC social fabric is rich. "A bar that's never had
|
||||
an explosion can still feel alive if the relationships inside it have evolved, fought, reconciled,
|
||||
and changed."
|
||||
|
||||
### 1.9 Arrival as diegetic GTTR window
|
||||
|
||||
**PO decision:** Contextual by travel method. An insert context window opens with system stats,
|
||||
planetary screenshot, and the GTTR narrative entry on arrival.
|
||||
|
||||
**Agent synthesis:**
|
||||
- **Ozzie:** GTTR warm arrival > cold orbital arrival. Expectation vs. reality is more interesting
|
||||
than ignorance vs. reality. The GTTR is "writing you a cheque. The world has to cash it." The gap
|
||||
between GTTR description and current simulation state is archaeology — legible if it's visible
|
||||
(you can see WHY things changed). *Critical playtest question: is GTTR-vs-reality divergence
|
||||
exciting or jarring?*
|
||||
- **Miri:** The cultural signal at arrival should be the first delivery on the galaxy map's promise.
|
||||
Settlement patterns at orbital view should be culturally legible — Commonwealth worlds cluster
|
||||
around institutional centres, Iberian/LatAm worlds cluster around water and family-pattern sprawl.
|
||||
|
||||
### 1.10 Galaxy map: full information from start
|
||||
|
||||
**PO decision:** Full information from start. Inserts logically contain a 300-system star chart.
|
||||
|
||||
**Agent synthesis:**
|
||||
- **Ozzie:** Full information works IF the dots have visual rhythm and named stories. 300 dots that
|
||||
all look the same are homework; 300 dots where your eye can land on a name and feel something are
|
||||
stories waiting to be entered. The wonder shifts from "what is this?" (ignorance) to "what IS
|
||||
this, actually, given everything I've heard?" (expectation). This requires visual design that
|
||||
hasn't happened yet. *Galaxy map as emotional object is the player experience question nobody
|
||||
else has asked.*
|
||||
- **Gestalt:** Confirmed. The GTTR entries are the galaxy's voice. Every system has a name, a voice,
|
||||
a personality before the player visits.
|
||||
|
||||
### 1.11 Spatial cohesion principle
|
||||
|
||||
**PO decision:** Cohesion at small/middle scale (not messy), variety at middle/large scale (not
|
||||
predictable).
|
||||
|
||||
**Agent synthesis:**
|
||||
- **Gestalt:** Codified as a design law:
|
||||
- Room → block level: cohesive. Single block feels like it belongs to one identifiable zone/era/culture.
|
||||
- District → settlement level: varied. Different districts feel genuinely different.
|
||||
- Settlement → system level: varied at settlement identity level, each internally coherent.
|
||||
Era transitions produce variety at district/block boundary, not within a single block.
|
||||
- **Ozzie:** Cohesion/variety boundary needs a player-legible version: "every neighbourhood feels
|
||||
internally consistent AND every new district I enter feels genuinely different from the last."
|
||||
Miri's Layer 1 (spatial grammar) and Layer 2 (social pattern) deliver this without asset cost.
|
||||
|
||||
---
|
||||
|
||||
## 2. Convergences Across Agents
|
||||
|
||||
| Theme | Agents | Consensus |
|
||||
|-------|--------|-----------|
|
||||
| Generator is reader-and-filler, not full procedural engine | Gestalt, Miri, Nigel | Layers 1-3 are authored inputs; generator produces spatial expression at layers 6-8. |
|
||||
| Simulation drift IS the replayability engine | All four | The background simulation design workshop is the single most important design work after the generator pipeline. |
|
||||
| NPC-driven generation hook is the highest-value feature | Ozzie, Nigel, Gestalt | "The game," "the moment," "the most exciting sentence in the interview." Strong convergence. |
|
||||
| Background simulation workshop is non-negotiable | Gestalt, Nigel | Replayability is undefined without it. NPC evolution is undefined. Archaeology is undefined. |
|
||||
| Heritage roots deprecated → corridor mapping is the missing artifact | Gestalt, Miri | Miri has produced a first draft. Needs validation against wiki content. |
|
||||
| Economic cascade confirmed as generator spine | Gestalt, Miri, Nigel | District, block, room all carry economic encoding. `EconomicModifier` on `ZonePalette` needs formalisation. |
|
||||
| Every NPC needs minimum data bundle | Gestalt | Follows from "any ambient NPC can evolve." Ambient/narrative distinction collapses. |
|
||||
| GTTR creates expectation contract | Ozzie, Miri | World must deliver on authored text. Playtest needed to calibrate how much divergence is exciting vs. jarring. |
|
||||
|
||||
---
|
||||
|
||||
## 3. Tensions and Gaps
|
||||
|
||||
### 3.1 ~~CRITICAL~~ RESOLVED — World map format
|
||||
|
||||
**PO answer (R2 follow-up):** Annotated heightmaps. Grayscale heightmap PNG + metadata JSON per
|
||||
planet/moon, with rivers/coastlines/biome zones as overlay layers. Additionally, a planetary shader
|
||||
plugin generates visual screenshots of each planet type (earthlike, jungle, desert, mars-like,
|
||||
ocean, etc.) for embedding in wiki pages and GTTR entries.
|
||||
|
||||
This is Gestalt's option A/B hybrid: annotated image (heightmap PNG) + structured metadata (JSON
|
||||
overlay layers). The JSON overlay layers give the generator the geometric data it needs — coastal
|
||||
boundaries, river paths, biome zones — without requiring a custom drawing tool. The visual
|
||||
screenshots feed the GTTR diegetic arrival window.
|
||||
|
||||
**Status:** Resolved. Authoring pipeline format is decided. Engineering can proceed on the ingestion
|
||||
pipeline (heightmap PNG + overlay JSON → terrain constraint data for district placement).
|
||||
|
||||
---
|
||||
|
||||
### 3.2 CRITICAL — Corridor-to-room-grammar mapping is the missing authoring artifact
|
||||
|
||||
Heritage roots are deprecated. Cultural corridors are canonical. But there is no document mapping
|
||||
corridor identity to spatial grammar tokens (Layer 1), social pattern tokens (Layer 2), or object
|
||||
selection (Layer 3). Without this document, the generator cannot produce culturally differentiated
|
||||
rooms.
|
||||
|
||||
**Current state:** Miri has authored four bar descriptions (Commonwealth, Iberian/LatAm, East Asian,
|
||||
Germanic/Scandinavian) as concrete room grammar parameterisations. This is a strong start, but:
|
||||
- Not yet validated against the 301 wiki entries
|
||||
- Industrial corridor overlay modifier unspecified (affects physical character? NPC composition? Both?)
|
||||
- Attenuation tiers proposed (Living/Structural/Archaeological) but not ratified
|
||||
- Intra-corridor diversity (Chinese vs Vietnamese bar in east_reach) not yet expressible at Layer 3
|
||||
- Compound identity blending function unspecified (corridor × exception archetype × industrial overlay)
|
||||
- Perpetual Founder Stamp room expression unaddressed
|
||||
|
||||
**Unblocking path (Miri, post-R2):** The wiki cross-check (does my derived room grammar match what
|
||||
Paula and Mellanie actually wrote for the 301 system entries?) should run in parallel with any
|
||||
background sim workshop prep. Paula and Mellanie have the best read on whether the corridor
|
||||
parameterisations match the authored content. This cross-check is the prerequisite before any
|
||||
room grammar authoring work begins.
|
||||
|
||||
**Owner:** Miri (primary), Gestalt (generator integration), Araminta (visual expression of Layer 3)
|
||||
**Cross-check:** Paula + Mellanie (wiki content validation)
|
||||
|
||||
**Status:** Draft authoring done, wiki cross-check and formalisation pending. Can run in parallel
|
||||
with background sim workshop prep.
|
||||
|
||||
---
|
||||
|
||||
### 3.3 REFRAMED — Simulation convergence / replayability model
|
||||
|
||||
**PO answer (R2 follow-up):** Three-part reframe:
|
||||
|
||||
1. **Player agency is the primary replayability lever.** Who you create, what you do, where you go
|
||||
across 300+ systems already provides massive variety. The background sim is secondary variety,
|
||||
not the core mechanism.
|
||||
|
||||
2. **Equilibrium is signal, not failure.** A stable economy shows the effect of the player's choices
|
||||
(or non-choices). That's information, not boredom. Convergence is not a design problem to be
|
||||
engineered away — it is a legible state for the player to read and respond to.
|
||||
|
||||
3. **The interconnected network IS the propagation mechanism.** Any event that tweaks core dials on
|
||||
any system — corporate disaster, portal closing, political shift, successful development effort —
|
||||
propagates and rebalances through the trade/political network. Corporate disasters are ONE entropy
|
||||
source, not THE entropy source. Bulk import/export lists per system inform both simulation (trade
|
||||
flows) and content (what's on store shelves). Set up the propagation properly and emergence
|
||||
follows naturally.
|
||||
|
||||
**Background simulation workshop design brief (PO):** Model bulk trade flows between systems with
|
||||
corporate facility dependencies, political pressure, and disaster injection. Central challenge is not
|
||||
"keep it chaotic" but **"set up propagation properly."**
|
||||
|
||||
**Nigel's convergence concern, recontextualised:** The invariants-vs-variables framing still holds,
|
||||
but the threat model changes. The question is not "will the simulation converge toward boring
|
||||
equilibria" but "will equilibria be legible enough for players to read and act on." Equilibrium is
|
||||
a valid game state IF the player can see what caused it and what would disrupt it.
|
||||
|
||||
**Miri's cultural texture concern, recontextualised:** The exceptional settlement histories
|
||||
(refugee colonies, Perpetual Founder Stamps, Gate Silence survivors) must still be resilient
|
||||
against normalisation — but this is now an authoring concern (their distinctiveness must be
|
||||
robustly authored in wiki content) more than a simulation tuning concern.
|
||||
|
||||
**Status:** Reframed. The background simulation workshop has a concrete design brief. The central
|
||||
engineering question is now trade flow propagation architecture, not divergence preservation.
|
||||
|
||||
---
|
||||
|
||||
### 3.4 Simulation event density for environmental archaeology
|
||||
|
||||
Real-event-only archaeology (no fabricated history) is the right design position for integrity.
|
||||
But it demands the simulation produce enough physically-observable events at sufficient frequency
|
||||
to give the world its historical texture. If the background sim mostly produces economic numbers
|
||||
(prices, worker counts), there is nothing to leave physical traces of.
|
||||
|
||||
**Ozzie:** "The world will feel like it has financial history but no human history."
|
||||
**Nigel:** Need a minimum density of world-marking events per district per in-game year as a
|
||||
simulation design requirement.
|
||||
**Gestalt:** Pre-play simulation strategy (how much background sim runs before player's first move)
|
||||
is the related question.
|
||||
|
||||
**Status:** Unresolved. Simulation design target needed.
|
||||
|
||||
---
|
||||
|
||||
### 3.5 Galaxy map visual design — nobody has asked it yet
|
||||
|
||||
Full information from start means the galaxy map is the first impression of the universe. 300
|
||||
named systems exist. But 300 dots that all look the same are homework. The emotional experience
|
||||
of the galaxy map — colour washes for faction territory, economic signal visible at a glance,
|
||||
visited vs unvisited, visual rhythm that lets your eye land on a name and feel something — is
|
||||
entirely a visual design question that nobody has addressed.
|
||||
|
||||
**Ozzie:** "The reward has to come from VISITING a named place, not from REVEALING it. That's a
|
||||
different dopamine loop. It has to be designed intentionally."
|
||||
|
||||
**Status:** Unaddressed. Flagged for Araminta (visual design).
|
||||
|
||||
---
|
||||
|
||||
### 3.6 NPC-driven generation: canonical or seeded neighbourhood?
|
||||
|
||||
When a player befriends Kael from Tau Ceti and Kael's neighbourhood generates — is it:
|
||||
- **Canonical:** Every player who befriends a Tau Ceti resident gets the same neighbourhood,
|
||||
consistent with the authored wiki state. Creates shared reference points.
|
||||
- **Seeded per run:** This Kael's specific neighbourhood is procedurally unique. Creates unique
|
||||
per-run experiences.
|
||||
|
||||
**Nigel's FQ3.** Both are valid design positions with very different comparison-test experiences.
|
||||
**Status:** Unresolved. Needs product owner input.
|
||||
|
||||
---
|
||||
|
||||
### 3.7 GTTR expectation vs. simulation delivery
|
||||
|
||||
The GTTR entry is authored at a point in time. The simulation has been running. If reality
|
||||
diverges significantly from the GTTR description, the player either finds it exciting (world
|
||||
has moved on, I can read why) or jarring (I was lied to).
|
||||
|
||||
**Ozzie's test:** "Read a GTTR entry, land, play for 30 minutes. Does the GTTR's description
|
||||
feel TRUE?" If the simulation has depopulated a system the GTTR called warmly communal — what
|
||||
does the player feel?
|
||||
|
||||
**Status:** Cannot be resolved in design. Needs playtest data.
|
||||
|
||||
---
|
||||
|
||||
### 3.8 Critical path has shifted — background simulation is the new load-bearing wall
|
||||
|
||||
Tyre's primary contribution is a revised cost estimate and a named critical-path shift.
|
||||
|
||||
**The fundamental change:** The pipeline moves from **procedural generation grammar → world out** to
|
||||
**authored content pipeline with simulation-driven drift.** This simplifies some layers and adds others.
|
||||
|
||||
**What got cheaper:**
|
||||
|
||||
| Layer | R1b estimate | Revised | Why |
|
||||
|-------|-------------|---------|-----|
|
||||
| Layer 2: Location profiles | 3-4 weeks | 1-2 weeks | Wiki ingestion replaces generation grammar |
|
||||
| Layer 3: Topography | days-to-5 weeks | 1-2 weeks | Authored map ingestion replaces terrain gen |
|
||||
| Seed-based variety | implicit cost | removed | No seed variation in the model |
|
||||
|
||||
**What's new and expensive:**
|
||||
|
||||
| System | Estimate | Notes |
|
||||
|--------|---------|-------|
|
||||
| Background pressure simulation | 9-14 weeks | Economic + social + political. Needs own workshop. |
|
||||
| LOD simulation primitives | 3-5 weeks | 4-level business sim, component promotion model |
|
||||
| NPC/news generation hooks | 2-3 weeks | On-demand generation from simulation events |
|
||||
| Authored content pipeline | 2-3 weeks | Wiki → data, map → constraints, GTTR compilation |
|
||||
|
||||
**Revised total: ~30-50 weeks** (up from 20-30, but better risk profile — open-ended generation
|
||||
grammar risk replaced by well-understood data pipeline work).
|
||||
|
||||
**Critical path (old):** Layer 2 grammar → Layer 6 settlement → Layer 7 districts
|
||||
**Critical path (new):** Background simulation design → Pressure-to-entity bridge → Phase 1/2 reading pressure state
|
||||
|
||||
**Don't start background sim engineering until the dedicated workshop produces a pressure model spec.**
|
||||
This is Tyre's strongest recommendation and aligns with Gestalt and Nigel.
|
||||
|
||||
---
|
||||
|
||||
### 3.9 Background simulation architecture: tokio tasks recommended
|
||||
|
||||
Tyre assessed three architectural options for background simulation on spare CPU cores:
|
||||
|
||||
| Option | Mechanism | Recommendation |
|
||||
|--------|-----------|----------------|
|
||||
| A. bevy_ecs gated SystemSets | Same World, conditional run_if schedule | Background gets squeezed when active sim spikes |
|
||||
| B. Separate bevy App | Parallel World + channel communication | Data sync complexity; entity state serialization across Worlds |
|
||||
| **C. tokio async tasks** | **Outside ECS, snapshot/delta channels** | **Recommended: CPU capping trivial, no ECS needed for aggregate data** |
|
||||
|
||||
Background sim operates on *aggregate* data (system-level economics, faction influence, population
|
||||
indicators) — not per-entity ECS queries. An ECS is the wrong tool for "calculate GDP drift for
|
||||
300 star systems." tokio tasks with a deterministic game-minute clock is the right pattern.
|
||||
|
||||
**Key D-010 risk:** Background sim must be gated on game-minute clock, NOT wall-clock time.
|
||||
Variable CPU availability must not produce different simulation states on different hardware.
|
||||
Deterministic clock → deterministic results (slower machines accrue sim debt but produce
|
||||
identical results when they catch up). This is the frame-independent physics pattern.
|
||||
|
||||
**Two-layer model:**
|
||||
|
||||
| Layer | Scope | Runs where | Updates |
|
||||
|-------|-------|-----------|---------|
|
||||
| Entity simulation (D-026 tiers) | Per-NPC: movement, dialogue, perception | bevy_ecs main tick | Every tick (Active) or game-minute (Background) |
|
||||
| Pressure simulation (new) | Per-system/settlement: economic health, faction balance, social tension | tokio background tasks | Every game-minute or game-hour |
|
||||
|
||||
---
|
||||
|
||||
### 3.10 Technical risks flagged by Tyre
|
||||
|
||||
| Risk | Severity | Mitigation |
|
||||
|------|---------|-----------|
|
||||
| Background sim non-determinism from variable CPU timing | HIGH | Gate on game-minute clock, apply results in fixed order |
|
||||
| Background sim design underspecified | HIGH | Don't start engineering until workshop produces pressure model spec |
|
||||
| Content authoring bottleneck blocks engineering testing | MEDIUM | Placeholder generation from systems.db attributes; mark as "generated, not reviewed" |
|
||||
| Cultural framework in flux delays room grammar implementation | MEDIUM | Lock cultural input format early — labels can change, data shape shouldn't |
|
||||
| Authored world maps — format not decided | MEDIUM | See section 3.1; decide format in this workshop |
|
||||
| LOD transition edge cases (player sells a business) | LOW | Design demotion rules alongside promotion rules; snapshot on demotion |
|
||||
|
||||
---
|
||||
|
||||
## 4. New Follow-Up Questions for Next Interview Round
|
||||
|
||||
Grouped by theme. Sources noted.
|
||||
|
||||
### Theme A: Simulation Architecture (pre-empts the background sim workshop)
|
||||
|
||||
| # | Question | Source | Why load-bearing |
|
||||
|---|----------|--------|-----------------|
|
||||
| A1 | What is the simulation's divergence-preservation mechanism? What ensures run trajectories stay different rather than converging toward equilibrium? | Nigel FQ1 | Entire replayability model rests on this. |
|
||||
| A2 | Does the canonical starting state have any run-start stochastic variation, or is it exactly identical every run? | Nigel FQ2 | Even small variation (5% band on faction standings) produces trajectory divergence much faster than zero variation. |
|
||||
| A3 | What is the minimum simulation event density needed per district per in-game year for environmental archaeology to work? | Nigel FQ4, Ozzie | Simulation design target needed before the sim workshop. |
|
||||
| A4 | What is the pre-play simulation strategy — how much background sim runs before the player's first move? (Options: none / fast-forward / pre-authored canonical events / hybrid) | Gestalt Q4 | Without pre-play history, first location has no archaeology. |
|
||||
| A5 | How does the tycoon interact with simulation drift? Can the simulation close a player-owned bar? Can the player resist economic pressure? | Nigel FQ5 | Determines whether simulation drift affects player's story or just background. |
|
||||
|
||||
### Theme B: World Map Format (gates layers 3-6)
|
||||
|
||||
| # | Question | Source | Why load-bearing |
|
||||
|---|----------|--------|-----------------|
|
||||
| B1 | What format do authored world maps take, and how does the generator consume them? (Image / structured GeoJSON-style zones / drawing tool with export / wiki table) | Gestalt Q1 | Everything at layers 3-6 depends on generator reading topographic data. |
|
||||
|
||||
### Theme C: NPC Generation
|
||||
|
||||
| # | Question | Source | Why load-bearing |
|
||||
|---|----------|--------|-----------------|
|
||||
| C1 | What is the minimum NPC data bundle at Phase 2 generation time? What must be generated immediately vs expanded on demand? | Gestalt Q2 | Every ambient NPC potentially becomes narrative. Bundle determines generation cost and save file size. |
|
||||
| C2 | Does NPC-driven generation produce canonical or seeded neighbourhoods? | Nigel FQ3 | Determines whether social exploration creates shared or unique per-run content. |
|
||||
| C3 | Is the NPC-driven generation hook visible to the player, or invisible? | Ozzie | Invisible = magic; visible = meta-knowledge. Instinct is invisible, but this needs confirmation. |
|
||||
|
||||
### Theme D: Cultural Cascade
|
||||
|
||||
| # | Question | Source | Why load-bearing |
|
||||
|---|----------|--------|-----------------|
|
||||
| D1 | Who validates the corridor-to-room-grammar mapping against the 301 wiki entries? | Miri Q-A | If derivations conflict with authored content, generator produces rooms inconsistent with the wiki. |
|
||||
| D2 | Does the industrial corridor overlay (MVG, Gate Corp, DSMC) modify room physical character, or only NPC composition? | Miri Q-B | Determines whether industrial overlays require room grammar authoring work. |
|
||||
| D3 | How does heritage_persistence in systems.db interact with hop-distance attenuation? Are they independent or redundant? | Miri Q-C | Needed to specify the attenuation function. |
|
||||
| D4 | How is the Perpetual Founder Stamp expressed at room level? Authored field? NPC encounter only? | Miri Q-D | Perpetual-Stamp systems have unique room identity from individual curation — needs a generation path. |
|
||||
|
||||
### Theme E: Visual Design
|
||||
|
||||
| # | Question | Source | Why load-bearing |
|
||||
|---|----------|--------|-----------------|
|
||||
| E1 | What does the galaxy map look like as an emotional object? Does it show faction territories, economic signals, visited/unvisited? | Ozzie | Full-info-from-start means the reward is VISITING, not REVEALING. This needs a designed dopamine loop. |
|
||||
|
||||
### Theme F: Engineering Fidelity and Scope (Tyre)
|
||||
|
||||
| # | Question | Source | Why load-bearing |
|
||||
|---|----------|--------|-----------------|
|
||||
| F1 | What LOD level does the background simulation need at launch? (LOD 1: economic pressure only / LOD 2: + social / LOD 3: full pressure model) | Tyre Q1 | LOD 1 ships in weeks. LOD 3 needs a full design workshop before engineering begins. Data architecture should support all levels from day one but simulation rules can layer. |
|
||||
| F2 | What format do authored world maps take? (Tagged JSON regions / annotated image + overlay / d2 vector maps / Tiled tilemap) Tyre recommends d2 vector topology first. | Tyre Q2 / Gestalt B1 | Generation needs topology data, not heightmaps. Format must be decided before ingestion pipeline is built. |
|
||||
| F3 | Does the background simulation use a deterministic game-minute clock, or wall-clock scheduling? (This directly affects D-010 compliance.) | Tyre Q3 | Variable CPU speed cannot produce different world states. Must be confirmed as part of background sim architecture. |
|
||||
|
||||
---
|
||||
|
||||
## 5. Agent Summary Table
|
||||
|
||||
| Agent | Primary contribution | Key tension identified | Follow-ups flagged |
|
||||
|-------|---------------------|----------------------|-------------------|
|
||||
| **Ozzie** | Player experience of PO decisions. GTTR warm arrival > cold orbital. NPC-driven generation hook = "the game." Galaxy map as emotional object unaddressed. | GTTR expectations vs simulation divergence. Archaeology event rate. Galaxy map visual design. | A3, E1 |
|
||||
| **Gestalt** | Generator architecture synthesis. Reader-and-filler framing. Economic cascade as spine. Heritage deprecation architectural consequences. 4 unresolved design questions. | World map format (gates layers 3-6). NPC universality requirement. Canonical state → deterministic generator. | A4, B1, C1, D1 |
|
||||
| **Miri** | Heritage root → corridor translation. Four bar descriptions as room grammar targets. Attenuation tier proposal. Industrial corridor as second modifier axis. | Corridor-to-room-grammar mapping not validated. Compound identity blending function unspecified. | D1, D2, D3, D4 |
|
||||
| **Nigel** | Replayability model shift acknowledged and mapped. Six replayability surfaces under new model. Simulation convergence as core architectural risk. NPC-driven generation as "explosive" replayability surface. | Simulation convergence (most serious risk). Cold-start metagaming. NPC locality bias. | A1, A2, A3, A5, C2 |
|
||||
| **Tyre** | Revised cost estimate. Reader-and-filler framing confirmed. Background sim as new critical path. tokio tasks architecture recommended. Determinism risk on background sim named. | Simulation convergence + D-010 risk. Content authoring bottleneck. World map format unspecified. Background sim scope underspecified. | F1, F2, F3 |
|
||||
|
||||
---
|
||||
|
||||
## 6. Background Simulation Workshop Brief — Mandatory Agenda Items
|
||||
|
||||
The following items must be explicitly addressed in the background simulation design workshop brief.
|
||||
They are architectural load-bearers, not enrichment.
|
||||
|
||||
| Item | Source | Why mandatory |
|
||||
|------|--------|--------------|
|
||||
| **Invariants vs variables** — which aspects of the world are designed to be stable reference points, and which are designed to stay chaotic and resist equilibrium? | Nigel (post-R2) | Without separating these, the simulation cannot be tuned. Invariants need authored starting state. Variables need divergence-preserving chaotic subsystems. |
|
||||
| **Propagation network architecture** — how do events that tweak core dials on any system propagate and rebalance through the trade/political network? Bulk import/export lists per system inform both simulation (trade flows) and content (what's on store shelves). | PO (R2 follow-up) / Nigel R2 | "Set up propagation properly and emergence follows naturally." The central challenge is propagation architecture, not divergence preservation. |
|
||||
| **Consistency layer for generation hooks** — when the storyteller generates a news event claiming a location exists, how does that become a real place the generator produces? What is the buffer between "claimed to exist" and "generator has produced"? | Gestalt (post-R2) | NPC-driven and news-driven generation are callable from social and narrative layers, not just player movement. The pipeline needs a consistency mechanism to ensure existence claims are resolved before the player arrives. |
|
||||
| **Pre-play simulation strategy** — what state is the world in when the player's first move happens? How much background sim runs before player control? | Gestalt (post-R2) / Gestalt Q4 | Load-bearing for environmental archaeology. If the sim hasn't run long enough before the player starts, the world has no traces and no history. The workshop needs a concrete answer on pre-game sim time or pre-authored canonical events. |
|
||||
| **Exception community resilience** — unusual settlement histories (refugee colonies, Perpetual Founder Stamp systems, Gate Silence survivors) must be resilient against simulated normalization, not just seeded. If the sim smooths these out over time, culturally distinctive room grammar loses its grounding. | Miri (post-R2) | Convergence risk has a direct cultural texture consequence. This constraint must be designed in, not left as an emergent property. |
|
||||
|
||||
---
|
||||
|
||||
## 7. Upstream Dependencies (in priority order)
|
||||
|
||||
Before the generator pipeline sub-workshops can proceed:
|
||||
|
||||
1. **Background simulation design workshop** (product owner flagged, confirmed by Gestalt and Nigel)
|
||||
— Replayability architecture, NPC evolution, archaeology all depend on it. Non-optional.
|
||||
|
||||
2. **World map format decision** (Gestalt Q1)
|
||||
— Blocks all generation below Layer 2. Must be decided before Settlement Placement (SW2 or SW3).
|
||||
|
||||
3. **Corridor-to-room-grammar document** (Miri)
|
||||
— Miri has a draft. Needs validation, industrial overlay specification, Araminta
|
||||
coordination for visual layer. Should feed Phase 2 room-fill specification.
|
||||
|
||||
4. **D-104, D-105 supersession** (flagged by Gestalt, Miri, Qatux)
|
||||
— D-records need formal closure. New D-record covering four-corridor framework to replace them.
|
||||
|
||||
5. **Minimum NPC data bundle specification** (Gestalt Q2)
|
||||
— Blocks Phase 2 NPC fill design. Must be specified before the NPC generation architecture
|
||||
is finalised.
|
||||
|
||||
---
|
||||
|
||||
*— Qatux, 2026-03-24*
|
||||
@@ -0,0 +1,171 @@
|
||||
# Tyre — SW1-R1: Feasibility Guardrails for Generation Scope
|
||||
|
||||
**Sub-workshop 1, Round 1 — Technical Feasibility Assessment**
|
||||
|
||||
---
|
||||
|
||||
## Feasibility Cheat Sheet
|
||||
|
||||
### Already Built and Working
|
||||
|
||||
| Component | Location | What It Does |
|
||||
|---|---|---|
|
||||
| `DistrictSkeleton` data model | `server/src/simulation/generator.rs` | Full type hierarchy: districts → blocks → chunks, social sites, reservations, z-levels, palettes, mutations. 579 lines of typed structs/enums. |
|
||||
| Chunk streaming system | `server/src/simulation/chunk_streaming.rs` | Load/unload chunks by Chebyshev distance from player. Cadence-gated (every 10 ticks). Configurable radius. |
|
||||
| Movement + walkability | `server/src/simulation/movement.rs` | `WalkabilityMap` with per-chunk `BTreeMap` storage, `TileKind` (Floor/Wall/Void/Restricted), `TilePosition`, `ChunkCoord` (with z). 32×32 tiles per chunk. |
|
||||
| Tile renderer (placeholder) | `client/scripts/rendering/tile_renderer.gd` | `TileMapLayer` with colored rectangles for 5 tile types. Processes tile data from `ObserverSnapshot`. |
|
||||
| World renderer pipeline | `client/scripts/rendering/world_renderer.gd` | D-049 z-stack: FogGroup → FloorTiles + Entities + FogOverlay. Tick-based invalidation. |
|
||||
| Dual-scale grid | D-066 confirmed | 0.5m sim tiles, 1m visual tiles. 2:1 retina factor. Server knows only sim tiles. |
|
||||
| 3D camera system | D-148 confirmed | 30° tilt, 45° diamond rotation. Real Camera3D, not sprite faking. |
|
||||
| 3D character rendering | D-149 confirmed | Live 3D models via `CharacterCompositor`. Sprint 28 in progress. |
|
||||
|
||||
### Stubbed but Needs Implementation
|
||||
|
||||
| Component | Status | What's Missing |
|
||||
|---|---|---|
|
||||
| Generator type aliases | `generator.rs` lines 39–96 | 27 stub types (all `String` or `Vec<bool>`). No actual generation logic — just the output shape. |
|
||||
| Phase 1 (skeleton generation) | Data model complete | No algorithm to *produce* a `DistrictSkeleton` from a seed + constraints. |
|
||||
| Phase 2 (chunk fill) | Architecture defined | No tile-level fill logic. `GeneratorChunkData` is `Vec<bool>`. |
|
||||
| `ZonePalette` system | Struct defined | No palette data, no heritage→material mapping. |
|
||||
| `WallBackside` | Enum defined | No assignment logic during chunk fill. |
|
||||
| `GuaranteeAuditResult` | `String` stub | No audit implementation. |
|
||||
| `MobileChunk` | D-108 spec complete | No structs in code yet. |
|
||||
| `ChunkMutations` | Struct defined | No mutation application logic. |
|
||||
|
||||
### Easy to Add (days)
|
||||
|
||||
| Feature | Effort | Why It's Cheap |
|
||||
|---|---|---|
|
||||
| Template-stamped room generator | 2–3 days | Define room templates as 2D tile grids, stamp them into chunk data. No algorithmic complexity. |
|
||||
| Corridor carving between rooms | 1–2 days | A* or L-shaped corridors between room centers. Well-understood problem. |
|
||||
| Tile palette → 3D mesh mapping | 2–3 days | Each TileKind maps to a MeshLibrary entry. GridMap or manual mesh placement. |
|
||||
| Noise-based district type assignment | 1 day | FastNoiseLite (built into Godot), or Rust noise crate on server side. Threshold → district type. |
|
||||
| Single-z-level GridMap rendering | 2–3 days | Replace TileMapLayer with GridMap for floor rendering. Straightforward migration. |
|
||||
| Z-level selector (UI toggle) | 1 day | Filter tiles by z in renderer, add UI button. No new rendering tech. |
|
||||
|
||||
### Hard to Add (weeks+)
|
||||
|
||||
| Feature | Effort | Why It's Hard |
|
||||
|---|---|---|
|
||||
| Full Phase 1 with guarantee audit | 3–4 weeks | Combinatorial satisfaction: place 16 blocks, assign zoning, enforce 13 guarantee checks, vary per seed. Essentially a constraint solver. |
|
||||
| WFC or grammar-based building interiors | 2–3 weeks | WFC requires careful tile adjacency ruleset authoring + solver tuning. Grammar-based requires defining the grammar. Both need extensive iteration. |
|
||||
| Multi-z-level rendering with cutaway | 2–3 weeks | Transparency masking, depth sorting, camera-relative culling. Godot's render pipeline doesn't natively support "hide floors above camera" for isometric. Needs custom shader work. |
|
||||
| Organic layout mode | 1–2 weeks | Block rotation/offset (D-096) creates non-axis-aligned boundaries. Pathfinding across rotated blocks, stitching streets at junctions, handling the 45° rotation cap. |
|
||||
| Cross-district boundary stitching | 2–3 weeks | Adjacent districts must have matching access points, consistent road networks, and aligned chunk edges. Generator must know neighbor state. |
|
||||
| Full ZonePalette with cultural modifiers | 2–3 weeks | 8 base terrain types × N heritage roots × N era layers × condition modifiers. Asset authoring dominates. |
|
||||
| 2D→3D rendering migration | 2–4 weeks | The current pipeline is Node2D + TileMapLayer. D-148/D-149 put us in 3D space. Fog shader, entity rendering, z-stack — all need migration. This is happening anyway but blocks generation rendering. |
|
||||
|
||||
### Reference Implementations — Relevance Assessment
|
||||
|
||||
| Reference | Relevance to Our Stack | Verdict |
|
||||
|---|---|---|
|
||||
| **CityCrafter3D** | **HIGH.** District→block→building pipeline maps to our hierarchy. Noise-based district assignment, density control, subdivision — all patterns we need. Godot 4.4, GDScript. BUT: generation is client-side (we need server-side Rust). Study the *algorithm*, not the code. |
|
||||
| **GridMapLayer** | **HIGH.** 2D tile data → 3D GridMap rendering is exactly our client-side need. TileMapLayer→GridMap bridge with subdivision support. Study for the client rendering upgrade. |
|
||||
| **Chunk Manager** | **MEDIUM.** Basic pattern matches ours but we already have a more sophisticated implementation in `chunk_streaming.rs`. Useful as a sanity check, not as a source of new patterns. |
|
||||
| **RetroTerrain** | **MEDIUM.** Procedural mesh + height shader is relevant for wilderness zones. BUT: crashes at 1000×1000 (their words), no chunking. We'd need the shader technique, not the generation approach. |
|
||||
| **PathMesh3D** | **MEDIUM.** Path extrusion for corridors, pipes, conduits — relevant for station interior detail (cables, ductwork). GDExtension (C++), performant. Future use, not v0.2 critical. |
|
||||
| **Block-based Procedural Map** | **LOW-MEDIUM.** Perlin noise + chunk loading — patterns we already know. Useful as a Godot 4.2 reference for seed determinism. |
|
||||
| **Spatial Gardener** | **LOW.** Manual brush painting, not procedural. Wrong paradigm — we need server-driven placement. The octree LOD concept is worth noting for future vegetation density, but not actionable now. |
|
||||
| **DeformableMesh** | **LOW.** Runtime mesh deformation for variety. Interesting for "make crates look different" but Godot 4.5+ required and not performance-optimized. Future nice-to-have. |
|
||||
| **SunshineClouds** | **LOW.** Volumetric cloud rendering — we'd only want the ground shadow dappling shader, which is a small extract. Not a priority for generation architecture. |
|
||||
|
||||
---
|
||||
|
||||
## Questions for the Product Owner
|
||||
|
||||
### Q1: What SettingType(s) ship in v0.2?
|
||||
|
||||
The generator data model supports 8 SettingTypes (Station, Urban, Agricultural, Maritime, Wilderness, Water, Transitional, Orbital, Specialized). Each needs its own generation grammar, tile palette, and social site placement rules.
|
||||
|
||||
**Technical tradeoff:** Each SettingType is essentially a separate generator. Station interiors (corridors + rooms + modules) are algorithmically different from Urban (streets + lots + buildings) which is different from Wilderness (terrain + vegetation + paths). Sharing infrastructure between them is possible but the tile-level generation logic is unique per type.
|
||||
|
||||
| Option | Cost | What You Get |
|
||||
|---|---|---|
|
||||
| A. Station only | **Small** (2–3 weeks for basic generator) | Corridors, rooms, airlocks, modules. Proves the entire pipeline end-to-end. Matches "first location the player sees" in many scenarios. |
|
||||
| B. Station + Urban | **Medium** (4–6 weeks) | Adds streets, building lots, exteriors. Two visually distinct zone types. Covers docking → city gameplay loop. |
|
||||
| C. Station + Urban + Wilderness | **Large** (7–10 weeks) | Adds terrain, vegetation, paths. Three zones. Full planet surface experience. Wilderness is algorithmically simplest but needs the most art assets. |
|
||||
| D. All SettingTypes | **Very large** (12+ weeks) | Full world variety. Not recommended for v0.2. |
|
||||
|
||||
**My recommendation:** **Option A** for v0.2 core, with Urban as a fast-follow. Station interiors are the most constrained environment (walls everywhere, clear rooms, obvious pathfinding) — they're the easiest to generate well and the hardest to generate badly. Prove the pipeline works before expanding surface area.
|
||||
|
||||
---
|
||||
|
||||
### Q2: What building/room generation algorithm?
|
||||
|
||||
We need to fill blocks with rooms, corridors, and spatial structure. The data model is ready. The algorithm choice determines quality ceiling AND iteration cost.
|
||||
|
||||
**Technical tradeoff:** Simpler algorithms are faster to implement but produce more repetitive output. Complex algorithms produce better variety but are harder to tune and debug — especially with our determinism requirement (D-010 principle 4, BTreeMap everywhere, no HashMap, no f32 in generation paths).
|
||||
|
||||
| Option | Cost | Quality | Determinism Risk |
|
||||
|---|---|---|---|
|
||||
| A. Template stamping + variation | **Small** (1–2 weeks) | Medium — recognizable patterns, seed-driven variation in rotation/mirroring/detail | **Zero** — templates are static data, placement is index math |
|
||||
| B. BSP (Binary Space Partition) room subdivision | **Small-Medium** (2 weeks) | Good — natural room variety, recursive split produces organic-feeling layouts | **Low** — pure integer math, well-understood algorithm |
|
||||
| C. Grammar-based (L-system / shape grammar) | **Medium** (3–4 weeks) | High — rule-driven expansion produces culturally coherent spaces | **Low** — rules are deterministic by definition, but debugging grammar rules is tedious |
|
||||
| D. Wave Function Collapse (WFC) | **Large** (4–6 weeks) | Very high — maximum local variety while maintaining adjacency rules | **MEDIUM** — WFC propagation order can diverge on different platforms if not carefully constrained. Backtracking adds complexity. |
|
||||
|
||||
**My recommendation:** **Option B (BSP) as the core algorithm, with template stamping for special rooms.** BSP is the Dwarf Fortress / roguelike standard for good reason — it produces natural room layouts with zero tuning, runs in microseconds, and is trivially deterministic. Stamp social-site templates (bars, offices, medical bays) into BSP-carved spaces. Grammar-based can layer on top later for cultural variation. WFC is fascinating but the tuning cost is high and the determinism risk is real with D-010.
|
||||
|
||||
---
|
||||
|
||||
### Q3: 2D TileMapLayer → 3D rendering migration — when?
|
||||
|
||||
**This is the elephant in the room.** The current rendering pipeline is 2D (`Node2D` + `TileMapLayer`). D-148 confirms a 30° Camera3D. D-149 confirms 3D character models. The world renderer needs to go 3D to match. Generation output format depends on this decision.
|
||||
|
||||
**Technical tradeoff:** If we generate for 2D rendering, we're building throwaway work. If we generate for 3D rendering, we need the 3D renderer first. The generation pipeline and the rendering pipeline are coupled at the tile data format level.
|
||||
|
||||
| Option | Cost | Risk |
|
||||
|---|---|---|
|
||||
| A. Generate for 2D now, migrate later | **Small** for generation, **Medium** for migration tax later | Double work: tile format changes, renderer rewrite, fog shader migration |
|
||||
| B. Migrate renderer to 3D first, then generate | **Medium** (2–4 weeks for renderer migration) | Blocks generation work until renderer is ready. But generation output is correct from day one. |
|
||||
| C. Generate for 3D from start, temporary 2D renderer | **Small-Medium** | Server generates 3D-ready data (tile + z-level + height). 2D renderer ignores z/height, just renders floor. 3D renderer replaces it when ready. No double work. |
|
||||
|
||||
**My recommendation:** **Option C.** The server doesn't care about rendering — it generates tile grids with z-level and TileKind data. The current TileMapLayer renderer already ignores z > 0 (line 91 of `tile_renderer.gd`: `if tile_z != GROUND_FLOOR: continue`). Generate 3D-ready data, let the 2D renderer display what it can, upgrade the renderer separately. Zero throwaway work.
|
||||
|
||||
---
|
||||
|
||||
### Q4: How detailed is Phase 2 chunk fill in v0.2?
|
||||
|
||||
Phase 2 takes a `BlockSkeleton` (from Phase 1) and fills it with actual tile data — walls, floors, doors, objects. The question is how much detail the fill produces.
|
||||
|
||||
**Technical tradeoff:** More detail means more visual richness but exponentially more generation rules. Objects (furniture, terminals, crates) need placement logic, collision, and eventually interaction — each is a mini-system.
|
||||
|
||||
| Option | Cost | What It Looks Like |
|
||||
|---|---|---|
|
||||
| A. Walls + floors only | **Small** (1 week) | Rooms exist, corridors connect them. Blank rooms. Playable for pathfinding and LOS testing. |
|
||||
| B. Walls + floors + doors + basic objects | **Medium** (2–3 weeks) | Rooms have doors, some furniture markers. Looks like a game level. |
|
||||
| C. Full fill with WallBackside, object placement, condition modifiers | **Large** (5–7 weeks) | Complete generator output matching the full data model. Every wall tagged, every room furnished. |
|
||||
|
||||
**My recommendation:** **Option B** for v0.2. Walls, floors, doors, and basic object placement (furniture as collision rectangles with a TileKind). This is the minimum to feel like a real space rather than a maze. WallBackside tagging (D-099) can wait — it's a data enrichment pass that adds zero visual difference.
|
||||
|
||||
---
|
||||
|
||||
### Q5: Full Phase 1 skeleton or simplified bootstrap?
|
||||
|
||||
The `DistrictSkeleton` is a rich data structure: 4×4 block grid, multi-block reservations, corridor spines, social sites, guarantee audit, zone palettes, cultural modifiers. Implementing the full Phase 1 generator that produces a valid `DistrictSkeleton` satisfying all guarantee tiers (D-097) is a significant engineering effort.
|
||||
|
||||
**Technical tradeoff:** The guarantee audit system (D-097) is essentially a constraint solver — place 16 blocks such that Tier 1 guarantees are met for all inhabited districts, Tier 2 for Full-complexity, and Tier 3 conditionally. This is the hardest part of Phase 1. Without it, generation is just "random blocks." With it, generation is "every district is playable."
|
||||
|
||||
| Option | Cost | What You Get |
|
||||
|---|---|---|
|
||||
| A. Hardcoded test skeleton | **Tiny** (1–2 days) | A single `DistrictSkeleton` literal in code. Proves Phase 2 works. No actual generation. |
|
||||
| B. Simple Phase 1 — random block assignment, no guarantees | **Small** (1–2 weeks) | Seed-driven block zoning. No guarantee audit. Some districts may lack required spatial affordances. |
|
||||
| C. Phase 1 with Tier 1 guarantees only | **Medium** (3–4 weeks) | Every inhabited district has a Social Hub, Informal Zone, and Encounter Corridor. Basic playability guaranteed. |
|
||||
| D. Full Phase 1 with all guarantee tiers | **Large** (5–7 weeks) | Full D-097 compliance. Up to 13 audit checks per Full-complexity coastal urban district. |
|
||||
|
||||
**My recommendation:** **Option B for v0.2, with the guarantee audit as a validation pass that logs warnings rather than blocks generation.** This lets us iterate on generation quality by reading audit output without blocking the pipeline. Promote to hard-fail (Option C/D) when the generator is mature enough that audit failures indicate real bugs rather than "feature not yet implemented."
|
||||
|
||||
---
|
||||
|
||||
## Architecture Compatibility Notes
|
||||
|
||||
### Determinism (D-010)
|
||||
All generation algorithms MUST use `BTreeMap` (not `HashMap`), seeded RNG via `SimRng`, and no `f32` in generation paths. BSP and template stamping are naturally deterministic. WFC requires careful propagation ordering to be deterministic — this is solvable but adds implementation cost. The existing codebase enforces this correctly (generator.rs uses `Vec` and fixed-size arrays, not `HashMap`).
|
||||
|
||||
### Camera/Rendering Tension
|
||||
D-148 (30° Camera3D) and D-149 (3D characters) are confirmed but the world renderer is still 2D. The generation pipeline should output data that's rendering-agnostic: tile grids with type + z-level + position. The client decides how to render. This is already the case in the data model — `ObserverSnapshot` sends tile data, the renderer interprets it.
|
||||
|
||||
### Wire Format
|
||||
The existing protocol sends individual tile dictionaries (`{x, y, z, type, visibility}`). For generated worlds with thousands of tiles, this will need chunked transmission — send a chunk's tile grid as a flat array rather than individual tile objects. This is a protocol optimization, not an architecture change. Estimate: 1 day when needed.
|
||||
|
||||
### Chunk Streaming
|
||||
`chunk_streaming.rs` already supports load/unload with configurable radius. For generated worlds, the `load_chunk` path needs a hook to trigger Phase 2 fill on first load. This is the designed extension point — the TODO is explicit in the code comments ("For v0.3+, the generator fills newly loaded chunks with terrain data"). Estimate: 1–2 days to add the generation callback.
|
||||
@@ -0,0 +1,411 @@
|
||||
# Tyre — SW1-R1b: Endgame Feasibility — Galaxy-to-Ground Pipeline Architecture
|
||||
|
||||
**Sub-workshop 1, Round 1b — Full Pipeline Technical Assessment**
|
||||
**No v0.2 scoping. Endgame vision, cost-annotated.**
|
||||
|
||||
---
|
||||
|
||||
## The Pipeline: 8 Layers, Top to Bottom
|
||||
|
||||
### Layer 1: Galaxy Generation (300 Systems)
|
||||
|
||||
**Status: LARGELY BUILT.**
|
||||
|
||||
This is the most mature layer in the entire pipeline. What exists:
|
||||
|
||||
| Component | Location | Status |
|
||||
|---|---|---|
|
||||
| `systems.db` | `server/data/systems-schema.sql` | 7 tables: star_systems, system_gates, system_history, system_economy, system_factions, system_culture, historical_events |
|
||||
| Wiki pages | `wiki/star-systems/GJ-*/index.md` | 300+ authored pages with supply dependency, faction notes, silence topics, narrative hooks, calibration notes |
|
||||
| Star map generation algorithm | `docs/design/star-map-plan.md` | 6-phase algorithm: sector seeding → Prim's spanning tree → hub/loop/spur augmentation → topology classification → aperture assignment → validation |
|
||||
| Generation script | `tooling/generate-star-map.py` | Python script producing `star-map.json` + sector d2 diagrams |
|
||||
| Gate topology data | `system_gates` table | aperture_count, gate_connections, gate_topology (hub/junction/loop_member/dead_end/spur_end), hop_distance_from_gateway |
|
||||
| Cultural data | `system_culture`, `system_history` tables | founding culture, cultural corridor, heritage persistence, ambient anxiety, silence threshold |
|
||||
|
||||
**What the runtime generator needs from this layer:**
|
||||
|
||||
The game server reads `systems.db` at startup and builds an in-memory graph. Each system node carries its profile (tier, setting types, cultural corridors, economic base, faction presence). When the player travels to a system for the first time, the generator receives the system profile as input and begins cascading downward.
|
||||
|
||||
**Cost annotation:** Galaxy generation is a **content authoring** problem, not an engineering problem. The database schema exists. The wiki pipeline exists. The engineering work is loading `systems.db` into the Rust server at startup and building a queryable graph — **cheap** (days). The ongoing cost is authoring/reviewing the 300 wiki entries — that's Miri/Mellanie/Paula territory.
|
||||
|
||||
**What's technically hard:** Nothing. This layer is fundamentally a read-only dataset with graph queries.
|
||||
|
||||
**What's technically cheap:** Everything. BFS pathfinding, neighbor lookup, attribute filtering — all standard graph operations on 300 nodes. Fits comfortably in memory (~1-2MB structured data).
|
||||
|
||||
---
|
||||
|
||||
### Layer 2: Location Profiles (Per-Planet/Station/Moon)
|
||||
|
||||
**Status: NOT BUILT — the biggest structural gap.**
|
||||
|
||||
The systems.db records that "GJ-699 has 2 habitable planets, 0 inhabited, no gas giant." But there are no individual planet/station/moon records. The jump from "system has 2 habitable planets" to "here is a specific planet with biome X, atmosphere Y, population Z" is entirely undefined.
|
||||
|
||||
**What needs to exist:**
|
||||
|
||||
```
|
||||
SystemProfile (from systems.db)
|
||||
└─ LocationProfile[] (new — per planet/station/moon/orbital)
|
||||
├─ location_type: Planet | Station | Moon | Orbital | AsteroidBase
|
||||
├─ physical: gravity, atmosphere, biome_zones[], terrain_type, hydrosphere_pct
|
||||
├─ settlement: population, economic_role, founding_age, settlement_pattern
|
||||
├─ cultural: heritage_blend (from system corridor + founding culture + local drift)
|
||||
├─ infrastructure: spaceport_class, transit_connections, district_count
|
||||
└─ districts[] → feeds into Layer 6
|
||||
```
|
||||
|
||||
**Cost annotation:**
|
||||
|
||||
| Approach | Cost | Quality |
|
||||
|---|---|---|
|
||||
| Derived from system profile (algorithmic) | **Medium** (2-3 weeks) | Good — each system's attributes constrain what planets look like. A core-sector, wave-1, economic-tier-5 system doesn't have a frontier mining colony. |
|
||||
| Hand-authored per inhabited planet | **Very large** (months of authoring for 300+ locations) | Excellent — every planet is unique. But doesn't scale. |
|
||||
| Hybrid: authored for narrative-notable, generated for the rest | **Medium-Large** (3-4 weeks engineering + ongoing authoring) | Best of both — ~30-40 hand-crafted locations, ~260 generated with authored review passes. |
|
||||
|
||||
**My assessment:** The hybrid approach is the right answer and probably the only sane one. `systems.db` already tags `narrative_notable` systems. Those get hand-authored location profiles. The rest derive their profile from the system's attributes using a generation grammar:
|
||||
|
||||
- `economic_base: manufacturing` + `inhabited_planet_count: 2` → primary planet is industrial + orbital station, secondary planet is residential/agricultural
|
||||
- `gate_topology: hub` + `economic_tier: 4+` → mandatory horizon station with large commercial district
|
||||
- `cultural_corridor: tide` + `settlement_wave: wave_3` → heritage blend weights favor Tide-root architecture
|
||||
|
||||
**What's technically hard:** The generation grammar itself. Mapping ~30 system attributes to coherent planet profiles requires careful constraint satisfaction. The grammar must not produce contradictions (an "economic_tier: 1" system shouldn't generate a bustling metropolis). Authoring and validating the grammar rules is iterative.
|
||||
|
||||
**What's technically cheap:** The data structures. Adding a `locations` table to `systems.db` and a `LocationProfile` Rust struct is straightforward.
|
||||
|
||||
---
|
||||
|
||||
### Layer 3: Planetary Topography
|
||||
|
||||
**Status: NOT BUILT — but the solution space is well-understood.**
|
||||
|
||||
Once we know a planet has biome zones, terrain type, and hydrosphere percentage, we need a surface. The question is: how detailed?
|
||||
|
||||
**The key insight: we don't need a real planet.** The player arrives at a specific location (gate → horizon station → transit → destination). They don't see the whole planet. They see a district, maybe neighboring districts. Planetary topography is a *context* that constrains district generation — "this district is on a coastal plain" or "this district is in a mountain valley" — not a renderable globe.
|
||||
|
||||
**Three approaches with very different costs:**
|
||||
|
||||
| Approach | Cost | What You Get |
|
||||
|---|---|---|
|
||||
| A. **Abstract topography tags** — each location gets tagged (coastal/mountain/desert/plains/tundra/oceanic/orbital). Tags constrain district generation SettingType + terrain palette. No actual terrain data. | **Cheap** (days) | Sufficient for district-level generation. "Coastal urban district" or "mountain wilderness district." The player never flies over the planet — they arrive at a point and explore outward. |
|
||||
| B. **Noise-based regional heightmap** — per-location Perlin/simplex noise heightmap at ~1km resolution. River placement via hydraulic erosion simulation. Biome assignment from elevation + latitude + moisture. | **Medium** (3-5 weeks) | A terrain you can zoom into. District placement becomes geographically motivated (cities on rivers, ports on coasts). The player's minimap can show regional context. |
|
||||
| C. **Full planetary generation** — plate tectonics, erosion simulation, climate modeling, ocean currents. Dwarf Fortress / Caves of Qud territory. | **Very large** (months) | A planet that makes geological sense. Beautiful, scientifically plausible, and almost entirely invisible to the player at ground level. |
|
||||
|
||||
**My assessment:** **Approach A for the immediate pipeline, with B as the enrichment that makes the minimap/world-map feel real.** Here's why:
|
||||
|
||||
The camera is at 30° (D-148), looking at a 512×512 district. The player sees maybe 50-100 visual tiles at a time. Planetary topography below district granularity is *literally invisible* at this camera angle. What the player *does* see is whether they're in a desert, by the ocean, or in mountains — and that's communicated by the district's SettingType and palette, not by a heightmap.
|
||||
|
||||
Approach B becomes valuable when you have a world map or minimap showing the region — "there's a mountain range to the west, a river delta to the south." That's a navigation/exploration feature, not a generation prerequisite.
|
||||
|
||||
**RetroTerrain reference:** Their approach (noise → heightmap → vertex colors → shader-based terrain painting) maps to Approach B. It's clean and well-understood. BUT: they crash at 1000×1000 because they don't chunk. We'd need to add chunking (which we already have infrastructure for). The terrain shader technique is directly applicable to our wilderness SettingType rendering.
|
||||
|
||||
**What's technically hard in Approach B:** Hydraulic erosion simulation (realistic river placement). Well-studied algorithm but computationally expensive — doing it at world-gen time (offline) is fine, doing it at runtime is not. Pre-generation with seed caching solves this.
|
||||
|
||||
**What's technically cheap:** Noise-based heightmaps. FastNoiseLite in Godot, the `noise` crate in Rust. Biome assignment from elevation thresholds is trivial.
|
||||
|
||||
---
|
||||
|
||||
### Layer 4: Inbound Gateways — What's Around Arrival Points
|
||||
|
||||
**Status: PARTIALLY DESIGNED (D-093, D-095), NOT BUILT.**
|
||||
|
||||
When the player arrives in a new system, they come through a horizon gate. D-095 defines the lore (alien-built gate infrastructure, aperture counts, the entire transit model). D-093 defines the gate cluster spatial layout within a district.
|
||||
|
||||
**What needs generation:**
|
||||
|
||||
1. **The horizon station itself** — a Station SettingType district. The gate cluster occupies one or more blocks. Institutional presence (Commission inspection, Institute monitoring) varies by system importance.
|
||||
2. **The transit connection** — how the player gets from the horizon station to their destination planet/station. This is either a skip-travel mechanic or a playable transit sequence (ship/shuttle interior as a MobileChunk per D-108).
|
||||
3. **The first impression** — what the player sees when they step off the gate platform. This is a spatial design problem, not just a generation problem.
|
||||
|
||||
**Cost annotation:**
|
||||
|
||||
| Component | Cost | Notes |
|
||||
|---|---|---|
|
||||
| Horizon station as a Station district | **Included in Station SettingType** — no separate cost | It's just a Station district with gate-specific blocks (gate cluster, customs, transit hub) |
|
||||
| Transit skip-travel | **Cheap** (days) | Loading screen with diegetic framing — "transit in progress." The MobileChunk vessel interior is optional enrichment. |
|
||||
| MobileChunk transit (playable voyage) | **Medium** (2-3 weeks per D-108) | Vessel interior as a social pressure cooker. High-value content but not a generation prerequisite. |
|
||||
| "First impression" spatial design | **Cheap as generation, hard as design** | The generator places the gate cluster at a specific block. What's visible from that block's entrance is a function of the district layout. Guarantee system (D-097) can ensure an Encounter Corridor is visible from the gate entry point. |
|
||||
|
||||
**What's technically hard:** Making the first impression *good*. The generator can produce a syntactically correct horizon station, but the spatial experience of stepping through a gate into a new system is a design problem — it requires the guarantee system to enforce experiential constraints ("from the gate entry, the player must see at least one zone transition within 30 tiles").
|
||||
|
||||
**What's technically cheap:** The generation itself. A horizon station is a Station district. Gate blocks are template-stamped special rooms.
|
||||
|
||||
---
|
||||
|
||||
### Layer 5: Content Spidering — LOD/Simulation-Tier Generation
|
||||
|
||||
**Status: ARCHITECTURE DESIGNED (D-026), STREAMING BUILT, GENERATION HOOKS NOT BUILT.**
|
||||
|
||||
This is where the simulation tier system (D-026) meets the generation pipeline. The four tiers:
|
||||
|
||||
| Tier | What Exists | What's Generated | When |
|
||||
|---|---|---|---|
|
||||
| **Ungenerated** | Nothing. System exists in `systems.db` graph. | — | Player has never visited or approached. |
|
||||
| **State-saved** | LocationProfile (Layer 2) + DistrictSkeleton (Phase 1). No tile data. ~1-2KB per district skeleton. | Phase 1 skeleton generated on first "approach" (player enters the system, or a connected system). | **On system entry** — background generation of neighbor systems' skeletons. |
|
||||
| **Background** | Phase 1 skeleton + Phase 2 fill for districts near the player's destination. Tile data exists. NPC state machines run at 1/game-minute. | Phase 2 chunk fill triggered on district entry. | **On transit approach** — background generation during travel loading. |
|
||||
| **Active** | Full sim. All chunks loaded within streaming radius. Full NPC simulation at 10 tps. | Already generated — just loaded from cache. | **On arrival** — chunk streaming activates from cache/generated data. |
|
||||
|
||||
**The generation cascade:**
|
||||
|
||||
```
|
||||
Player enters system (gate transit)
|
||||
├─ If system is Ungenerated:
|
||||
│ ├─ Generate LocationProfiles for all bodies in system (Layer 2)
|
||||
│ ├─ Generate Phase 1 skeletons for player's destination + immediate neighbors
|
||||
│ └─ Background-generate Phase 1 for remaining districts (async)
|
||||
├─ If system is State-saved:
|
||||
│ ├─ Load existing skeletons from save
|
||||
│ └─ Generate Phase 2 for destination district (if not already filled)
|
||||
└─ Player arrives at district:
|
||||
├─ Load/generate Phase 2 chunks within streaming radius
|
||||
├─ Activate NPCs in loaded chunks (D-026 tier promotion)
|
||||
└─ Chunk streaming takes over (existing system)
|
||||
```
|
||||
|
||||
**Cost annotation:**
|
||||
|
||||
| Component | Cost | Notes |
|
||||
|---|---|---|
|
||||
| Generation trigger hooks in chunk_streaming.rs | **Cheap** (1-2 days) | The TODO is already in the code: "For v0.3+, the generator fills newly loaded chunks." Just need to call the Phase 2 generator from `load_chunk`. |
|
||||
| Phase 1 background generation (async) | **Medium** (1-2 weeks) | Rust async task spawning for background generation. bevy_ecs tasks or tokio. Must not block the simulation tick. |
|
||||
| Phase 2 on-demand generation | **Medium** (tied to Phase 2 algorithm cost) | The Phase 2 algorithm itself determines this cost. BSP + template stamping is fast enough for on-demand (~5-50ms per chunk). WFC might be too slow for on-demand. |
|
||||
| Save/load of generated data | **Medium** (1-2 weeks) | DistrictSkeleton is already `Serialize/Deserialize`. Chunk tile data needs a compact format (MessagePack per D-020). Save file includes generated-but-not-original-seed data for districts the player has visited. |
|
||||
| Cache management | **Medium** (1-2 weeks) | LRU cache for generated chunks. Memory budget per D-026. Eviction writes to save file. |
|
||||
|
||||
**What's technically hard:** The async generation pipeline. Generating a Phase 1 skeleton (constraint satisfaction with guarantee audit) cannot run on the simulation thread — it needs to run in background and deliver results when ready. Rust's async ecosystem handles this well (tokio::spawn or bevy_ecs async tasks), but integrating it with the ECS tick loop requires care.
|
||||
|
||||
**What's technically cheap:** The tier promotion/demotion. D-026's simulation tiers are about *component presence* on entities. bevy_ecs dynamic component add/remove is the designed mechanism. Promoting a State-saved NPC to Active means attaching simulation components — this is literally what bevy_ecs is built for.
|
||||
|
||||
---
|
||||
|
||||
### Layer 6: Settlement Generation — Cities on Bones
|
||||
|
||||
**Status: NOT BUILT — this is the missing bridge between topography and districts.**
|
||||
|
||||
Given a LocationProfile (planet with population X, economic base Y, biome zones Z), where do settlements go? How many districts? How are they connected?
|
||||
|
||||
**What needs generation:**
|
||||
|
||||
1. **Settlement placement** — where on the location surface do cities/towns/outposts appear? Constrained by topography (Approach A: tags, Approach B: heightmap).
|
||||
2. **District count and type distribution** — a population-500K industrial city has different district composition than a population-2K research outpost.
|
||||
3. **Road/transit network** — how districts connect to each other and to the horizon station.
|
||||
4. **District boundaries** — the `DistrictBoundaries` stub in generator.rs. Adjacent districts must have compatible edges.
|
||||
|
||||
**CityCrafter3D reference:** Their pipeline is directly applicable at this level:
|
||||
- Grid-based city layout (maps to our Grid DistrictLayoutMode)
|
||||
- Noise-based district assignment (residential/commercial/industrial) — we'd substitute our richer `DistrictType` enum
|
||||
- Block sizing with multi-block reservations (1x1, 2x1, 2x2) — maps directly to our 4×4 block grid with `MultiBlockReservation`
|
||||
- Road network generation between blocks — their `generate_dynamic_roads_async` with road merging and intersection generation is a clean reference
|
||||
- Building density per district type — their density_settings pattern (min/max buildings, spacing, border margin) maps to our `density_pct` on BlockSkeleton
|
||||
|
||||
**Key difference from CityCrafter3D:** They do everything client-side in GDScript. We do generation server-side in Rust. But the *algorithm* transfers: grid placement → district assignment → road network → building population.
|
||||
|
||||
**Cost annotation:**
|
||||
|
||||
| Component | Cost | Notes |
|
||||
|---|---|---|
|
||||
| Settlement placement from location profile | **Cheap-Medium** (1-2 weeks) | Rule-based: population → district count table. Economic base → district type distribution. Topography tag → valid SettingTypes. |
|
||||
| District adjacency and road network | **Medium** (2-3 weeks) | Graph generation: districts as nodes, roads as edges. Must respect topography (no road through a mountain). Must ensure connectivity. |
|
||||
| District boundary stitching | **Hard** (2-3 weeks) | Two adjacent districts must have matching access points at their shared edge. This is a constraint propagation problem — generate district A, then district B must respect A's boundary. |
|
||||
| Transit network (inter-district) | **Medium** (1-2 weeks) | Higher-level than roads — shuttle routes, rail lines, vehicle paths. Can be abstract (graph edges with travel time) initially, rendered later. |
|
||||
|
||||
**What's technically hard:** District boundary stitching. When generating district A, you must leave "ports" on its edges where district B can connect. If district B is Organic layout (D-096) while district A is Grid, the boundary gets architecturally interesting. The previous Generator Architecture Workshop outputs don't fully solve this — the `DistrictBoundaries` type is still a `String` stub.
|
||||
|
||||
**What's technically cheap:** Settlement placement and district count. This is a lookup table with some noise. Population 500K → 8-12 districts. Economic base: manufacturing → 3 industrial, 2 commercial, 2 residential, 1 transit, 1 mixed.
|
||||
|
||||
---
|
||||
|
||||
### Layer 7: District → Building (Phase 1 + Phase 2)
|
||||
|
||||
**Status: DATA MODEL BUILT (generator.rs), ALGORITHM NOT BUILT.**
|
||||
|
||||
This is the layer my Round 1 assessment covered. The data model is the most mature part: `DistrictSkeleton` with 4×4 block grid, `BlockSkeleton`, `MultiBlockReservation`, `FloorZone`, `ZonePalette`, `ChunkMutations`, `WallBackside`, `SocialSitePlacement`, `TriangleAssignment`.
|
||||
|
||||
**Phase 1 (Skeleton)** — the hard part:
|
||||
- Assign 16 blocks with zoning, era, density
|
||||
- Place multi-block reservations (skyscrapers, parks, terminals)
|
||||
- Carve corridor spines
|
||||
- Place social sites with triangle assignments
|
||||
- Run guarantee audit (D-097: up to 13 checks)
|
||||
|
||||
**Phase 2 (Chunk Fill)** — the visible part:
|
||||
- BSP room subdivision within blocks
|
||||
- Template stamping for social site rooms
|
||||
- Corridor carving between rooms
|
||||
- Door placement
|
||||
- Object/furniture placement
|
||||
- WallBackside tagging (D-099)
|
||||
- Tile palette application from ZonePalette
|
||||
|
||||
**Cost annotations from Round 1 still apply.** Adding context from the full pipeline:
|
||||
|
||||
- Phase 1 with full guarantee audit: **3-5 weeks** (the guarantee system is a constraint solver)
|
||||
- Phase 2 BSP + templates: **2-3 weeks**
|
||||
- Phase 2 with full WallBackside + object placement: **4-6 weeks**
|
||||
- Z-level generation (MultiBlockReservation floors): **2-3 weeks** additional
|
||||
- Organic layout mode (D-096 rotation/offset): **1-2 weeks** additional
|
||||
|
||||
---
|
||||
|
||||
### Layer 8: 2D → 3D Rendering
|
||||
|
||||
**Status: ASSESSED IN ROUND 1 — recommendation stands.**
|
||||
|
||||
Generate rendering-agnostic data (tile grids with type + z-level + position). The current 2D TileMapLayer renderer filters z > 0 and displays what it can. The 3D renderer replaces it when ready. Zero throwaway work.
|
||||
|
||||
The GridMapLayer reference (vendor) confirms the 2D-tile-data → 3D-GridMap bridge is a clean, well-understood pattern. Their approach: TileMapLayer data → bake to custom data layers → GridMap reads baked data. We'd skip the bake step and go directly from server tile data → GridMap placement.
|
||||
|
||||
---
|
||||
|
||||
## Questions for the Product Owner
|
||||
|
||||
### Q1: How does Layer 2 (Location Profiles) get populated?
|
||||
|
||||
This is the biggest structural gap. We have 300 systems in `systems.db` with rich attributes, but no individual planet/station records. Every layer below depends on this.
|
||||
|
||||
**Technical tradeoff:** Authoring 300+ location profiles by hand produces the best quality but doesn't scale. Pure generation from system attributes is fast but may produce bland or contradictory locations. The grammar that maps system attributes → location profiles is the critical intellectual work.
|
||||
|
||||
| Option | Cost | What You Get |
|
||||
|---|---|---|
|
||||
| A. Pure generation — system attributes → location profile via rules | **Medium** (2-3 weeks for grammar + generation code) | Every system gets locations automatically. Quality depends entirely on grammar quality. Bland results if grammar is shallow. |
|
||||
| B. Hybrid — generated baseline + hand-authored overrides for narrative-notable systems | **Medium-Large** (3-4 weeks engineering + ongoing authoring) | Generated locations everywhere, hand-crafted for the ~30-40 systems that matter most. The generation grammar is validated against hand-authored examples. |
|
||||
| C. Template library — 20-30 location templates, selected by system attribute matching | **Medium** (2-3 weeks) | Faster than per-system authoring, less variety than generation. A "manufacturing hub" template applied to 40 systems produces 40 similar-but-seeded locations. |
|
||||
|
||||
**My assessment:** **B is the right answer.** The systems.db already tags `narrative_notable`. Those get authored profiles (Miri territory). The rest use the generation grammar. The grammar rules are the critical design work — they encode "what kind of planet does a wave-3, economic-tier-2, manufacturing system in the deep frontier have?" The engineering to execute those rules is straightforward.
|
||||
|
||||
**Cost: Medium for engineering, ongoing for authoring.**
|
||||
|
||||
---
|
||||
|
||||
### Q2: Planetary topography — how deep do we go?
|
||||
|
||||
The player arrives at a specific point and explores outward. They never see the whole planet. But they might see a world map. And the topography constrains what districts can exist.
|
||||
|
||||
**Technical tradeoff:** Abstract tags are cheap and sufficient for district generation. Real terrain makes the world map meaningful and enables terrain-aware features (rivers, elevation, weather). The ROI inflection point is "does the player ever look at a map bigger than one district?"
|
||||
|
||||
| Option | Cost | What You Get |
|
||||
|---|---|---|
|
||||
| A. Abstract tags only (coastal/mountain/plains/etc.) | **Cheap** (days of engineering, authored per location) | Districts know their terrain context. No world map beyond "you are here on planet X." Sufficient for ground-level gameplay. |
|
||||
| B. Regional noise heightmap (~1km resolution) | **Medium** (3-5 weeks) | Terrain the player can see on a minimap. Rivers, coastlines, mountain ranges visible at region scale. Districts placed on geographically motivated positions. |
|
||||
| C. Full planetary generation (tectonics + erosion + climate) | **Very Large** (months) | Geologically plausible planets. Beautiful, scientifically interesting, and almost invisible at 30° camera / district scale. |
|
||||
|
||||
**My assessment:** **A to start, B as enrichment.** The 30° camera at ground level cannot distinguish "noise heightmap coastline" from "tagged as coastal." The value of B is the *world map experience* — showing the player that districts exist in a geographically coherent space. If the world map is important to the endgame experience (and I suspect it is — it's the NMS/Stellaris "I can see my whole territory" feeling), then B is worth doing. C is pure gold-plating at our scale.
|
||||
|
||||
**The RetroTerrain technique (noise → heightmap → vertex colors → shader) is directly applicable for B.** We'd chunk it (they don't) and run it server-side (they run client-side). The shader work for terrain painting is reusable across all wilderness/rural SettingTypes.
|
||||
|
||||
---
|
||||
|
||||
### Q3: Does the generation pipeline run offline, on-demand, or hybrid?
|
||||
|
||||
There's a fundamental architecture choice: does the game pre-generate the entire galaxy when you start a new game, or does it generate on-demand as you explore?
|
||||
|
||||
**Technical tradeoff:** Pre-generation means loading screens but consistent quality. On-demand means seamless exploration but risk of generation hitches. Hybrid means different layers pre-generate at different times.
|
||||
|
||||
| Option | Cost | Player Experience |
|
||||
|---|---|---|
|
||||
| A. Full pre-generation at new-game | **Engineering: cheap. Time: expensive.** Generating 300 systems × N locations × M districts takes minutes to hours depending on depth. | Long "generating world" screen. But: everything is ready when you start. No hitches. Consistent. The Dwarf Fortress model. |
|
||||
| B. Full on-demand | **Engineering: medium-hard** (async pipeline, cache management, save integration) | Seamless exploration. But: first visit to any location has a generation pause. Risk of visible pop-in if generation is slow. |
|
||||
| C. Hybrid — Layer 1-2 pre-generated, Layer 3-7 on-demand | **Engineering: medium** | Short "generating world" screen (Layer 1-2 takes seconds — it's table lookups and grammar rules). Districts generate as you approach. The NMS model. |
|
||||
| D. Progressive — Layer 1 pre-gen, Layer 2 on first system visit, Layer 3-7 on district approach | **Engineering: medium** (the tier cascade described in Layer 5) | Minimal upfront wait. Each system visit triggers location generation. Each district approach triggers tile generation. The "fog of generation" parallels the fog of war. |
|
||||
|
||||
**My assessment:** **D (progressive) is the correct architecture and also the most elegant.** It maps exactly onto D-026 simulation tiers:
|
||||
|
||||
- New game: `systems.db` loaded. All 300 systems exist as graph nodes. Cost: milliseconds.
|
||||
- Player's home system: LocationProfiles generated at game start. Starting district Phase 1 + Phase 2 completed. Cost: seconds.
|
||||
- Transit to new system: LocationProfiles generated during transit loading (the MobileChunk voyage or skip-travel screen). Phase 1 skeletons for destination and neighbors generated async. Cost: hidden behind transit.
|
||||
- Arrive at district: Phase 2 fill on demand. Chunk streaming activates. Cost: <100ms per chunk if BSP is the algorithm.
|
||||
|
||||
**This means generation latency is always hidden behind a diegetic transition** (gate transit, shuttle ride, walking to a new district). The player never sees a "generating..." screen after the initial game start.
|
||||
|
||||
**What's technically hard:** The async pipeline coordination. Multiple layers generating concurrently for different systems/districts, writing to a shared cache, with the simulation tick continuing. Rust's ownership model actually helps here — each generation task owns its input data and produces an output that gets atomically inserted.
|
||||
|
||||
**What's technically cheap:** The progressive trigger logic. It's an if-chain: "is this system generated? no → generate it. is this district filled? no → fill it."
|
||||
|
||||
---
|
||||
|
||||
### Q4: How do 5 zone types share one pipeline?
|
||||
|
||||
The Round 1 flag was correct: "each SettingType is essentially a separate generator." But the reframe asks: what does a shared pipeline look like?
|
||||
|
||||
**Technical tradeoff:** The more the pipeline shares between zone types, the cheaper each new zone is to add — but the less distinctive each zone feels. The less they share, the more each zone feels unique — but the implementation cost multiplies per zone type.
|
||||
|
||||
**What CAN be shared across all zone types:**
|
||||
|
||||
| Shared Component | Applies To | Notes |
|
||||
|---|---|---|
|
||||
| Phase 1 skeleton structure (4×4 blocks, zoning, social sites) | All types | Block grid works for Station (modules), Urban (city blocks), Agricultural (plots), Wilderness (terrain sectors). The *block meaning* changes but the *structure* doesn't. |
|
||||
| Guarantee audit system (D-097) | All inhabited types | Tier 1 guarantees (Social Hub, Informal Zone, Encounter Corridor) apply to ALL inhabited districts regardless of SettingType. |
|
||||
| ZonePalette + modifier system | All types | Base palette per SettingType, modifiers apply identically. |
|
||||
| ChunkMutations / DamageOverlay | All types | Post-generation modification is setting-agnostic. |
|
||||
| Social site placement | All inhabited types | Social sites go in blocks. The block's SettingType constrains which site templates are valid, but the placement mechanism is shared. |
|
||||
| Chunk streaming | All types | Already setting-agnostic. |
|
||||
|
||||
**What MUST differ per zone type:**
|
||||
|
||||
| Per-Zone Component | Why It Differs | Cost Per Zone |
|
||||
|---|---|---|
|
||||
| Phase 2 fill algorithm | Station = rooms + corridors. Urban = lots + buildings + streets. Wilderness = terrain + vegetation + paths. | **2-4 weeks per zone type** |
|
||||
| Tile palette data | Different tile types, materials, visual vocabulary. | **1-2 weeks per zone type** (asset-dominated) |
|
||||
| Block semantics | Station block = module cluster. Urban block = city block with lot subdivision. Agricultural block = field + farmstead. | **1 week per zone type** (definition + templates) |
|
||||
| Height/terrain treatment | Station = flat interior. Urban = flat with building heights. Wilderness = terrain heightmap. | **1-3 weeks per zone type** |
|
||||
|
||||
**My assessment:** The pipeline IS shared at Phase 1 level. The divergence happens at Phase 2. This means:
|
||||
|
||||
1. Phase 1 is **one implementation** that works for all 5 zone types (the skeleton structure is zone-agnostic)
|
||||
2. Phase 2 needs **one fill algorithm per zone type** (or per zone type *family* — Station and Urban can share a lot of room/corridor logic)
|
||||
3. The total cost for 5 zone types is: Phase 1 (once, 3-5 weeks) + Phase 2 per zone (2-4 weeks × 5, minus shared code between similar types)
|
||||
|
||||
**Zone type families that share Phase 2 code:**
|
||||
|
||||
| Family | Members | Shared Fill Logic |
|
||||
|---|---|---|
|
||||
| **Interior** | Station, Orbital, Specialized | BSP room subdivision, corridor carving, door placement. Station is the base; others add templates. |
|
||||
| **Urban** | Urban, Industrial, Maritime (port) | Lot subdivision, building placement, street network. CityCrafter3D patterns apply. |
|
||||
| **Natural** | Wilderness, Agricultural, Water | Terrain heightmap, vegetation/crop placement, path networks. RetroTerrain patterns apply. |
|
||||
| **Transitional** | Transitional | Hybrid of adjacent zone families — boundary-stitching problem. |
|
||||
|
||||
With 3 families instead of 8 independent generators, the Phase 2 cost drops from 5 × 3 weeks to 3 families × 3 weeks + per-type customization.
|
||||
|
||||
**Total endgame cost for all zone types: Phase 1 (4 weeks) + 3 Phase 2 families (9 weeks) + per-type customization (3-4 weeks) = ~16-17 weeks of generation engineering.**
|
||||
|
||||
---
|
||||
|
||||
### Q5: What does the "content spidering" look like at the galaxy boundary?
|
||||
|
||||
When the player is at Van Maanen's Star and looks at the star map, they see 300 system nodes. Some are nearby (2 hops), some are distant (20+ hops). What exists at each distance?
|
||||
|
||||
**Technical tradeoff:** Generating too far ahead wastes resources on content the player may never visit. Generating too little ahead means visible loading when the player decides to travel. The sweet spot depends on how fast the player can traverse the gate network.
|
||||
|
||||
| Distance from Player | What Should Exist | Generation Trigger |
|
||||
|---|---|---|
|
||||
| **Current system** | Full: LocationProfiles + Phase 1 skeletons + Phase 2 for current district + chunk streaming active | At game start / on arrival |
|
||||
| **Adjacent systems (1 hop)** | LocationProfiles + Phase 1 skeletons for likely destinations | On system entry (background async) |
|
||||
| **2-3 hops** | LocationProfiles only (planet count, economic role, population) | On system entry (cheap, batch) |
|
||||
| **4+ hops** | `systems.db` graph data only (name, sector, topology, economic tier) | Already loaded at game start |
|
||||
|
||||
**My assessment:** This is the NMS model: the star map shows *metadata* for distant systems (name, type, faction, economic tier — all from `systems.db`), generates *profiles* for nearby systems, and fully generates *districts* only for the current location and immediate neighbors.
|
||||
|
||||
**Cost: Cheap.** The generation cascade is the progressive model from Q3. The only engineering work is the async pipeline that pre-generates adjacent systems during idle time. The `systems.db` data is already loaded and query-ready.
|
||||
|
||||
**What's technically hard:** Cache invalidation when the player returns to a previously-visited system. The generated districts must be saved and reloaded identically (MessagePack serialization per D-020). This is the save/load integration problem — not conceptually hard, but must be correct.
|
||||
|
||||
**What's technically cheap:** The star map UI showing `systems.db` metadata for all 300 systems. It's a read-only overlay on the graph. The data already exists and is query-ready.
|
||||
|
||||
---
|
||||
|
||||
## Feasibility Summary: The Full Pipeline
|
||||
|
||||
| Layer | Status | Cost to Complete | Difficulty |
|
||||
|---|---|---|---|
|
||||
| 1. Galaxy (300 systems) | **Built** | Days (Rust loader for systems.db) | Easy |
|
||||
| 2. Location profiles | **Gap** | 3-4 weeks (grammar + generation + hybrid authoring) | Medium — the grammar is the hard design work |
|
||||
| 3. Planetary topography | **Not built** | Days (tags) to 3-5 weeks (heightmaps) | Easy to Medium |
|
||||
| 4. Inbound gateways | **Partially designed** | Included in Station SettingType + 1-2 days for gate-specific templates | Easy |
|
||||
| 5. Content spidering | **Architecture exists** | 2-3 weeks (async pipeline + cache + save integration) | Medium — async coordination |
|
||||
| 6. Settlement generation | **Not built** | 3-5 weeks (placement + roads + boundary stitching) | Medium-Hard — boundary stitching is the challenge |
|
||||
| 7. District → building | **Data model built** | 6-10 weeks (Phase 1 + Phase 2 for 3 zone families) | Medium-Hard — guarantee audit is a constraint solver |
|
||||
| 8. 2D → 3D rendering | **Assessed** | 2-4 weeks | Medium — ongoing client work |
|
||||
|
||||
**Total engineering estimate for the full endgame pipeline: ~20-30 weeks** of dedicated generation engineering, depending on topography depth (A vs B) and zone type count at full fidelity.
|
||||
|
||||
**The critical path is Layer 2 → Layer 6 → Layer 7.** Everything else is either built (Layer 1), cheap (Layer 3A, Layer 4), or parallelizable (Layer 5, Layer 8). The three critical layers are sequential: you can't generate settlements (6) without location profiles (2), and you can't generate districts (7) without settlement placement (6).
|
||||
|
||||
**The good news:** The data model for Layer 7 is already built (579 lines). The infrastructure for Layer 1 is already built (300 wiki pages, systems.db, star map generation). The streaming system for Layer 5 is already built. The pipeline has bookends — the top and bottom are solid. The middle needs to be filled.
|
||||
@@ -0,0 +1,400 @@
|
||||
# Tyre — SW1-R2: Feasibility Synthesis — Authored Content + Background Simulation
|
||||
|
||||
**Sub-workshop 1, Round 2 — Cross-read synthesis with interview answers**
|
||||
|
||||
---
|
||||
|
||||
## 1. The Authored Content Shift — What Changes in the Engineering Pipeline
|
||||
|
||||
The interview answers fundamentally reframe the generator. My R1b assessment assumed a **procedural generation pipeline** — seed in, world out. The product owner's model is an **authored content pipeline with simulation-driven drift**:
|
||||
|
||||
| Layer | R1b Assumption | Interview Reality | Engineering Impact |
|
||||
|---|---|---|---|
|
||||
| **Galaxy (300 systems)** | Read-only dataset — correct | Fixed galaxy, same routes every run | **No change.** Assessment was already right. |
|
||||
| **Location profiles** | Hybrid: generated baseline + authored overrides | **Fully authored.** Extend the wiki. Generator *reads* authored data, doesn't generate profiles. | **Major simplification.** Kill the generation grammar. Build a wiki → data pipeline instead. |
|
||||
| **Topography** | Abstract tags or noise heightmaps | **Authored world maps** for all planets and moons. Hard constraint on generation. | **Removes algorithmic terrain generation entirely.** Adds an authored-map ingestion pipeline. |
|
||||
| **Replayability source** | Seed-based variation | **NOT seed-based.** Background simulation drift over time. Same canonical starting state every run. | **Fundamental architecture shift.** The generator is a *painter reading current state*, not a *builder from a seed*. |
|
||||
| **Cultural framework** | 7 heritage roots with corridor weights | Heritage roots **deprecated as generator inputs.** Real-world cultural migration corridors from the wiki. D-104/D-105 are stale. | **Simplification.** Cultural data is authored per-system in the wiki, not derived from abstract roots. Miri's cascade framework (Q1-Q5) needs reframing — the authored data IS the cascade input. |
|
||||
|
||||
### What's Still Generated vs. What's Read from Authored Data
|
||||
|
||||
**Read from authored data (engineering = data pipeline):**
|
||||
- Galaxy topology and system attributes (systems.db — already built)
|
||||
- Per-planet/station/moon profiles (wiki — to be authored)
|
||||
- World maps / topographic constraints (to be authored)
|
||||
- Cultural identity per system (wiki — largely authored)
|
||||
- GTTR entries with stats and art (to be authored)
|
||||
|
||||
**Generated from authored data + simulation state (engineering = algorithms):**
|
||||
- Settlement layout on authored terrain (where do districts go, given the terrain map and the current economic state?)
|
||||
- District skeletons (Phase 1 — block zoning, social sites, guarantees)
|
||||
- Tile-level fill (Phase 2 — rooms, corridors, objects)
|
||||
- NPC populations and their current states
|
||||
- Economic/social conditions within generated spaces (derived from background sim pressure)
|
||||
|
||||
**Generated on-demand from simulation events (engineering = hooks):**
|
||||
- NPC home neighborhoods (triggered by deep interaction)
|
||||
- Damaged/changed locations (triggered by news events)
|
||||
- LOD upgrades for player-invested entities (triggered by player economic engagement)
|
||||
|
||||
### The Pipeline Simplification
|
||||
|
||||
*cracks knuckles* — This is actually elegant. The product owner has removed the two hardest algorithmic problems from the pipeline:
|
||||
|
||||
1. **Location profile generation grammar** — was going to be a constraint satisfaction problem (mapping 30+ system attributes to coherent planet profiles). Now it's a data ingestion pipeline. Authoring is hard, engineering is cheap.
|
||||
|
||||
2. **Terrain generation** — was either trivial (abstract tags) or expensive (hydraulic erosion, heightmaps). Now it's a fixed data pipeline: authored map → constraint extraction → "this area is coast, this area is mountain." The constraint data feeds district placement.
|
||||
|
||||
What remains as the algorithmic core:
|
||||
- Phase 1 skeleton generation (constraint satisfaction with guarantees) — **still hard**
|
||||
- Phase 2 tile fill (BSP + templates) — **still medium**
|
||||
- District boundary stitching — **still hard**
|
||||
- Background simulation pressure modeling — **new and substantial**
|
||||
|
||||
---
|
||||
|
||||
## 2. Background Simulation on Spare CPU Cores
|
||||
|
||||
The product owner wants full economic + social + political background simulation running on spare CPU cores at capped load. Let me be honest about what this means technically.
|
||||
|
||||
### Architecture Options
|
||||
|
||||
**Option A: bevy_ecs same-World, gated SystemSets**
|
||||
|
||||
Background sim systems live in the same bevy World as the active sim but run on a separate schedule with a `run_if(idle_budget_available)` condition.
|
||||
|
||||
```
|
||||
[Active tick schedule - 10 tps]
|
||||
├─ perception, movement, dialogue, monologue (ActiveSim entities)
|
||||
└─ if cpu_idle_budget > 0:
|
||||
├─ background_economic_pressure (all systems)
|
||||
├─ background_social_drift (BackgroundSim entities)
|
||||
└─ background_political_shift (system-level)
|
||||
```
|
||||
|
||||
- **Pro:** Single World, ECS queries work naturally, component access is straightforward.
|
||||
- **Con:** Background systems share the tick budget. If the active sim takes 8ms of a 100ms tick, background gets 92ms. But if active sim spikes (combat, crowd scene), background gets squeezed to zero. Also: all background work must complete within the remaining tick budget or be interruptible.
|
||||
- **Determinism risk:** LOW if background systems run in fixed order after active systems. The variable is *how much* runs per tick, not *what order*.
|
||||
|
||||
**Option B: Separate bevy App (parallel world)**
|
||||
|
||||
A second bevy App runs on a dedicated thread pool with its own World. It holds system-level economic/political state and BackgroundSim NPC state machines. Communication with the main App via channels (crossbeam or tokio mpsc).
|
||||
|
||||
```
|
||||
[Main thread - Active tick schedule] [Background thread pool - uncoupled]
|
||||
├─ active sim systems ├─ economic pressure per system
|
||||
├─ read channel: background results → ├─ social drift per BackgroundSim NPC
|
||||
└─ write channel: → tier promotion requests └─ political faction shifts
|
||||
```
|
||||
|
||||
- **Pro:** True CPU isolation. Background sim can't impact active sim frame time. Natural CPU capping via thread pool size.
|
||||
- **Con:** Data synchronization complexity. Two Worlds means entity state must be serialized across the channel boundary. Tier promotion (Background → Active) requires transferring entity state from one World to the other. This is architecturally messy.
|
||||
- **Determinism risk:** HIGH. Two independent schedulers running at different rates produce ordering-dependent results. Must gate background sim on a deterministic clock (game-minutes), not wall-clock time.
|
||||
|
||||
**Option C: tokio async tasks outside bevy**
|
||||
|
||||
Background simulation runs as a set of tokio tasks, not bevy systems. They operate on a separate data model (not ECS components) and write results back to the ECS World via a command queue consumed once per tick.
|
||||
|
||||
```
|
||||
[bevy tick] [tokio thread pool]
|
||||
├─ active sim ├─ economic_sim_task(system_id)
|
||||
├─ consume background_results queue → ├─ social_sim_task(region_id)
|
||||
└─ publish state_snapshots → └─ political_sim_task(faction_id)
|
||||
```
|
||||
|
||||
- **Pro:** Clean separation. Background sim doesn't touch ECS at all — it reads snapshots and writes deltas. CPU capping is trivial (tokio runtime with configured thread count). Already have tokio in the dependency tree (voice pipeline uses it).
|
||||
- **Con:** The background sim needs its own data model, separate from ECS components. Duplication of entity state representation. More code to maintain.
|
||||
- **Determinism risk:** MEDIUM. tokio task scheduling is non-deterministic, but if each task is internally deterministic and results are applied in a fixed order per game-minute, overall determinism is preserved.
|
||||
|
||||
### My Assessment
|
||||
|
||||
**Option C (tokio tasks) is the right architecture.** Here's why:
|
||||
|
||||
1. **CPU capping is trivial.** Configure a tokio runtime with N worker threads. Set N based on available cores minus main-sim needs. This is exactly "spare CPU cores."
|
||||
|
||||
2. **The background sim doesn't need ECS.** Economic pressure, faction power shifts, and social drift operate on *aggregate* data (system-level economics, faction influence scores, population-level social indicators). These aren't per-entity ECS queries — they're mathematical models over structured data. An ECS is the wrong tool for "calculate GDP drift for 300 star systems."
|
||||
|
||||
3. **D-010 determinism is solvable.** Background tasks run on a game-minute clock. Every game-minute, the main sim snapshots relevant state, pushes it to the background task queue, and background tasks process it deterministically. Results are collected and applied in a fixed order at the next game-minute boundary. The variable scheduling only affects *when* results are ready, not *what* they contain.
|
||||
|
||||
4. **Already have the precedent.** The voice pipeline (`server/src/voice/`) already uses tokio with hardware detection, worker queues, and caching. Same pattern, different domain.
|
||||
|
||||
### D-026 Interaction
|
||||
|
||||
The existing tier system (tier.rs) handles per-entity proximity-based promotion/demotion beautifully. Background simulation is a *different axis* — it's not about individual NPC simulation tiers, it's about **system-level pressure modeling** that affects all entities in a system regardless of their individual tier.
|
||||
|
||||
Think of it as two simulation layers:
|
||||
|
||||
| Layer | Scope | Runs Where | Updates |
|
||||
|---|---|---|---|
|
||||
| **Entity simulation** (D-026 tiers) | Per-NPC: movement, dialogue, perception | bevy_ecs main tick | Every tick (Active) or every game-minute (Background) |
|
||||
| **Pressure simulation** (new) | Per-system/per-settlement: economic health, faction balance, social tension | tokio background tasks | Every game-minute or game-hour |
|
||||
|
||||
The pressure layer produces *context* that entity-layer systems read. Example flow:
|
||||
|
||||
1. Background pressure sim calculates: "Van Maanen's Station commercial district economic health dropped from Stable to Faltering this game-hour."
|
||||
2. Main sim reads the updated pressure on next tick.
|
||||
3. Active-tier NPCs in that district adjust behavior (merchants reduce stock, workers show stress, security increases patrols).
|
||||
4. Background-tier NPCs in that district get a state-machine transition queued (some leave, some change routines).
|
||||
5. When the player visits, the district *looks* different because the pressure changed the NPC population's state.
|
||||
|
||||
### Cost Estimate
|
||||
|
||||
| Component | Effort | Notes |
|
||||
|---|---|---|
|
||||
| Pressure simulation data model | 1-2 weeks | Per-system economic state, per-settlement social indicators, per-faction political influence. Separate from ECS. |
|
||||
| tokio task infrastructure | 1 week | Runtime setup, snapshot/result channels, game-minute clock integration. Pattern exists in voice pipeline. |
|
||||
| Economic pressure model | 2-3 weeks | Supply/demand between systems, trade route effects, industry health, prosperity cascades. The intellectual design work dominates. |
|
||||
| Social pressure model | 2-3 weeks | Population satisfaction, cultural tension, crime pressure, public services quality. |
|
||||
| Political pressure model | 1-2 weeks | Faction influence shifts, governance stability, external pressure (Commission, Institute). |
|
||||
| Pressure → entity behavior bridge | 1-2 weeks | How pressure state modifies NPC routines, dialogue topics, building conditions. |
|
||||
| CPU budget management | 1 week | Core detection, thread pool sizing, load capping, idle detection. |
|
||||
| **Total** | **9-14 weeks** | **This needs its own dedicated workshop** (as the product owner flagged). |
|
||||
|
||||
**Tier classification: HARD.** Not because any single piece is beyond reach, but because the *design* of what economic/social/political pressures to model, and how they cascade to visible changes, is a major game design task that requires Gestalt, Paula, and Nigel alongside engineering.
|
||||
|
||||
---
|
||||
|
||||
## 3. NPC-Driven and News-Driven Generation Hooks
|
||||
|
||||
### NPC-Driven Generation
|
||||
|
||||
**Scenario:** Player meets Kira from Barnard's Star. Through deep interaction (not casual), they learn Kira's address. Now that address must be a real visitable place.
|
||||
|
||||
**Architecture:**
|
||||
|
||||
```
|
||||
Player meets Kira (deep interaction trigger)
|
||||
├─ Kira.home_location already exists in wiki data:
|
||||
│ system: GJ-699 (Barnard's Star)
|
||||
│ settlement: Proxima Station, District 7
|
||||
│ address: Block 3, Unit 12
|
||||
│
|
||||
├─ Is GJ-699 generated?
|
||||
│ No → Queue: generate LocationProfile for GJ-699 (background)
|
||||
│ Yes → Is District 7 skeleton generated?
|
||||
│ No → Queue: generate Phase 1 skeleton for District 7 (background)
|
||||
│ Yes → Is Block 3 filled?
|
||||
│ No → Queue: generate Phase 2 fill for Block 3 (background)
|
||||
│ Yes → Mark Unit 12 as "Kira's residence" (ChunkMutation)
|
||||
│
|
||||
└─ Kira's home is now visitable. Player can travel there.
|
||||
```
|
||||
|
||||
**Latency budget:** NOT immediate. The player meets Kira now, but traveling to Barnard's Star takes game-time. Generation runs in background during that interval. Even if the player teleported instantly, Phase 1 skeleton generation for a single district is ~50-200ms (BSP is fast). Phase 2 for a single block is ~5-50ms. Total worst case: <1 second of generation, easily hidden behind a door transition or transit loading.
|
||||
|
||||
**Consistency constraint:** Kira's home must match Kira's presentation. If Kira is wealthy, Unit 12 should be in a prosperous block. If Kira is struggling, it should be in a declining area. This means the generation mandate carries economic/social constraints that Phase 1 must respect when placing Kira's block.
|
||||
|
||||
**Feasibility: MEDIUM.** The generation itself is cheap. The hard part is the **constraint propagation**: Kira's attributes → home block requirements → Phase 1 must place that block appropriately. This is a focused version of the guarantee system — "this specific block must have property X." Estimate: **1-2 weeks** for the hook system + constraint interface.
|
||||
|
||||
### News-Driven Generation
|
||||
|
||||
**Scenario:** Reach-wide news reports "Gas main explosion at Kepler Haven, East District." Player travels there three game-days later. The explosion damage must exist.
|
||||
|
||||
**Architecture:**
|
||||
|
||||
```
|
||||
News event fires
|
||||
├─ Event specifies: location (Kepler Haven), district (East), type (gas explosion)
|
||||
│
|
||||
├─ Is Kepler Haven generated?
|
||||
│ No → Queue: generate with explosion as a ChunkMutation
|
||||
│ The explosion becomes part of the initial generation —
|
||||
│ no "pristine then damaged" needed
|
||||
│ Yes → Apply ChunkMutation: damage overlay on affected blocks
|
||||
│ Replace tiles, add rubble objects, modify NPC states
|
||||
│
|
||||
└─ When player visits, damage is present and consistent
|
||||
```
|
||||
|
||||
**Latency budget:** Days of game-time. News events are sparse (the product owner said "sparse frequency to avoid disruption"). The generation mandate is queued and processed in background during normal idle-time sim cycles.
|
||||
|
||||
**The hard edge case:** The news event references something that must *already exist* at the location. "Explosion at the hospital" means the location must have a hospital. Two approaches:
|
||||
|
||||
1. **News events are generated from existing content:** The storyteller only generates news about things that already exist in the world state (including generated-but-unvisited locations). This means the event system reads the Phase 1 skeleton to know "East District has a hospital block" before deciding to blow it up.
|
||||
|
||||
2. **News events mandate content:** The event says "there must be a hospital here" and the guarantee system ensures it during generation. If the district isn't generated yet, the hospital is a Tier 1 guarantee. If it IS generated, the hospital must already exist or we have a contradiction.
|
||||
|
||||
**My strong recommendation: Approach 1.** Events read world state, don't mandate content. This is consistent with the product owner's statement: "Only from real simulation events. No fabricated history." The background simulation produces pressures → pressures cause events → events are reported as news. The sequence is simulation → event → news, not news → content.
|
||||
|
||||
**Feasibility: MEDIUM.** The news event hook itself is cheap (1 week). The integration with the background simulation event system is the real work — and that's part of the background simulation workshop scope.
|
||||
|
||||
---
|
||||
|
||||
## 4. Full Simulation Primitives with LOD
|
||||
|
||||
The product owner's model: "A visited bar needs monthly turnover, cost, employee count, current staff and visitors. If the player BUYS the bar, deeper simulation activates."
|
||||
|
||||
### LOD Architecture
|
||||
|
||||
This maps cleanly to bevy_ecs component composition:
|
||||
|
||||
| LOD Level | Trigger | Components Added | Simulation Cost |
|
||||
|---|---|---|---|
|
||||
| **LOD 0: Exists** | Phase 1 skeleton generation | `SocialSite { site_type, block_id }` | Zero — metadata only |
|
||||
| **LOD 1: Observable** | Player is within same district | `BusinessStats { turnover_bracket, cost_tier, employee_count, patron_density, condition }` | Near-zero — derived from pressure sim, updated per game-hour |
|
||||
| **LOD 2: Visited** | Player enters the building | `BusinessState { current_staff: Vec<StableEntityId>, current_patrons: Vec<StableEntityId>, today_revenue, inventory_level }` | Low — entity list management, per-tick patron flow |
|
||||
| **LOD 3: Invested** | Player purchases / takes job | `BusinessFinancials { daily_revenue, daily_expenses, staff_satisfaction, supply_chain: Vec<SupplyLink>, customer_demographics }` | Medium — full economic tick, supply chain queries |
|
||||
|
||||
The LOD transition is **component promotion** — same pattern as D-026 tier transitions. bevy_ecs is literally designed for this. Add components on trigger, remove on distance/disengagement.
|
||||
|
||||
### Economic Success Follows Regional Prosperity
|
||||
|
||||
This is the key design insight. A bar's LOD 1 `turnover_bracket` is NOT independently seeded — it's **derived from the district's economic pressure state**:
|
||||
|
||||
```
|
||||
district_economic_health: Prosperous
|
||||
→ BusinessStats.turnover_bracket for all businesses in district: High ± noise
|
||||
→ When economic_health drops to Faltering:
|
||||
turnover_bracket shifts to Medium ± noise
|
||||
condition may degrade over game-time
|
||||
some businesses close (entity removal)
|
||||
```
|
||||
|
||||
This means the tycoon game IS the regional economic game. Buying a bar in a declining district means fighting against the pressure. Buying a bar in a prosperous district means riding the wave. The player reads the economic landscape, invests accordingly, and their investment feeds back into the pressure sim.
|
||||
|
||||
### LOD Transition Cost
|
||||
|
||||
| Transition | What Happens | Latency |
|
||||
|---|---|---|
|
||||
| LOD 0 → LOD 1 | Derive BusinessStats from pressure sim + district profile | Instant (~microseconds, table lookup) |
|
||||
| LOD 1 → LOD 2 | Generate or load current staff/patron entities. Activate NPC routines for building occupants. | Fast (~1-10ms, entity spawning + component attach) |
|
||||
| LOD 2 → LOD 3 | Attach financial simulation components. Connect to supply chain graph. | Instant (component attach, supply chain is a graph edge) |
|
||||
| LOD 3 → LOD 2 | Detach financial sim, snapshot state to save data | Instant |
|
||||
| LOD 2 → LOD 1 | Despawn transient patron NPCs, save staff state | Fast (~1ms) |
|
||||
|
||||
**Feasibility: MEDIUM.** The ECS component composition is natural. The harder work is designing the BusinessStats → BusinessState → BusinessFinancials data model, and the rules for how pressure drives them. Estimate: **3-5 weeks** for the full LOD system with financial simulation at LOD 3.
|
||||
|
||||
---
|
||||
|
||||
## 5. Revised Pipeline Cost Estimate
|
||||
|
||||
The shift from procedural generation to authored content + simulation changes the cost profile significantly.
|
||||
|
||||
### What Got Cheaper
|
||||
|
||||
| Layer | R1b Estimate | Revised Estimate | Why |
|
||||
|---|---|---|---|
|
||||
| **Layer 2: Location profiles** | 3-4 weeks (grammar + gen + hybrid authoring) | **1-2 weeks** (wiki → data pipeline + validation) | Authoring replaces generation. Engineering is just data ingestion. |
|
||||
| **Layer 3: Topography** | Days (tags) to 3-5 weeks (heightmaps) | **1-2 weeks** (authored map → constraint extraction) | Authored maps eliminate terrain generation entirely. |
|
||||
| **Seed-based variety** | Implicit cost across all layers (deterministic RNG management, seed-driven variation logic) | **Removed** | No seed variation. Canonical starting state + simulation drift. |
|
||||
|
||||
### What Got More Expensive (New Systems)
|
||||
|
||||
| System | Estimate | Why It's New |
|
||||
|---|---|---|
|
||||
| **Background pressure simulation** | 9-14 weeks | Economic + social + political pressure modeling. The product owner's core replayability mechanism. |
|
||||
| **LOD simulation primitives** | 3-5 weeks | Per-business economic sim at 4 LOD levels. |
|
||||
| **NPC/news generation hooks** | 2-3 weeks | On-demand generation triggered by simulation events. |
|
||||
| **Authored content pipeline** | 2-3 weeks | Wiki → structured data ingestion, map ingestion, GTTR compilation. |
|
||||
|
||||
### Revised Total
|
||||
|
||||
| Layer / System | Revised Cost | Notes |
|
||||
|---|---|---|
|
||||
| Layer 1: Galaxy | Days | Unchanged — systems.db loader |
|
||||
| Layer 2: Location profiles | 1-2 weeks | Wiki pipeline engineering. Content authoring is external. |
|
||||
| Layer 3: Topography | 1-2 weeks | Authored map ingestion + constraint extraction |
|
||||
| Layer 4: Gateways | Included in Station | No change |
|
||||
| Layer 5: Content spidering | 3-4 weeks | Add simulation-driven triggers alongside exploration triggers |
|
||||
| Layer 6: Settlement generation | 2-4 weeks | Simpler with authored terrain constraints. Boundary stitching still hard. |
|
||||
| Layer 7: District → Building | 6-10 weeks | Phase 1 + Phase 2 for 3 zone families. Core algorithmic work unchanged. |
|
||||
| Layer 8: Rendering | 2-4 weeks | Unchanged |
|
||||
| **NEW: Background simulation** | **9-14 weeks** | Economic + social + political pressure. Needs own workshop. |
|
||||
| **NEW: LOD primitives** | **3-5 weeks** | Business simulation at multiple LOD levels |
|
||||
| **NEW: Generation hooks** | **2-3 weeks** | NPC-driven + news-driven on-demand generation |
|
||||
| **NEW: Content pipeline** | **2-3 weeks** | Wiki → data, map → constraints, GTTR compilation |
|
||||
| **TOTAL** | **~30-50 weeks** | Up from 20-30, but different in character |
|
||||
|
||||
### The Character Shift
|
||||
|
||||
The R1b estimate was **~20-30 weeks of generation engineering.** The revised estimate is **~30-50 weeks of mixed engineering:**
|
||||
|
||||
- **Generation engineering** (Layers 5-7): ~11-18 weeks — actually *cheaper* per layer because authored inputs simplify constraint satisfaction
|
||||
- **Simulation engineering** (background sim + LOD): ~12-19 weeks — this is the **new load-bearing work**
|
||||
- **Data pipeline engineering** (Layers 2-3 + content pipeline): ~5-7 weeks — unglamorous but critical
|
||||
- **Rendering** (Layer 8): ~2-4 weeks — unchanged
|
||||
|
||||
The headline number is bigger, but the risk profile is *better*. R1b's pipeline had a "generation grammar for 300 locations" problem that was open-ended and hard to validate. The revised pipeline has a "build a data pipeline" problem that's well-understood and a "design an economic simulation" problem that's complex but decomposable.
|
||||
|
||||
**The critical path has shifted.** It was: Layer 2 grammar → Layer 6 settlement → Layer 7 districts. It's now: **Background simulation design → Pressure-to-entity bridge → Phase 1/2 generation reading pressure state.** The background simulation is the new load-bearing wall. Everything else reads from it.
|
||||
|
||||
---
|
||||
|
||||
## 6. Follow-Up Questions and Technical Risks
|
||||
|
||||
### Q1: What fidelity does the background simulation need at launch?
|
||||
|
||||
The interview says "full economic + social + political background simulation." That's the endgame. But background sim is the kind of system where you can ship LOD levels of the sim itself:
|
||||
|
||||
| Sim LOD | What It Models | Cost | Player-Visible Effect |
|
||||
|---|---|---|---|
|
||||
| **LOD 0: Static authored** | Wiki data is the "simulation." No drift. | Zero | None — world is a snapshot |
|
||||
| **LOD 1: Economic pressure only** | System-level GDP drift, trade route effects, industry health | 3-4 weeks | Prices change, some businesses open/close, NPC complaints shift |
|
||||
| **LOD 2: Economic + social** | Add population satisfaction, crime pressure, cultural tension | +2-3 weeks | NPC behavior changes, district condition drifts, security presence varies |
|
||||
| **LOD 3: Full pressure model** | Add political faction shifts, governance stability, external events | +3-4 weeks | Faction control of districts changes, political events fire, governance type shifts |
|
||||
|
||||
**The question for the product owner:** Is LOD 1 sufficient for the first playable build, with LOD 2-3 as enrichment? Or is the full pressure model needed for the core game loop to work?
|
||||
|
||||
**Why this matters architecturally:** LOD 1 can ship in weeks. LOD 3 needs a dedicated workshop to design the pressure interaction model. The data architecture should support all levels from day one, but the simulation rules can layer.
|
||||
|
||||
### Q2: How are authored world maps represented?
|
||||
|
||||
The product owner said "authored world maps for all planets and moons." What format?
|
||||
|
||||
| Format | Engineering Cost | Authoring Tool |
|
||||
|---|---|---|
|
||||
| **Tagged regions** (JSON/YAML: region name → terrain type + bounding polygon) | Cheap (1 week) | Any text editor. Low fidelity. |
|
||||
| **Annotated images** (PNG heightmap + region overlay, like Crusader Kings province maps) | Medium (2-3 weeks for ingestion pipeline) | Image editor. Medium fidelity. |
|
||||
| **d2/SVG vector maps** (topology diagram with named regions and connections) | Cheap-Medium (1-2 weeks) | d2 tool (already in the stack). Good for settlement placement, bad for terrain detail. |
|
||||
| **Tiled/Godot TileMap** (authored in a map editor with terrain brushes) | Medium (2-3 weeks) | Tiled or Godot editor. High fidelity, high authoring effort per planet. |
|
||||
|
||||
**My recommendation:** Start with d2 vector maps for topology (regions, connections, terrain types) and add image heightmaps later for the visual world map. The generation pipeline only needs the topology — "District A is coastal, District B is mountain, they connect via a valley corridor." That's a graph, not a heightmap.
|
||||
|
||||
### Q3: How does determinism work without seeds?
|
||||
|
||||
D-010 mandates deterministic simulation. The current architecture uses `SimRng` (seeded RNG). If replayability comes from simulation drift rather than seed variation, the determinism requirement shifts:
|
||||
|
||||
- **Same starting state + same player actions → same world state.** This is traditional determinism and is preserved.
|
||||
- **Same starting state + different player actions → different world state.** This is the intended replayability — player agency creates divergence.
|
||||
- **Background simulation must be deterministic.** Even though it runs on "spare cores" with variable timing, results must be identical given the same inputs. This means background sim tasks must be gated on a deterministic clock (game-minutes) and applied in a fixed order.
|
||||
|
||||
**Risk: Wall-clock-dependent background sim.** If background tasks process "as much as they can" in available CPU time, two machines with different CPU speeds produce different world states at the same game-time. This VIOLATES D-010. The fix: background sim advances in discrete game-minute steps regardless of CPU availability. Slower machines fall behind (sim debt) but produce identical results when they catch up. Same pattern as frame-independent physics.
|
||||
|
||||
### Q4: Content authoring bottleneck
|
||||
|
||||
The pipeline now depends on authored content for 300+ systems. Who authors this? At what pace? And what blocks engineering while authoring is in progress?
|
||||
|
||||
**Risk:** Engineering builds a wiki → data pipeline, but the wiki isn't populated fast enough for testing. Mitigation: **generate placeholder profiles from systems.db attributes** for engineering testing, with a validation flag that marks them "generated, not reviewed." Authored content replaces placeholders over time. The generation grammar from R1b isn't wasted — it becomes the **placeholder generation tool** that produces testable-but-not-final location profiles.
|
||||
|
||||
### Q5: Miri's heritage root framework — what survives the deprecation?
|
||||
|
||||
D-104 and D-105 are flagged as stale. Miri's R1b questions (Q1-Q5) are built on the 7 heritage roots (Frost/Stone/Tide/Vine/Dust/Iron/Salt). The interview replaces these with real-world cultural corridors (Commonwealth, Iberian/Latin American, East Asian, Northern European).
|
||||
|
||||
**The room-grammar framework (Miri Q5) still applies** — the token layers (privacy_default, sightline_character, gathering_orientation, threshold_character) are excellent regardless of whether the cultural axis is "Frost" or "Northern European isolationist tradition." The *labels* change, the *architecture* doesn't.
|
||||
|
||||
**Risk:** If the cultural framework is in flux, the generation pipeline can't lock its cultural input format. Need a decision on whether cultural identity is a continuous parameter space (Miri's option C) or a discrete set of authored cultural profiles. I recommend the product owner settle this before generation engineering begins.
|
||||
|
||||
### Technical Risk Summary
|
||||
|
||||
| Risk | Severity | Mitigation |
|
||||
|---|---|---|
|
||||
| Background sim non-determinism from variable CPU timing | **HIGH** | Gate on game-minute clock, not wall-clock. Apply results in fixed order. |
|
||||
| Content authoring bottleneck blocks engineering testing | **MEDIUM** | Placeholder generation from systems.db attributes for dev/test. |
|
||||
| Cultural framework in flux delays room grammar implementation | **MEDIUM** | Lock cultural input format early. Labels can change, data shape shouldn't. |
|
||||
| Background sim design underspecified — "needs its own workshop" | **HIGH** | Don't start sim engineering until the workshop produces a pressure model spec. |
|
||||
| LOD transition edge cases (player sells a business, what happens to LOD 3 state?) | **LOW** | Design LOD demotion rules alongside promotion rules. Snapshot on demotion. |
|
||||
| Authored world maps — format not decided | **MEDIUM** | Decide format in this workshop. Don't build ingestion pipeline for a format that changes. |
|
||||
|
||||
---
|
||||
|
||||
## Summary for the Team
|
||||
|
||||
The product owner's model is **simpler to generate, harder to simulate.** The generator reads authored data and paints spaces based on current simulation state. The replayability engine is the background simulation, not the seed. This is architecturally sound — it means the generator is a relatively straightforward painter, and the complexity lives in the simulation model where it belongs.
|
||||
|
||||
The critical path has shifted from "build a procedural generation grammar" to "design and implement a background economic/social/political simulation." That simulation needs its own workshop. Everything else — the data pipelines, the Phase 1/2 generation, the LOD system — is well-understood engineering that can proceed once the simulation design is specified.
|
||||
|
||||
Gestalt's economic cascade framework (Q1: economic axes, Q5: room-level cascade) is now MORE important, not less. In R1b, economic data was one of many generation inputs. In the revised model, economic pressure IS the primary driver of world variety. The cascade must be designed explicitly: pressure → district condition → business stats → room interior signals.
|
||||
|
||||
Nigel's replayability framework (Q1: fixed galaxy / seeded drama, Q4: world lives before player arrives) is **confirmed by the interview**. The implementation mechanism shifts from "seed-based variation" to "background simulation drift," but the player-facing outcome is identical: two playthroughs produce different worlds because the simulation trajectory diverged.
|
||||
|
||||
Ozzie's environmental archaeology (Q3) gets **stronger** in this model. "Only from real simulation events" means every piece of environmental evidence has a genuine causal chain. The generator doesn't fabricate history — it renders the consequences of simulation events. This is the highest-integrity version of Ozzie's vision.
|
||||
@@ -0,0 +1,624 @@
|
||||
# Tyre — SW1-R3: Endgame Pipeline Architecture
|
||||
|
||||
**Sub-workshop 1, Round 3 — Final Technical Synthesis**
|
||||
**Declarative. This is the architecture as it will be.**
|
||||
|
||||
---
|
||||
|
||||
## 1. The 8-Layer Pipeline — Updated Status
|
||||
|
||||
```
|
||||
Layer 1: Galaxy (300 systems) ██████████ BUILT — systems.db + wiki + star map
|
||||
Layer 2: Location profiles ░░░░░░░░░░ AUTHORED — wiki pipeline, not generated
|
||||
Layer 3: Planetary topography ░░░░░░░░░░ AUTHORED — annotated heightmaps + metadata
|
||||
Layer 4: Inbound gateways ████░░░░░░ DESIGNED — D-093/D-095, template stamped
|
||||
Layer 5: Content spidering ████░░░░░░ ARCH BUILT — D-026 tiers + chunk streaming
|
||||
Layer 6: Settlement generation ░░░░░░░░░░ NOT BUILT — placement on authored terrain
|
||||
Layer 7: District → building ███░░░░░░░ DATA MODEL — generator.rs, no algorithms
|
||||
Layer 8: 2D → 3D rendering ███░░░░░░░ MIGRATING — D-148/D-149 in progress
|
||||
```
|
||||
|
||||
### Layer-by-Layer Architecture
|
||||
|
||||
**Layer 1: Galaxy — READ ONLY**
|
||||
|
||||
The game server loads `systems.db` at startup and builds an in-memory graph of 300+1 systems. Each node carries: economic base, cultural corridor, gate topology, faction presence, habitable body count, narrative hooks, silence topics, ambient anxiety. The graph supports BFS pathfinding, neighbor lookup, and attribute filtering. Memory footprint: ~1-2MB. Load time: milliseconds.
|
||||
|
||||
The galaxy is **fixed and canonical**. Same 300 systems, same wormhole routes, every run. Internal economic/political state starts identical and drifts via background simulation. Player knowledge of system geography is durable across playthroughs.
|
||||
|
||||
**Engineering required:** Rust loader for systems.db → in-memory graph. **Cost: days.**
|
||||
|
||||
---
|
||||
|
||||
**Layer 2: Location Profiles — AUTHORED, READ ONLY**
|
||||
|
||||
Every inhabited planet, station, moon, and orbital in the 300 systems receives a wiki-authored profile. The generator does not generate profiles — it reads them.
|
||||
|
||||
Profile structure (per location):
|
||||
|
||||
```
|
||||
LocationProfile
|
||||
├─ location_type: Planet | Station | Moon | Orbital | AsteroidBase
|
||||
├─ physical: gravity, atmosphere, biome_summary, terrain_reference (→ Layer 3 heightmap)
|
||||
├─ settlement: population, economic_role[], founding_age, founding_culture
|
||||
├─ cultural: cultural_corridor (from systems.db), heritage_persistence, industrial_corridor
|
||||
├─ infrastructure: spaceport_class, transit_connections, district_count
|
||||
├─ economy: industries[], power_players[], trade_imports[], trade_exports[]
|
||||
└─ narrative: gttr_entry_path, planetary_screenshot_path, arrival_type_default
|
||||
```
|
||||
|
||||
The wiki → data pipeline parses authored markdown into structured `LocationProfile` records. Validation ensures completeness and internal consistency (a location with `spaceport_class: none` cannot be a `gate_topology: hub`).
|
||||
|
||||
**Engineering required:** Wiki markdown → LocationProfile parser + validator. **Cost: 1-2 weeks.** Content authoring is external and runs in parallel.
|
||||
|
||||
**Placeholder strategy:** For engineering testing before wiki content is complete, generate provisional profiles from systems.db attributes using the same rules that would have been the R1b generation grammar. These are flagged `"source": "provisional"` and replaced by authored content on merge.
|
||||
|
||||
---
|
||||
|
||||
**Layer 3: Planetary Topography — AUTHORED, READ ONLY**
|
||||
|
||||
Each inhabited planet/moon receives an **annotated heightmap package**:
|
||||
|
||||
```
|
||||
heightmaps/
|
||||
GJ-699/
|
||||
proxima-b/
|
||||
heightmap.png # Grayscale 16-bit PNG. Elevation data.
|
||||
metadata.json # Scale, origin, resolution, sea_level, units
|
||||
rivers.png # Binary overlay: river channels
|
||||
coastlines.png # Binary overlay: coastline boundaries
|
||||
biome_zones.json # Named polygon regions + biome type per region
|
||||
settlements.json # Settlement center points + approximate radius
|
||||
screenshot.png # Planetary shader screenshot for GTTR/wiki
|
||||
```
|
||||
|
||||
The generator consumes this package at settlement generation time (Layer 6). The heightmap provides hard constraints: mountains block corridors, rivers create district boundaries, coastlines produce port districts. The `biome_zones.json` maps regions to SettingType constraints (coastal → Urban/Maritime, mountain valley → Agricultural/Wilderness).
|
||||
|
||||
**Heightmap ingestion pipeline:**
|
||||
1. Load grayscale PNG → elevation grid at authored resolution
|
||||
2. Overlay rivers and coastlines as passability constraints
|
||||
3. Read biome zone polygons → tag each settlement site with terrain type
|
||||
4. Cache the processed constraint data per location (MessagePack, ~50-200KB per planet)
|
||||
|
||||
**Engineering required:** Heightmap ingestion + constraint extraction + caching. **Cost: 2-3 weeks.** Authoring tooling (the planetary shader plugin for screenshots) is separate scope.
|
||||
|
||||
**For stations and orbitals:** No heightmap. Module topology is authored as a structured JSON (ring sections, module connections, access corridors). Same principle: authored structure, generator reads it.
|
||||
|
||||
---
|
||||
|
||||
**Layer 4: Inbound Gateways — TEMPLATE STAMPED**
|
||||
|
||||
When the player arrives at a new system, they come through a horizon gate. The gate infrastructure is a Station SettingType district generated from template blocks.
|
||||
|
||||
Gate arrival architecture:
|
||||
- **Gate transit:** Player exits through a horizon gate aperture into a gate cluster block (D-093). Template-stamped: customs inspection area, transit hub, Commission/Institute monitoring presence scaled by system importance.
|
||||
- **Transit to destination:** Diegetic loading transition. Charter flight = port arrival scene. Normal transit = orbital view with GTTR insert window. Smuggler route = low-orbit darkness.
|
||||
- **First impression:** The guarantee system (D-097) enforces that from the gate entry point, the player sees at least one zone transition within 30 tiles and at least one readable arrival signal (security density, commercial activity, maintenance condition).
|
||||
|
||||
**Engineering required:** Gate cluster templates + arrival guarantee constraints. **Cost: included in Station SettingType Phase 2 + 1-2 days for gate-specific templates.**
|
||||
|
||||
---
|
||||
|
||||
**Layer 5: Content Spidering — PROGRESSIVE GENERATION**
|
||||
|
||||
Generation is triggered progressively, hidden behind diegetic transitions. Maps to D-026 simulation tiers:
|
||||
|
||||
```
|
||||
UNGENERATED ──[player enters system]──→ STATE-SAVED ──[player approaches]──→ BACKGROUND ──[player arrives]──→ ACTIVE
|
||||
│ │ │ │
|
||||
│ systems.db graph node only │ LocationProfile loaded │ Phase 2 chunks filled │ Full sim running
|
||||
│ No generation data │ Phase 1 skeleton generated │ NPC state machines active │ 10 tps, full perception
|
||||
│ │ ~1-2KB per district skeleton │ Chunk streaming ready │ All components attached
|
||||
```
|
||||
|
||||
**Progressive generation trigger sequence:**
|
||||
|
||||
| Player Action | Generation Triggered | Runs Where | Latency Budget |
|
||||
|---|---|---|---|
|
||||
| Starts new game | Load systems.db. Generate LocationProfiles for home system. Phase 1 + Phase 2 for starting district. | Main thread (one-time startup) | 2-5 seconds (acceptable for new game) |
|
||||
| Enters transit to new system | LocationProfiles for destination (if not authored yet → load from wiki data). Phase 1 skeletons for destination district + neighbors. | tokio background tasks during transit loading | Hidden behind transit scene (5-30 seconds of diegetic travel) |
|
||||
| Arrives at destination | Phase 2 chunk fill for destination district within streaming radius. Activate NPCs. | Main thread (generation) + chunk_streaming.rs (loading) | <500ms total. BSP fills a chunk in <5ms. 8-chunk radius = ~40ms. |
|
||||
| Walks toward district boundary | Phase 2 for adjacent district chunks (pre-generation). | tokio background tasks | Hidden behind walking time. Pre-generate 2 chunks ahead. |
|
||||
|
||||
**Heightmap consumption in progressive generation:**
|
||||
|
||||
When generating a settlement (Layer 6), the generator loads the planet's cached constraint data. Settlement center points from `settlements.json` are already authored. The generator places districts around those points, respecting elevation constraints, river boundaries, and biome zones. This happens once per settlement, during the transit-to-system phase.
|
||||
|
||||
**Engineering required:** Generation trigger hooks in chunk_streaming.rs (the TODO already exists). Async task spawning for background generation. Cache management (LRU + MessagePack persistence). **Cost: 3-4 weeks.**
|
||||
|
||||
---
|
||||
|
||||
**Layer 6: Settlement Generation — CONSTRAINT PLACEMENT ON AUTHORED TERRAIN**
|
||||
|
||||
Given a LocationProfile (population, economic role, industries) and authored terrain constraints (heightmap + settlements.json), generate the settlement's district layout.
|
||||
|
||||
**Settlement generation algorithm:**
|
||||
|
||||
```
|
||||
Input: LocationProfile + terrain constraints
|
||||
│
|
||||
├─ 1. Read settlement center point from settlements.json
|
||||
├─ 2. Determine district count from population + economic complexity
|
||||
│ (population 500K → 8-12 districts, population 2K → 1-2 districts)
|
||||
├─ 3. Assign district types from economic role
|
||||
│ (manufacturing base → 3 Industrial, 2 Commercial, 2 Residential, 1 Transit, 1-4 Mixed)
|
||||
├─ 4. Place districts on terrain, respecting:
|
||||
│ - River boundaries (districts don't cross rivers; bridges connect them)
|
||||
│ - Elevation constraints (no district on a mountain peak)
|
||||
│ - Coastline (Maritime districts on coast, port infrastructure)
|
||||
│ - Biome zones (Agricultural districts on arable land)
|
||||
├─ 5. Generate road/transit network between districts
|
||||
│ (graph: districts as nodes, roads as edges, respecting terrain)
|
||||
├─ 6. Compute district boundary access points
|
||||
│ (each shared boundary has 1-3 access points for stitching)
|
||||
└─ Output: SettlementSkeleton with district positions, types, boundaries, road network
|
||||
```
|
||||
|
||||
**CityCrafter3D patterns apply at this level:** grid-based block layout, noise-based density variation, road merging at intersections, multi-block reservations. The key difference: our placement is constrained by authored terrain, not by noise alone.
|
||||
|
||||
**Engineering required:** Settlement placement algorithm + road network generation + district boundary access point computation. **Cost: 2-4 weeks.** District boundary stitching (ensuring adjacent districts have compatible edges) is the hardest sub-problem.
|
||||
|
||||
---
|
||||
|
||||
**Layer 7: District → Building — FULL GENERATION (Phase 1 + Phase 2)**
|
||||
|
||||
This is the algorithmic heart of the generator. Data model is built (generator.rs, 579 lines). Algorithms are not.
|
||||
|
||||
**Phase 1: Skeleton Generation**
|
||||
|
||||
```
|
||||
Input: DistrictType + SettingType + boundary constraints + economic pressure state
|
||||
│
|
||||
├─ 1. 4×4 block grid allocation
|
||||
├─ 2. Zoning assignment (Residential/Commercial/Industrial/Mixed/Civic/Transit/Green)
|
||||
│ driven by DistrictType + economic pressure
|
||||
├─ 3. Multi-block reservation placement (landmarks, parks, terminals)
|
||||
├─ 4. Corridor spine carving (main paths through district)
|
||||
├─ 5. Social site placement (bars, markets, offices, clinics) with triangle assignments
|
||||
├─ 6. Era tagging per block
|
||||
│ driven by simulation state, not seed
|
||||
│ (Prosperous district → Commission-era blocks. Declining district → Decay/EmergencyExtension blocks.)
|
||||
├─ 7. Guarantee audit (D-097)
|
||||
│ Tier 1: every inhabited district has Social Hub + Informal Zone + Encounter Corridor
|
||||
│ Tier 2: Full-complexity districts get full 13-check audit
|
||||
│ Initially: audit logs warnings, does not block generation
|
||||
└─ Output: DistrictSkeleton
|
||||
```
|
||||
|
||||
**Phase 2: Chunk Fill**
|
||||
|
||||
```
|
||||
Input: BlockSkeleton + ZonePalette + economic pressure state
|
||||
│
|
||||
├─ 1. BSP room subdivision (Binary Space Partition)
|
||||
│ Recursive split produces organic room layouts
|
||||
│ Integer math only (D-010 determinism)
|
||||
│ Seeded per-block via SimRng for consistent regeneration
|
||||
├─ 2. Template stamping for social site rooms
|
||||
│ Bar template, market template, office template → placed in BSP-carved space
|
||||
├─ 3. Corridor carving (L-shaped or A* between room centers)
|
||||
├─ 4. Door placement at room-corridor intersections
|
||||
├─ 5. Object/furniture placement
|
||||
│ driven by room function + economic pressure + cultural corridor
|
||||
│ a prosperous Commonwealth bar ≠ a declining East Asian bar
|
||||
├─ 6. Condition application
|
||||
│ Pristine/Functional/Worn/Derelict derived from economic pressure state
|
||||
│ Block era modifies baseline (Decay-era blocks start at Worn minimum)
|
||||
└─ Output: chunk tile data (TileKind grid + object placements + door positions)
|
||||
```
|
||||
|
||||
**The generator reads simulation pressure state, not seeds.** Two players visiting the same district at different simulation times get different era tags, different condition levels, different object density. The canonical starting state produces the same district on game-start. Simulation drift produces visible changes over time.
|
||||
|
||||
**Zone type families share Phase 2 fill logic:**
|
||||
|
||||
| Family | Members | Fill Algorithm | Shared Code |
|
||||
|---|---|---|---|
|
||||
| **Interior** | Station, Orbital, Specialized | BSP rooms + corridors + doors | ~80% shared. Station is the base implementation. |
|
||||
| **Urban** | Urban, Industrial, Maritime | Lot subdivision + building footprints + street network | ~70% shared. Building density and height differ. |
|
||||
| **Natural** | Wilderness, Agricultural, Water | Terrain mesh + vegetation/crop placement + path network | ~60% shared. Agricultural has regular grid patterns; wilderness is noise-based. |
|
||||
|
||||
**Engineering required:** Phase 1 skeleton (3-5 weeks, constraint satisfaction is the hard part). Phase 2 fill for Interior family (2-3 weeks, BSP is well-understood). Phase 2 for Urban family (2-3 weeks, CityCrafter3D patterns transfer). Phase 2 for Natural family (2-3 weeks, RetroTerrain shader technique applies). **Total: 9-14 weeks.**
|
||||
|
||||
---
|
||||
|
||||
**Layer 8: 2D → 3D Rendering — RENDERING-AGNOSTIC DATA**
|
||||
|
||||
The server generates tile grids with type + z-level + position. The renderer interprets them. The current 2D TileMapLayer renderer filters z > 0 and displays what it can. The 3D renderer (D-148 Camera3D + GridMap) replaces it when ready. Zero throwaway work in the generation pipeline.
|
||||
|
||||
**Engineering required:** 3D renderer migration (ongoing, Sprint 28+). **Cost: 2-4 weeks** for the GridMap rendering path. Not on the generation critical path.
|
||||
|
||||
---
|
||||
|
||||
## 2. Data Flow
|
||||
|
||||
```
|
||||
┌─────────────────────────────────────────────────────────────────────┐
|
||||
│ AUTHORED CONTENT │
|
||||
│ │
|
||||
│ wiki/star-systems/ ──→ systems.db (300 systems, 7 tables) │
|
||||
│ wiki/locations/ ──→ LocationProfile[] (per planet/station) │
|
||||
│ heightmaps/ ──→ Terrain constraint cache (per planet) │
|
||||
│ wiki/gttr/ ──→ GTTR entries (per system) │
|
||||
│ cultural-migration- ──→ Cultural corridor data (per system) │
|
||||
│ pressure.md │
|
||||
└────────────────┬────────────────────────────────────────────────────┘
|
||||
│ loaded at game start
|
||||
▼
|
||||
┌─────────────────────────────────────────────────────────────────────┐
|
||||
│ RUST SERVER (bevy_ecs) │
|
||||
│ │
|
||||
│ ┌──────────────────┐ ┌──────────────────────────────────┐ │
|
||||
│ │ Galaxy Graph │ │ Background Pressure Sim (tokio) │ │
|
||||
│ │ 300 system nodes │◄──►│ Economic: trade flows, industry │ │
|
||||
│ │ gate topology │ │ Social: satisfaction, tension │ │
|
||||
│ │ faction state │ │ Political: faction influence │ │
|
||||
│ └────────┬─────────┘ │ Updates every game-minute │ │
|
||||
│ │ └──────────────┬───────────────────┘ │
|
||||
│ │ │ pressure deltas │
|
||||
│ ▼ ▼ │
|
||||
│ ┌──────────────────────────────────────────────────────────┐ │
|
||||
│ │ GENERATOR PIPELINE │ │
|
||||
│ │ │ │
|
||||
│ │ LocationProfile + TerrainConstraints + PressureState │ │
|
||||
│ │ │ │ │
|
||||
│ │ ├─→ Settlement placement (Layer 6) │ │
|
||||
│ │ ├─→ DistrictSkeleton (Phase 1) │ │
|
||||
│ │ └─→ Chunk tile data (Phase 2) │ │
|
||||
│ │ │ │ │
|
||||
│ └────────────────────┼──────────────────────────────────────┘ │
|
||||
│ │ │
|
||||
│ ┌────────────────────┼──────────────────────────────────────┐ │
|
||||
│ │ ENTITY SIMULATION (D-026 tiers) │ │
|
||||
│ │ │ │ │
|
||||
│ │ Active (80 NPCs) ◄── tile data + NPC spawns │ │
|
||||
│ │ Background (2K) ◄── state machine updates from pressure │ │
|
||||
│ │ State-saved (10K+)◄── skeleton data only │ │
|
||||
│ └────────────────────┼──────────────────────────────────────┘ │
|
||||
│ │ ObserverSnapshot (MessagePack) │
|
||||
│ ▼ │
|
||||
└─────────────────────────────────────────────────────────────────────┘
|
||||
│ IPC (MessagePack, D-020)
|
||||
▼
|
||||
┌─────────────────────────────────────────────────────────────────────┐
|
||||
│ GODOT CLIENT │
|
||||
│ │
|
||||
│ ObserverSnapshot ──→ WorldRenderer ──→ GridMap (3D tiles) │
|
||||
│ ──→ EntityRenderer ──→ CharacterCompositor (3D) │
|
||||
│ ──→ FogRenderer ──→ Fog shader │
|
||||
│ ──→ UIRenderer ──→ Insert HUD, galaxy map, GTTR │
|
||||
└─────────────────────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 3. Progressive Generation Behind Diegetic Transitions
|
||||
|
||||
Every generation step is hidden behind a moment where the player is already waiting for something else.
|
||||
|
||||
| Diegetic Moment | What the Player Experiences | What Generates Behind It |
|
||||
|---|---|---|
|
||||
| **New game start** | Character creation + opening narrative | Home system LocationProfiles loaded. Starting district Phase 1 + Phase 2. Starting NPCs spawned. (2-5 seconds) |
|
||||
| **Gate transit** | Transit scene: gate aperture VFX, insert shows GTTR entry + planetary screenshot, system stats | Destination system LocationProfiles. Destination terrain constraints loaded. Settlement placement. Phase 1 skeletons for destination + neighbor districts. (5-15 seconds, hidden behind 10-30 second transit scene) |
|
||||
| **Shuttle/transit ride** | Interior of shuttle (MobileChunk) or loading screen with diegetic framing | Phase 2 fill for destination district. NPC population spawned for destination. Adjacent district Phase 1 pre-generation. (1-5 seconds) |
|
||||
| **Walking to district boundary** | Player walks through corridor/street toward next district | Adjacent district Phase 2 chunks pre-generated 2 chunks ahead of player position. Chunk streaming activates. (<100ms per chunk, invisible) |
|
||||
| **Entering a building** | Door transition (brief fade or animation) | Building interior LOD promotion: LOD 0 → LOD 1 (BusinessStats derived). Staff/patron NPCs spawned if first visit. (<50ms) |
|
||||
|
||||
**Heightmap consumption timing:** Terrain constraint data is loaded once per planet, during the gate transit phase. The processed constraint cache (~50-200KB) is kept in memory for the duration of the player's stay in the system. When the player leaves the system, the cache is evicted (LRU). If they return, it reloads from disk cache.
|
||||
|
||||
**The player never sees a "generating..." screen after new-game startup.** All subsequent generation runs during diegetic transitions that are already part of the game's pacing.
|
||||
|
||||
---
|
||||
|
||||
## 4. Background Simulation Architecture
|
||||
|
||||
### Two-Layer Model
|
||||
|
||||
The simulation runs on two independent layers with different execution models:
|
||||
|
||||
| Layer | Scope | Data Model | Execution | Clock |
|
||||
|---|---|---|---|---|
|
||||
| **Entity Simulation** | Per-NPC: movement, perception, dialogue, routines | bevy_ecs World (Components on Entities) | Main tick thread, 10 tps | SimulationTime (tick counter) |
|
||||
| **Pressure Simulation** | Per-system, per-settlement: economics, faction balance, social tension, trade flows | Standalone structs (not ECS) | tokio thread pool, capped | Game-minute clock (deterministic) |
|
||||
|
||||
### Pressure Simulation — tokio Architecture
|
||||
|
||||
```rust
|
||||
// Conceptual structure — not final API
|
||||
|
||||
struct PressureSimRuntime {
|
||||
runtime: tokio::runtime::Runtime, // Capped thread pool (N = available_cores - 2)
|
||||
state: Arc<RwLock<PressureState>>,
|
||||
result_rx: crossbeam::channel::Receiver<PressureDelta>,
|
||||
snapshot_tx: crossbeam::channel::Sender<PressureSnapshot>,
|
||||
}
|
||||
|
||||
struct PressureState {
|
||||
systems: BTreeMap<SystemId, SystemPressure>,
|
||||
trade_flows: BTreeMap<(SystemId, SystemId), TradeFlow>,
|
||||
faction_influence: BTreeMap<(FactionId, SystemId), f64>,
|
||||
// All collections BTreeMap for D-010 determinism
|
||||
}
|
||||
|
||||
struct SystemPressure {
|
||||
economic_health: ProsperityLevel, // Prosperous/Growing/Stable/Faltering/Declining
|
||||
industries: BTreeMap<IndustryId, IndustryHealth>,
|
||||
social_satisfaction: f64,
|
||||
political_stability: f64,
|
||||
trade_imports: Vec<TradeGood>,
|
||||
trade_exports: Vec<TradeGood>,
|
||||
recent_events: Vec<PressureEvent>,
|
||||
}
|
||||
```
|
||||
|
||||
### Game-Minute Clock — Determinism Guarantee
|
||||
|
||||
```
|
||||
Main sim tick (100ms real-time at 10 tps)
|
||||
│
|
||||
├─ Every 10 ticks (= 1 game-minute):
|
||||
│ ├─ Snapshot current PressureState → PressureSnapshot
|
||||
│ ├─ Send snapshot to tokio runtime via channel
|
||||
│ └─ Collect any completed PressureDelta from previous minute
|
||||
│ └─ Apply deltas to PressureState in fixed order (system_id ascending)
|
||||
│
|
||||
tokio runtime (background, capped CPU):
|
||||
│
|
||||
├─ Receives PressureSnapshot
|
||||
├─ Runs pressure simulation for game-minute N:
|
||||
│ ├─ Trade flow propagation (bulk imports/exports between connected systems)
|
||||
│ ├─ Industry health updates (supply availability, demand, corporate events)
|
||||
│ ├─ Social pressure calculation (satisfaction from economic health + political stability)
|
||||
│ ├─ Faction influence shifts (from economic leverage, political events, player actions)
|
||||
│ └─ Event injection (storyteller may inject corporate disasters, portal closings, political shifts)
|
||||
├─ Produces PressureDelta
|
||||
└─ Sends delta via channel → main sim consumes on next game-minute boundary
|
||||
```
|
||||
|
||||
**Determinism:** The tokio runtime scheduling is non-deterministic (tasks may run in any order), but each task is internally deterministic (BTreeMap iteration order, seeded where needed). Results are collected and applied in a fixed order (system_id ascending) at the game-minute boundary. Slower machines accrue sim debt (pressure sim falls behind) but produce identical results when they catch up. This is the frame-independent physics pattern applied to economic simulation.
|
||||
|
||||
**CPU capping:** `tokio::runtime::Builder::new_multi_thread().worker_threads(N)` where N = `std::thread::available_parallelism() - 2` (reserve 2 cores for main sim + OS). Minimum N = 1. The runtime processes as many game-minutes as it can within available CPU. If it falls behind, the pressure sim is simply older — entities read slightly stale pressure data, which is acceptable (economic conditions don't change meaningfully within seconds of game-time).
|
||||
|
||||
### Propagation Network Model
|
||||
|
||||
The PO's reframe: the background sim is a **propagation network**, not a chaos engine. Events propagate through the trade/political network:
|
||||
|
||||
```
|
||||
Event: Corporate disaster at System A (factory explosion)
|
||||
│
|
||||
├─ System A: industry health drops, unemployment rises, export volume decreases
|
||||
├─ Trade partners of A: import shortage for A's exports, price increase
|
||||
├─ 2nd-degree partners: substitution effects (who else can supply what A exported?)
|
||||
├─ Faction with presence at A: influence drops at A, may shift resources from other systems
|
||||
└─ Political: governance stability at A drops, Commission may intervene
|
||||
```
|
||||
|
||||
Bulk import/export lists per system (already implied by systems.db economic data) drive the trade flow graph. Every system has inputs and outputs. Disruptions cascade. The interconnected network topology naturally creates non-trivial propagation patterns.
|
||||
|
||||
**Equilibrium is signal, not failure.** A stable economy shows the effect of the player's choices (or non-choices). The player reads economic stability or instability as information. The system doesn't need artificial chaos injection — event injection from the storyteller + player actions provide sufficient perturbation.
|
||||
|
||||
---
|
||||
|
||||
## 5. NPC/News Generation Hook Architecture
|
||||
|
||||
### Hook System
|
||||
|
||||
```
|
||||
┌─────────────────────────────────────────────────────────┐
|
||||
│ GENERATION MANDATE QUEUE │
|
||||
│ │
|
||||
│ Mandate { location, trigger, constraints, priority } │
|
||||
│ │
|
||||
│ Sources: │
|
||||
│ ├─ Player exploration (progressive generation) │
|
||||
│ ├─ NPC-driven hook (deep interaction with distant NPC) │
|
||||
│ ├─ News-driven hook (simulation event at a location) │
|
||||
│ └─ Storyteller (narrative-paced world expansion) │
|
||||
│ │
|
||||
│ Consumer: Generator pipeline (background tokio tasks) │
|
||||
└─────────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
### NPC-Driven Generation
|
||||
|
||||
**Trigger:** Player forms a deep relationship (not casual) with an NPC whose `home_location` references an ungenerated or partially-generated location.
|
||||
|
||||
**Flow:**
|
||||
|
||||
1. Deep interaction fires → system reads NPC's `home_location: { system: GJ-699, settlement: Proxima Station, district: 7, block: 3, unit: 12 }`
|
||||
2. System creates a GenerationMandate:
|
||||
```
|
||||
Mandate {
|
||||
location: GJ-699 / Proxima Station / District 7,
|
||||
trigger: NpcHome { npc_id, block: 3, unit: 12 },
|
||||
constraints: {
|
||||
block_3_economic_tier: must match NPC's presented wealth,
|
||||
block_3_condition: must match NPC's cultural presentation,
|
||||
unit_12_function: Residential,
|
||||
unit_12_cultural_corridor: NPC's corridor identity,
|
||||
},
|
||||
priority: Background (not urgent — player must travel to visit)
|
||||
}
|
||||
```
|
||||
3. Mandate enters the queue. Background generation processes it during idle time.
|
||||
4. When processed: Phase 1 skeleton for District 7 places Block 3 with the mandated economic tier. Phase 2 fills Block 3, creating Unit 12 as a residential space matching the NPC's cultural corridor. A ChunkMutation marks Unit 12 as the NPC's home.
|
||||
5. NPC's home is now visitable. If the player travels to GJ-699, District 7 is already generated.
|
||||
|
||||
**Consistency guarantee:** The mandate carries constraints derived from the NPC's presentation. The guarantee audit ensures these constraints are satisfied. If they can't be (pathological edge case), the audit logs a warning and places the home in the closest valid block.
|
||||
|
||||
**Latency:** Not real-time. The player meets the NPC now; generation runs in background. Even worst-case (immediate teleportation), Phase 1 + Phase 2 for one district is <1 second total.
|
||||
|
||||
### News-Driven Generation
|
||||
|
||||
**Trigger:** Background simulation produces an event (gas main explosion, factory closure, political uprising) at a specific location.
|
||||
|
||||
**Critical design principle: events read world state, don't mandate content.** The storyteller generates news about things that already exist in the simulation's model of the world — including locations that have Phase 1 skeletons but no Phase 2 fill.
|
||||
|
||||
**Flow:**
|
||||
|
||||
1. Pressure simulation produces event: `{ type: InfrastructureFailure, system: Kepler Haven, district: East, affected_block: 5 }`
|
||||
2. If the location has a Phase 1 skeleton: event becomes a ChunkMutation (damage overlay) applied to block 5. Phase 2 fill for that block incorporates the damage when generated.
|
||||
3. If the location is ungenerated: the mandate creates a skeleton with the event pre-baked. When the player visits, the damage is part of the initial generation — there's no "pristine then damaged" transition.
|
||||
4. News system reports the event via the Reach-wide news ticker. If the player visits, the damage exists.
|
||||
|
||||
**Frequency:** Sparse. The PO specified "sparse frequency to avoid disruption." The storyteller gates news-driven generation to ~1-3 events per game-day across the entire Reach. Most events are economic (prices, shortages) not physical (explosions, construction).
|
||||
|
||||
---
|
||||
|
||||
## 6. LOD Economic Primitives
|
||||
|
||||
Four LOD levels for business/social site entities, implemented as ECS component promotion:
|
||||
|
||||
### LOD 0: Exists (metadata only)
|
||||
|
||||
**Trigger:** Phase 1 skeleton generation places the social site.
|
||||
**Components:** `SocialSite { site_type: SocialSiteType, block_id: BlockId, stable_id: StableId }`
|
||||
**Cost:** Zero simulation cost. Metadata only.
|
||||
|
||||
### LOD 1: Observable (derived stats)
|
||||
|
||||
**Trigger:** Player enters the district containing the business. Or: player queries the business via insert device.
|
||||
**Components added:**
|
||||
```rust
|
||||
struct BusinessStats {
|
||||
turnover_bracket: TurnoverBracket, // High/Medium/Low/Failing
|
||||
cost_tier: CostTier, // Luxury/Standard/Budget/Derelict
|
||||
employee_count: u16,
|
||||
patron_density: PatronDensity, // Packed/Busy/Moderate/Quiet/Empty
|
||||
condition: ConditionTier, // Pristine/Functional/Worn/Derelict
|
||||
}
|
||||
```
|
||||
**Derivation:** All fields derived from district economic pressure + business type. No independent simulation. Updated when pressure state changes (per game-hour at most).
|
||||
|
||||
```
|
||||
district_economic_health: Prosperous
|
||||
+ site_type: Bar
|
||||
+ cultural_corridor: Commonwealth
|
||||
→ turnover_bracket: High
|
||||
→ cost_tier: Standard (Commonwealth bars are never Luxury — cultural norm)
|
||||
→ patron_density: Busy (evening), Moderate (day)
|
||||
→ condition: Functional (well-maintained but not ostentatious)
|
||||
```
|
||||
|
||||
**Cost:** Near-zero. Table lookup on pressure change.
|
||||
|
||||
### LOD 2: Visited (entity-level)
|
||||
|
||||
**Trigger:** Player enters the building.
|
||||
**Components added:**
|
||||
```rust
|
||||
struct BusinessState {
|
||||
current_staff: Vec<StableEntityId>,
|
||||
current_patrons: Vec<StableEntityId>,
|
||||
today_revenue: u32,
|
||||
inventory_level: InventoryLevel, // Full/Adequate/Low/Critical
|
||||
open_hours: (GameHour, GameHour),
|
||||
}
|
||||
```
|
||||
**Simulation:** Staff and patron NPC entities are spawned (or promoted from Background tier) when the player enters. Patron flow follows daily patterns (quiet morning, lunch rush, evening peak). Revenue accumulates per patron visit. Inventory depletes and restocks on a daily cycle.
|
||||
|
||||
**Cost:** Low. Entity list management, per-tick patron flow check. ~10-20 NPCs per business.
|
||||
|
||||
### LOD 3: Invested (full financial sim)
|
||||
|
||||
**Trigger:** Player purchases the business, takes employment, or forms a deep economic relationship.
|
||||
**Components added:**
|
||||
```rust
|
||||
struct BusinessFinancials {
|
||||
daily_revenue: u32,
|
||||
daily_expenses: u32,
|
||||
staff_satisfaction: f32,
|
||||
supply_chain: Vec<SupplyLink>,
|
||||
customer_demographics: BTreeMap<CulturalCorridor, f32>,
|
||||
monthly_profit_history: VecDeque<i32>, // Last 12 months
|
||||
competitive_position: CompetitivePosition,
|
||||
}
|
||||
|
||||
struct SupplyLink {
|
||||
supplier_id: StableEntityId,
|
||||
good: TradeGood,
|
||||
reliability: f32,
|
||||
cost: u32,
|
||||
}
|
||||
```
|
||||
**Simulation:** Full economic tick. Supply chain queries (are suppliers delivering? at what price?). Staff satisfaction from wages vs district norms. Customer demographics from district cultural composition + foot traffic patterns. Competitive position from nearby similar businesses.
|
||||
|
||||
**Economic success follows regional prosperity:** The business's revenue baseline is derived from the district's pressure state. A thriving bar in a declining district fights against the current. A mediocre bar in a booming district rides the wave. The tycoon reads the economic landscape and invests accordingly.
|
||||
|
||||
**Cost:** Medium. Full economic tick per game-minute for invested businesses. Budget: 10-50 invested businesses per active district (player can't meaningfully manage more).
|
||||
|
||||
### LOD Demotion
|
||||
|
||||
| Transition | Trigger | Action |
|
||||
|---|---|---|
|
||||
| LOD 3 → LOD 2 | Player sells business / quits job | Snapshot BusinessFinancials to save data. Remove component. Business continues at LOD 2 with stats derived from last financial state decaying toward district norm over game-days. |
|
||||
| LOD 2 → LOD 1 | Player leaves district | Despawn transient patron NPCs. Save staff state. Remove BusinessState. Stats revert to pressure-derived values. |
|
||||
| LOD 1 → LOD 0 | Player leaves system (district enters State-saved tier) | Remove BusinessStats. Metadata persists in skeleton. |
|
||||
|
||||
---
|
||||
|
||||
## 7. Revised Cost Estimate and Critical Path
|
||||
|
||||
### Cost Summary
|
||||
|
||||
| Layer / System | Effort | Category |
|
||||
|---|---|---|
|
||||
| **Layer 1:** Galaxy loader | Days | Data pipeline |
|
||||
| **Layer 2:** Wiki → LocationProfile pipeline | 1-2 weeks | Data pipeline |
|
||||
| **Layer 3:** Heightmap ingestion + constraint extraction | 2-3 weeks | Data pipeline |
|
||||
| **Layer 4:** Gate templates + arrival guarantees | Included in Layer 7 | Generation |
|
||||
| **Layer 5:** Progressive generation triggers + cache | 3-4 weeks | Generation infrastructure |
|
||||
| **Layer 6:** Settlement placement on terrain | 2-4 weeks | Generation |
|
||||
| **Layer 7:** Phase 1 skeleton + Phase 2 fill (3 families) | 9-14 weeks | Generation (core) |
|
||||
| **Layer 8:** 3D renderer migration | 2-4 weeks | Rendering (parallel) |
|
||||
| **Background pressure simulation** | 9-14 weeks | Simulation (new) |
|
||||
| **LOD economic primitives** | 3-5 weeks | Simulation (new) |
|
||||
| **NPC/news generation hooks** | 2-3 weeks | Generation hooks |
|
||||
| **Content pipeline tooling** | 1-2 weeks | Tooling |
|
||||
| | | |
|
||||
| **TOTAL** | **~35-55 weeks** | |
|
||||
|
||||
### Category Breakdown
|
||||
|
||||
| Category | Weeks | Character |
|
||||
|---|---|---|
|
||||
| **Data pipelines** (wiki, heightmaps, content tooling) | 4-7 | Well-understood. No design risk. |
|
||||
| **Generation core** (Layers 5-7 + hooks) | 16-25 | Algorithmic. BSP is proven. Constraint satisfaction (Phase 1 guarantees) is the hardest part. |
|
||||
| **Simulation** (pressure sim + LOD primitives) | 12-19 | **Requires dedicated design workshop before engineering.** Highest design risk. |
|
||||
| **Rendering** (Layer 8) | 2-4 | Parallel track. Not on critical path. |
|
||||
|
||||
### Critical Path
|
||||
|
||||
```
|
||||
┌─────────────────────────────────┐
|
||||
│ Background Simulation Workshop │
|
||||
│ (design: pressure model spec) │
|
||||
└──────────────┬──────────────────┘
|
||||
│
|
||||
┌────────────────────┼────────────────────┐
|
||||
│ │ │
|
||||
▼ ▼ ▼
|
||||
┌─────────────────┐ ┌─────────────────┐ ┌─────────────────┐
|
||||
│ Pressure Sim │ │ LOD Primitives │ │ Content Pipeline │
|
||||
│ Engineering │ │ (3-5 weeks) │ │ (4-7 weeks) │
|
||||
│ (9-14 weeks) │ └────────┬────────┘ └────────┬────────┘
|
||||
└────────┬────────┘ │ │
|
||||
│ │ │
|
||||
▼ ▼ ▼
|
||||
┌─────────────────────────────────────────────────────────────┐
|
||||
│ GENERATION PIPELINE │
|
||||
│ Layer 5 (triggers) → Layer 6 (settlement) → Layer 7 (fill) │
|
||||
│ (16-25 weeks) │
|
||||
│ Reads: pressure state + authored content + terrain data │
|
||||
└─────────────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
**The background simulation design workshop is the gate.** Nothing in the simulation category can start without a pressure model specification. The generation pipeline can start in parallel with the content pipeline (using provisional placeholder data), but it needs the pressure-to-entity bridge before Phase 1 era tagging and Phase 2 condition application are meaningful.
|
||||
|
||||
**Parallelizable tracks:**
|
||||
1. Content pipeline (Layers 2-3 data ingestion) — can start immediately
|
||||
2. Generation infrastructure (Layer 5 trigger hooks, Layer 6 settlement placement) — can start immediately with placeholder terrain data
|
||||
3. Phase 2 BSP + templates (Layer 7 Interior family) — can start immediately, pressure integration added later
|
||||
4. Background simulation — blocked on design workshop
|
||||
5. Rendering (Layer 8) — independent track, already in progress
|
||||
|
||||
**If all parallelizable tracks run concurrently, the wall-clock critical path is approximately 20-25 weeks from workshop completion to feature-complete pipeline.** The 35-55 week total reflects serial execution; with 2-3 engineers running parallel tracks, calendar time compresses significantly.
|
||||
@@ -0,0 +1,120 @@
|
||||
---
|
||||
title: "World Generation Architecture Workshop — Outcomes"
|
||||
workshop: world-generation
|
||||
date: 2026-03-24
|
||||
status: complete
|
||||
participants: Gestalt, Miri, Nigel, Ozzie, Tyre, Qatux (documenter)
|
||||
rounds: 3 (SW1 only — SW2-SW4 cancelled)
|
||||
---
|
||||
|
||||
# World Generation Architecture Workshop — Outcomes
|
||||
|
||||
## Workshop Summary
|
||||
|
||||
**Date:** 2026-03-24
|
||||
**Duration:** 3 rounds of Sub-Workshop 1 (Endgame Feature Vision)
|
||||
**Planned structure:** 4 sub-workshops (feature vision → technical architecture → v0.2 slice → implementation plan)
|
||||
**Actual outcome:** SW1 completed, SW2-SW4 cancelled — replaced by a 6-phase development cascade
|
||||
|
||||
## What Was Produced
|
||||
|
||||
1. **Endgame Feature Vision** — `endgame-feature-vision.md` (692 lines)
|
||||
- 8-layer generation pipeline (galaxy → room)
|
||||
- Cultural cascade (real-world corridor system replacing abstract heritage roots)
|
||||
- Replayability architecture (3-tier: player agency → simulation trajectory → generation hooks)
|
||||
- Player experience beats (7 beats from galaxy map to scale drop)
|
||||
- Background simulation design brief
|
||||
- X4: Foundations identified as the economic simulation reference model
|
||||
|
||||
2. **Interview answers** — `sw1-interview-answers.md`
|
||||
- All product owner decisions captured with rationale
|
||||
|
||||
3. **Per-round agent outputs** — R1a, R1b, R2, R3 files for all 5 agents + Qatux consolidation notes
|
||||
|
||||
## Key Decisions Locked
|
||||
|
||||
### Galaxy Level
|
||||
- 300+1 systems fixed and canonical, authored in wiki
|
||||
- Internal state drifts via background simulation (not seed-based)
|
||||
- Full galaxy map visible from start (inserts contain star charts)
|
||||
- Cultural geography: real-world migration corridors (Commonwealth, Iberian/LatAm, East Asian, Germanic) per `docs/design/cultural-migration-pressure.md`
|
||||
|
||||
### System / Location Level
|
||||
- Per-planet/station/moon profiles authored as wiki extensions
|
||||
- Full economic profile: multiple industries, power players, historical disruptions
|
||||
- Background simulation (econ + social + political) on spare CPU cores at capped load
|
||||
|
||||
### Topography
|
||||
- Hard constraint — mountains block, rivers create boundaries
|
||||
- Authored world maps for all planets and moons (annotated heightmaps)
|
||||
|
||||
### Arrival
|
||||
- Contextual by travel method, orbital view as default
|
||||
- Diegetic GTTR scouting window via insert
|
||||
|
||||
### Generated Spaces (endgame)
|
||||
- Full simulation primitives with LOD (depth scales with player engagement)
|
||||
- Hybrid NPC population — any ambient NPC can evolve to narrative through interaction
|
||||
- Cohesion at small/middle scale, variety at middle/large scale
|
||||
|
||||
### Generation Hooks
|
||||
- NPC-driven: meet someone → their home environment generates
|
||||
- News-driven: reach-wide events create visitable locations
|
||||
- Environmental archaeology from real simulation events only
|
||||
|
||||
## Course Correction: Development Cascade
|
||||
|
||||
During the Round 2 interview, the PO redirected the project from scoped v0.2 releases to a strict 6-phase development cascade. The rationale: superseded decisions on details kept causing confusion, re-priming agents into wrong-level discussions, and not progressing toward a realized product.
|
||||
|
||||
**v0.2 target dropped.** No more scoping negotiations.
|
||||
|
||||
### The 6 Phases
|
||||
|
||||
| Phase | Focus | Deliverable |
|
||||
|-------|-------|-------------|
|
||||
| 1 | Wiki content complete — all planets, moons, stations, heightmaps, artwork | Implant-ready Godot map of the Reach with click-throughs + wiki/GTTR popups |
|
||||
| 2 | Economics layer — supply/demand, transport, political/social pressure, corporations | Economics spreadsheets/graphs with runtime-tweakable simulation |
|
||||
| 3 | Planetary/moon maps & station layouts — cities, rivers, mountains, roads, biomes | Atlas of the Reach (implant app) |
|
||||
| 4 | Player control scheme — 2-floor test map, character rendering, walls/stairs/doors, lighting | Player viewport with final-version assets |
|
||||
| 5 | World generation (tile/chunk/block) — walkable world, parallel asset pipeline | Walkable generated world + asset catalog |
|
||||
| 6 | Detail coloring — room-level NPC population, cultural room grammar | Only when the world is walkable |
|
||||
|
||||
Each phase must complete before the next begins. Agents must not discuss detail from later phases.
|
||||
|
||||
## Stale D-Records Flagged for Supersession
|
||||
|
||||
| D-record | Issue |
|
||||
|----------|-------|
|
||||
| D-104 | Heritage root grammar overlays — uses 7 abstract roots, wiki uses real corridors |
|
||||
| D-105 | Heritage root grammar overlays (continued) |
|
||||
| D-101 | ZonePalette modifier axis A = HeritageRoot — needs remapping to corridor identity |
|
||||
| D-107 | References heritage roots — needs audit |
|
||||
|
||||
**Resolution:** Superseded — clean break. New D-records will describe corridor-to-room-grammar mapping (deferred to Phase 6).
|
||||
|
||||
## Future Workshop Topics
|
||||
|
||||
| Workshop | Priority | Blocked by |
|
||||
|----------|----------|-----------|
|
||||
| Background Simulation Design | CRITICAL | Phase 2 start |
|
||||
| Zone Type Phase 2 Fill | High | Phase 5 start |
|
||||
| NPC Generation Depth | High | Phase 5 start |
|
||||
| Cultural Cascade Authoring | Medium | Phase 6 start |
|
||||
| Authored Content Pipeline | Medium | Phase 1 in progress |
|
||||
|
||||
## Files Produced
|
||||
|
||||
```
|
||||
docs/workshops/world-generation/
|
||||
├── BRIEF.md (updated status: complete)
|
||||
├── workshop-outcomes.md (this file)
|
||||
├── endgame-feature-vision.md (main deliverable)
|
||||
├── sw1-interview-answers.md (PO decisions)
|
||||
├── sw1-round1-notes.md (R1a consolidation)
|
||||
├── sw1-round1b-notes.md (R1b consolidation)
|
||||
├── sw1-round2-notes.md (R2 consolidation)
|
||||
├── {agent}-sw1r1.md (R1a outputs, 5 files)
|
||||
├── {agent}-sw1r1b.md (R1b outputs, 5 files)
|
||||
├── {agent}-sw1r2.md (R2 outputs, 5 files)
|
||||
└── {agent}-sw1r3.md (R3 outputs, 5 files)
|
||||
```
|
||||
Reference in New Issue
Block a user