settled-reach/docs/workshops/wheres-the-fun/round3-tyre.md

title, description, type, status, workshop, agent, round, created

title	description	type	status	workshop	agent	round	created
Round 3: Tyre — Technical Architecture Proposal	Tyre's technical architecture proposal for implementation feasibility	workshop	archived	wheres-the-fun	tyre	3	2026-03-05

Round 3: Tyre — Technical Architecture Proposal

Workshop: Where's the Fun? | Round: 3 (Proposals) | Agent: Tyre (Technical Architect)

---

The Reframe Through an Architectural Lens

cracks knuckles

The interview landed hard. The vision is a single-character life sim — Sims meets Rimworld from one perspective. Detective is a job bookmark, not the game. The v0.1 vertical slice scoped out the player's entire tool suite (mystery board, journal, AR overlays, comms) and asked them to play with monologue alone. That's not a content gap. That's an architecture gap — we built the simulation backend but not the information frontend.

Here's the good news: the simulation engine we built is the right engine for a life sim. The bad news: the client-side information architecture doesn't exist yet. Let me break this down.

---

KEEP

1. The Rust simulation server (D-020)

The split architecture — Rust/bevy_ecs server, Godot dumb client, MessagePack IPC — is more correct for a life sim than it was for a detective game. A life sim needs:

• Hundreds of NPCs with persistent state (we have simulation tiers, D-026)
• A rich knowledge graph tracking relationships, facts, reputation (we have D-041)
• Deterministic simulation for save/load fidelity (we have D-010 principle 4)
• Multiple observer perspectives for multiplayer-ready architecture (we have D-010 principle 3)

The engine doesn't know there's "a detective." It knows there are entities with knowledge graphs and perception ranges. Swapping a detective bookmark for a tycoon bookmark is a content/configuration change, not an architecture change. This is exactly what D-010 principle 3 was designed for.

Verdict: The simulation core is the single biggest asset we have. It stays.

2. ObserverSnapshot as the universal client interface (D-054)

The variable-shape MessagePack snapshot was always designed for this. D-017 spec'd perception modes that change what the HUD shows. D-020 explicitly says "Variable structure supports variable HUD composition driven by perception modes." A detective's neural insert surfaces different widgets than a smuggler's street contact network than a tycoon's market feed.

Different bookmarks = different ObserverSnapshot shapes. The protocol already supports this. The client already renders what it receives without understanding the game logic.

Verdict: ObserverSnapshot is the right abstraction. It stays and grows.

3. Knowledge graph (D-041)

The per-entity BTreeMap knowledge graph with confidence levels, sources, and decay — this is the backbone of a life sim. It tracks what your character knows about every person, place, fact, and relationship. For a detective bookmark it surfaces contradictions and tells. For a tycoon bookmark it surfaces market intelligence and investment risks. For a smuggler bookmark it surfaces routes, contacts, and heat levels.

Same data structure. Different query patterns. Different rendering.

Verdict: Knowledge graph is the most reusable system we built. It stays.

4. Verb system architecture (interaction-verbs-v0.1.md)

The verbs[] array computed server-side per entity per tick — this extends naturally. v0.1 has 7 verbs. A life sim needs more: Buy, Sell, Hire, Apply, Bribe, Intimidate, Hack, Repair. Each is a VerbKind enum variant with priority logic. The architecture was designed for N verbs from day one.

Verdict: Verb pipeline stays. Verb list grows per bookmark.

5. Simulation tiers (D-026)

Active/Background/State-saved/Ungenerated is exactly what a life sim with 10K+ NPCs needs. The timestamp-based LRU eviction means the NPCs the player interacts with stay fully simulated. A tycoon's employees, a detective's suspects, a smuggler's contacts — all stay Active via scope tags.

Verdict: Tier system stays. Scope tags expand per career type.

---

CHANGE

1. Client information architecture — from monologue-only to diegetic tool suite

This is the biggest change and the highest priority. The interview confirmed the full vision was always: mystery board, journal, character glossary, AR overlays, comms, insert icons. Monologue was supposed to be a reasoning nudge, not the sole feedback channel.

Architecture impact: Moderate. Here's why.

The server already computes everything. The knowledge graph has the data. What's missing is the rendering pipeline — new sections in ObserverSnapshot that carry structured data to new client-side UI panels.

Concretely, the ObserverSnapshot needs new optional sections:

ObserverSnapshot {
    // Existing
    visible_entities, fog_state, monologue, nearby_interactions, ...

    // NEW: Diegetic tool data (populated based on bookmark/insert loadout)
    active_threads: Vec<ThreadSummary>,      // "Things your character is tracking"
    journal_entries: Vec<JournalEntry>,       // Structured knowledge log
    tool_widgets: Vec<ToolWidget>,            // Bookmark-specific HUD elements
    comms_messages: Vec<CommsMessage>,        // In-world communications
    ar_overlays: Vec<ArOverlay>,             // World-space annotations
}

