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

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

title	description	type	status	workshop	agent	round	created
Round 1: Tyre — Diagnosis Questions	Tyre's technical architecture diagnosis on engine constraints and feasibility	workshop	archived	wheres-the-fun	tyre	1	2026-03-05

Round 1: Tyre — Diagnosis Questions

Role: Technical Architect Sources reviewed: Workshop brief, decisions/architecture.md (D-010, D-020, D-026, D-041), docs/design/interaction-verbs-v0.1.md

---

Technical Context (for the other agents)

cracks knuckles — Before the questions, a quick reality-check on what the architecture can and can't absorb. This matters for scoping proposals in Round 3.

What's cheap to change (server-only, days not weeks):

• Monologue priority, timing, cooldown, queue depth — all tuning parameters in the server's monologue system. Rebalancing the signal-to-noise ratio (playtest item #10) is a config change, not an architecture change.
• Adding new fields to ObserverSnapshot — the MessagePack protocol is variable-shape by design (D-020). The client renders what it receives. Adding, say, a "current objective hint" or "knowledge progress summary" to the snapshot is a server-side addition + a client-side UI widget. No protocol rewrite.
• Verb priority shifts — the verbs[] array is already computed server-side every tick with full context (distance, relationship state, knowledge level). Changing what [E] does in different situations is priority reordering, not new systems.
• Knowledge graph queries — the graph already tracks what the player knows, what's contradicted, what's stale. Any "progress" system can be built as a read-only query over existing data. The data is there; we just don't surface it.

What's moderate (new systems, but within existing architecture):

• An objective/hint system that reads the knowledge graph and emits guidance through the existing ObserverSnapshot pipeline. This is a new server-side system, but it plugs into existing infrastructure. Think: a system that runs once per game-minute, checks knowledge state, and pushes a "current thread" indicator to the client. Maybe a week of work.
• Spatial anchoring for monologue (playtest item #9) — tying monologue triggers to specific tile positions so the client can render an indicator at the source location. Requires adding a source_position field to the monologue payload. Server change + client rendering change.

What's expensive (architecture-level, would delay v0.1):

• Branching dialogue trees replacing the tagged line pool system (D-028). The entire content pipeline assumes pool-based selection. This would be a rebuild.
• Real-time NPC conversation AI (dynamic dialogue generation). Not in the architecture at all.
• Fundamentally changing the client-server boundary (moving logic to the client). This contradicts D-010/D-020/D-048 and would be a project reset.

---

Question 1: The Knowledge Graph Already Knows — Why Doesn't the Player?

The knowledge graph (D-041) tracks everything the player character has learned: entity knowledge, fact knowledge, confidence levels, contradictions, staleness. The server computes this every tick. But none of it is surfaced to the player as structured progress.

The monologue system was supposed to bridge this gap (D-016), but it fires as prose fragments — atmosphere, not information architecture. The player gets "He checked his lattice again. Third time." but never gets the structured signal: "You've noticed 2 of 3 tells on this NPC. Something is off here."

The question: When you designed monologue as the primary feedback mechanism, were you envisioning it as the only channel between the knowledge graph and the player? Or was there always an implicit assumption that some structured feedback layer (a journal, a "threads" panel, a knowledge summary) would eventually sit alongside it?

Why this matters technically: If the answer is "monologue was supposed to be sufficient," then the fix is content and tuning — write better monologue lines, tighten the priority system, add spatial anchoring. If the answer is "there was always supposed to be more," then we need to design that structured layer now, and the good news is the architecture supports it cheaply — the data already exists in the knowledge graph, we just need a new rendering path through ObserverSnapshot to a client-side UI element.

---

Question 2: What Does "No Objectives" Actually Mean at the Architecture Level?

The playtest showed that "no objectives, no markers" produces paralysis, not discovery (item #13). But "objectives" is a spectrum, not a binary. Technically, the architecture can support anything from:

• Tier 0 (current): Nothing. The player infers purpose from monologue and observation.
• Tier 1: Passive knowledge summary — a panel showing what the player character knows, organized by entity/fact, with contradictions highlighted. No direction, just structured memory. "You know these things. Some of them conflict."
• Tier 2: Diegetic threads — the character's neural insert (already established in D-013) surfaces "active threads" based on knowledge graph state. "Kael's schedule doesn't match what Torek said." Not objectives — observations the character is actively puzzling over.
• Tier 3: Explicit objectives — a mission briefing, checkpoints, "investigate X." Traditional game objectives dressed in diegetic clothing.

All four tiers are technically feasible within the existing architecture. Tiers 1-2 are moderate effort (query existing knowledge graph, new UI widget). Tier 3 is also moderate but requires authored objective content.

The question: Where on this spectrum does the game need to land for v0.1? And critically — is the resistance to objectives a design principle (the game is fundamentally about discovering your own purpose) or a scope decision (we didn't build it yet)? Because architecturally, I can support any of these without touching the simulation core.

Why this matters: If it's a design principle, we're solving the fun problem through better monologue, spatial feedback, and environmental storytelling — and the architecture is fine as-is. If it's a scope decision, then the cheapest high-impact change might be a Tier 2 "threads" system — maybe 3-5 days of server work, 2-3 days of client UI — that gives the player structured awareness of what their character is tracking, without ever saying "go here, do this."

---

Question 3: Is the Single Context Key Hiding the Game From the Player?

The v0.1 verb system has 7 verbs, but the player only sees one at a time through [E]. The system auto-selects based on priority. The player presses [E] and gets whatever the server decided was most important. The design intent was simplicity — don't overwhelm with choices.

But the playtest suggests the opposite problem: the player doesn't know what actions exist. They don't know they can Examine NPCs separately from Talking. They don't know Overhear is a thing that happens. They don't know monologue is reactive to their observations. The verb system is invisible.

The v0.2 plan already calls for showing the full verbs[] array (e.g., [E] Talk [F] Observe). This requires zero server changes — the protocol already carries all available verbs. It's purely a client-side rendering change.

The question: Would pulling the v0.2 verb display forward to v0.1 — showing all available verbs instead of just the top one — help solve the "I don't know what to do" problem? Or would it just add more noise to an already overwhelming experience (item #10)?

Why this matters: This is the single lowest-effort change that could materially affect the core loop. It's 1-2 days of client work, zero server work. If the player can see that "Observe" exists as a distinct action from "Talk," they might naturally discover the investigation loop. But it only helps if the player's problem is "I don't know my options" rather than "I don't know why I should care." If it's the latter, showing more verbs just adds clutter.

---

Feasibility summary: the architecture is more flexible than the playtest suggests. The simulation engine doesn't need rebuilding — it needs better channels between what it already knows and what the player can see. The knowledge graph is rich; the rendering of that knowledge to the player is impoverished. Most high-impact changes are in the "moderate" category: new server-side query systems feeding new client-side UI, all within existing protocol boundaries.