Each section is optional (MessagePack handles missing fields). Each bookmark's server-side systems populate only the sections relevant to that career. The client renders what it receives.

Effort estimate:

• Server: New systems that query the knowledge graph and populate these sections. Each is a read-only system running once per game-minute (tick % 10 == 0). ~2-3 weeks for the core set.
• Protocol: Adding optional fields to ObserverSnapshot. ~2 days.
• Client: New UI panels that consume these sections. This is the bulk of the work — each tool (journal, thread tracker, AR overlay) is a Godot scene. ~3-4 weeks for minimum viable set.

Tier assessment: Challenging but doable in one sprint cycle (2 sprints). No engine rebuild.

2. Career bookmark system — onboarding as architecture, not content

CK3-style bookmarks are an architectural feature, not just a content swap. Each bookmark needs:

• A starting knowledge graph state (what does this character already know?)
• A starting relationship map (who do they know? who's their boss?)
• A tool loadout (which diegetic tools does this job provide?)
• An onboarding sequence (scripted first-30-minutes that teaches tools organically)

Architecturally, this means a BookmarkDefinition resource that the server loads at game start:

struct BookmarkDefinition {
    career: CareerType,              // Detective, Tycoon, Smuggler, etc.
    starting_knowledge: Vec<KnowledgeGrant>,
    starting_relationships: Vec<RelationshipSeed>,
    tool_loadout: Vec<ToolId>,       // Which insert tools this career gets
    onboarding_sequence: SequenceId, // Scripted opening (server-driven)
}

The simulation doesn't change. The ECS world is the same. What changes is the initial state and the observer configuration. Different bookmarks seed different knowledge, different relationships, different tools — and the existing ObserverSnapshot pipeline renders whatever results from that configuration.

Effort estimate:

• BookmarkDefinition loader + starting state seeding: ~1 week
• Per-bookmark tool loadout configuration: ~2 days per bookmark
• Onboarding sequence system (scripted events/tutorials): ~2 weeks for the framework, then content-driven per bookmark

Tier assessment: Moderate. The hardest part is the onboarding sequence system — it needs to be authored per bookmark but driven by server events, not client-side scripts. This is a new server system but fits cleanly into the existing event architecture.

3. Mission system with consequence spectrums

Jeroen's answer on objectives was clear: missions with varying success/failure and consequences. Not binary pass/fail. Not GTA objective markers. Diegetic missions that come through in-world channels (your boss calls, a contact pings, a notice appears) with outcomes on a spectrum.

This needs a MissionState component and a ConsequenceEngine:

struct MissionState {
    mission_id: MissionId,
    status: MissionStatus,          // Active, Completed, Failed, Abandoned
    objectives: BTreeMap<ObjectiveId, ObjectiveProgress>,
    outcome_score: f32,             // 0.0 (catastrophic) to 1.0 (perfect)
    consequences: Vec<ConsequenceId>, // Queued consequences based on outcome
}

The outcome score drives consequences: getting fired, enemies made, innocents harmed, reduced pay, reputation changes. These consequences feed back into the knowledge graph and relationship system. An NPC you screwed over in a mission remembers. Your employer's trust changes.

Effort estimate:

• Mission state tracking + objective progress: ~2 weeks
• Consequence engine (maps outcome scores to world-state changes): ~2 weeks
• Per-mission authored content (objectives, consequence trees): content-driven, ongoing

Tier assessment: This is the most complex new system. But it's self-contained — it reads from and writes to existing ECS components (knowledge graph, relationships, NPC state). It doesn't require changes to the simulation loop itself. Feasible. Challenging but doable.

4. NPC legibility — from dots to people

The interview was brutal: NPCs didn't register as human beings. This is partly visual (Araminta's domain) but partly architectural. The server sends entity data — the client needs richer data to render NPCs as people.

What the ObserverSnapshot currently sends per visible NPC: position, entity type, relationship color, verb options.

What it needs to also send for NPC legibility:

• Display name (obfuscated until identified per D-041 confidence levels — "Dock Worker" → "Kael")
• Current activity label ("Working at terminal", "Having a drink", "Walking to shift")
• Emotional state indicator (calm, stressed, nervous — derived from NPC behavioral state)
• Relationship summary (if known: "Your contact", "Your supervisor", "Stranger")

All of this data already exists server-side. It's in the NPC components, the knowledge graph, the routine system. We just don't pack it into the snapshot.

Effort estimate: ~3-5 days server, ~1 week client (rendering labels, activity indicators, name plates).

Tier assessment: Easy. This is the single cheapest high-impact change. The data exists. We just need to send it.

---

KILL

1. The detective-smuggler dual-character v0.1 scope

The vertical slice was framed as "play detective OR smuggler, same world, different knowledge." The interview says this framing was myopic. Detective and smuggler become two bookmarks among many, not the entire game.

What this means architecturally: We don't kill the dual-lens architecture (D-010 principle 3 makes multiple observers free). We kill the assumption that v0.1 proves itself by demonstrating detective-vs-smuggler divergence. Instead, v0.2 proves itself by demonstrating one career bookmark played to depth — with the life-sim tools working.

What survives: The dual-lens reveal becomes a later-game discovery, not the vertical slice thesis. The smuggler storyline and detective storyline become world content, not the frame.

2. Monologue as primary feedback channel

Kill as the primary channel. Keep as a supplementary channel. Monologue was always meant to be a reasoning nudge — "Huh, that's the third time he's checked his lattice." Not the player's only window into the knowledge graph. With the diegetic tool suite in place, monologue becomes flavor and nudges, which is what it was designed to be.

Architecture change: Reduce monologue priority in the attention hierarchy. When journal, threads, and AR overlays exist, monologue drops from "how you learn things" to "your character's personality showing through."

3. "No objectives" as a v0.1 stance

The interview confirmed this was never a design principle — it was the absence of diegetic tools. Kill the philosophical position. Replace with: "diegetic objectives delivered through in-world tools, varying by career bookmark, with spectrum outcomes."

---

The Cheapest Path: Current Architecture to Life-Sim Vertical Slice

Here's what I'd sequence, in order of impact-per-effort:

Phase 1: Make the world readable (1 sprint)

1. NPC legibility data in ObserverSnapshot — names, activities, emotional state, relationship labels. Server: 3-5 days. Client: 5-7 days. This unblocks everything else. If NPCs are dots, nothing works.
2. Visual hierarchy (Araminta's domain, but needs server support for priority data). Server provides attention-priority per entity. Client renders tiers. Server: 2 days. Client: Araminta's estimate.

Phase 2: Give the player tools (1-2 sprints)

3. Thread tracker — "Things your character is tracking." Read-only query over knowledge graph, surfaces contradictions and open questions. Server: 1 week. Client: 1 week. This is the Tier 2 "diegetic threads" from my Round 1 question. Jeroen's answer confirmed it.
4. Journal/knowledge log — Structured record of what the character has learned. Server: 1 week. Client: 1 week. Overlaps with thread tracker; share the knowledge graph query layer.
5. Bookmark definition + starting state — One career bookmark fully defined (suggest smuggler — most content exists). Server: 1 week.

Phase 3: Give the player purpose (1-2 sprints)

6. Mission system core — Mission state, objective tracking, consequence engine. Server: 3-4 weeks.
7. Onboarding sequence — Scripted first-30-minutes for one bookmark. Server framework: 2 weeks. Content: ongoing.
8. Comms system — In-world message delivery (boss calls, contact pings). Server: 1 week. Client: 1 week.

Phase 4: Expand (ongoing)

9. Additional bookmarks (each ~1-2 weeks for definition + tool loadout + starting content)
10. Additional diegetic tools per career
11. AR overlays, mystery board, market feed (career-specific tools)

Total to a playable life-sim vertical slice with one bookmark: ~4-6 sprints from current state. Not a rebuild — an expansion. The simulation core, ECS world, perception system, knowledge graph, IPC pipeline all stay. We're adding information rendering and player purpose systems on top of a solid foundation.

---

Feasibility Assessment

Component	Difficulty	Effort	Risk
NPC legibility in snapshot	Easy	1-2 weeks	Low — data exists, just needs packing
Thread tracker / journal	Moderate	2-3 weeks	Low — read-only over existing KG
Bookmark definitions	Moderate	1-2 weeks	Low — configuration, not new systems
Mission system	Hard	3-4 weeks	Medium — new stateful system, needs careful design
Consequence engine	Hard	2-3 weeks	Medium — feeds into many existing systems
Onboarding sequences	Moderate	2 weeks framework	Medium — content-dependent, hard to test without content
Diegetic comms	Moderate	2 weeks	Low — event-driven, fits existing patterns
Career-specific tools	Varies	1-2 weeks each	Low per tool — but many tools needed

Overall verdict: Feasible. Challenging but doable. The critical insight is that the simulation engine is already a life-sim engine — it tracks people, knowledge, relationships, routines, and state across thousands of entities. What's missing is the layer between that simulation and the player's eyes. That layer is substantial work (~4-6 sprints) but it's additive, not reconstructive. We're not rebuilding the engine. We're building the dashboard.

The riskiest item is the mission system — it's the most complex new stateful system and it touches many existing components. I'd want a design spec workshop for that before implementation. Everything else is moderate or straightforward.

---

One Sentence

The engine is a life-sim engine that was accidentally shipped with a detective-game UI; the fix is building the information layer the simulation was always meant to feed.