settled-reach/docs/workshops/wheres-the-fun/round4-gestalt.md

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

title	description	type	status	workshop	agent	round	created
Round 4: GESTALT — Cross-Review and Questions	Gestalt's cross-review questions on systems design interactions	workshop	archived	wheres-the-fun	gestalt	4	2026-03-05

Round 4: GESTALT — Cross-Review and Questions

Workshop: Where's the Fun? | 2026-03-05

Agent: GESTALT (Systems Design) Based on: All Round 3 proposals, Round 3 notes, interview supplement

---

Reactions to Other Agents' Proposals

What I'm strongly endorsing

Tyre: "The engine is a life-sim engine accidentally shipped with a detective-game UI." This is the cleanest formulation of the entire workshop's finding. I'm adopting it as the authoritative framing. The corollary: the fix is additive, not reconstructive. The delivery roadmap (NPC legibility → player tools → player purpose) is the right sequence, and my VerbPriorityProfile refactor belongs in Phase 2 as Tyre listed it.

Gore's reframe of complicity: "Complicity is what you discover you've been building all along." This is significantly stronger than anything in the original design docs. The shift from "pre-authored entanglement" to "choices you didn't know were choices" resolves the cold-start problem at the thematic level — if Phase Zero is just living your life, the entanglement arrives through the world, not through character selection. The verb that makes this land: "decide," not "observe." I agree completely.

Paula's Phase Zero: You can't erode what hasn't been built. This is a prerequisite for the moral arc and also a prerequisite for the storyteller injection model from the supplement (Jeroen's two-phase world: uncaring world first, authored pressure second). Phase Zero IS the Phase 1 world — the player builds a life in an uncaring simulation before the authored content arrives. These are the same concept from different domains. This alignment needs to be explicit.

Araminta: "Fix the screen first." This is the correct gate. NPC legibility is prerequisite for my verb work to matter — if the entities aren't readable as people, the VerbPriorityProfile produces nothing. Araminta's priority order should be treated as blocking for mine: character legibility and place legibility must exist before career-specific verb designs can be evaluated in play.

Mellanie: Hold new monologue content until NPC legibility is solved. Same reasoning. Monologue about a character the player can't identify registers as noise. The content pipeline should be staged behind the visual fix.

Ozzie's redesigned wow moments: The shift from timed beats to emergent thresholds is right. "The Consequence" and "The Ownership Moment" are life-sim-native in a way the original detective-specific moments weren't. Specifically: "The Consequence" (persistent consequence state, journal entry referencing earlier decision) depends on the consequence engine Tyre describes — that's a natural coupling between Ozzie's player experience goals and Tyre's mission system.

Where I see a gap nobody addressed

The skills-verb coupling is completely undesigned. The supplement establishes that character skills (shooting, social manipulation, hacking, mechanical repair) are MORE fundamental than career choice. The toolbox comes from the job; the character comes from creation. But nobody has designed how skills interact with the verb system.

Three possible models:

Model	What it means	Implication
Skills affect priority	High social manipulation → Talk rises toward [E] across ALL jobs	Character creation adjusts VerbPriorityProfile on top of job-derived defaults
Skills affect availability	High hacking → Hack verb unlocks on terminals; no skill = verb doesn't appear	Skills gate verb access, not just outcomes
Skills affect outcome	Verbs identical regardless of skill; skill determines success rate at resolution	Skills invisible at interaction layer; only matter when the action resolves

These produce completely different gameplay experiences and completely different content authoring specs. The second model (availability) means a single terminal object has different verb sets for different characters — the server's verb computation becomes skill-aware. The first model (priority) means my VerbPriorityProfile is additive with skill modifiers. The third model (outcome) means the verb spec stays simple but the resolution system needs the skill layer.

This needs a decision before any of the dependent work (verb spec, content authoring, monologue triggers, character creation UI) can be finalized.

The three career models (Active/WFH/Gig) have different verb interaction densities that the storyteller doesn't currently account for. The supplement establishes three coexisting models:

• Active: at the workplace, the work IS the gameplay (cooking, law enforcement patrol)
• WFH/Remote: portable work anywhere, income ticks while exploring
• Gig/Freelance: pick from board, execute in bursts

These aren't just different VerbPriorityProfiles — they're different rhythms of play. A bar cook on Active has continuous high-density verb interaction (Talk, Examine, Move between stations). A remote hacker may go extended stretches with minimal verb interaction while income ticks. A smuggler on Gig operates in mission bursts with downtime between.

The storyteller's pressure calibration needs to understand which rhythm the player is in. A pressure injection during a Gig player's downtime between jobs lands differently than the same injection during an Active shift. Nobody has designed this coupling.

One tension I want to flag

Tyre and Ozzie disagree on which career bookmark to build first for v0.2:

• Tyre: smuggler (most content already exists)
• Ozzie: law enforcement (most legible for first-run players)

I don't have a strong preference between them, but I note that the supplement resolves the FORMAT (Groundhog Day opening, onboarding arc, Gig vs Active structure) without resolving WHICH career. This is listed as a blocker for multiple agents (Q-WTF-008). It needs to be resolved before Round 4 closes, or it becomes the first Sprint 25 design question.

---

Questions for Jeroen

Q1: Do character skills affect verb PRIORITY, AVAILABILITY, or OUTCOME — or all three in different situations?

The tension: The supplement says skills (social manipulation, hacking, mechanical repair, shooting) are fundamental to character creation and precede career choice. But the verb system currently has only one dimension: job-aware priority. Skills could interact with verbs in three distinct ways — shifting priority (socially skilled characters default to Talk more readily across all jobs), gating availability (you need hacking skill for the Hack verb to appear on a terminal), or affecting outcomes at resolution (the verb is the same but success rates vary). These produce completely different designs for the interaction layer, character creation, and content authoring.

Why it matters now: Before I can finalize the VerbPriorityProfile spec, before Mellanie can write triggers tied to verb outcomes, before Araminta can design the visual grammar for skill-related UI indicators — this needs a decision. If skills gate availability, the server's verb computation becomes skill-aware and the content spec needs to account for "this verb doesn't exist for this character." If skills affect outcomes, the resolution layer needs the skill layer and the verb spec stays clean.

The concrete question: When a character with high social manipulation and a tycoon career approaches an NPC, does anything about the verb interaction look or function differently from a low-social-manipulation tycoon? And is the answer the same for hacking vs. a terminal, or shooting vs. a conflict encounter?

---

Q2: In the two-phase world (uncaring world first, authored content second) — is Phase 1 a per-session player experience or only a dev-sequencing principle?

The tension: The supplement describes Phase 1 as "the generator runs, NPCs go about their days, the simulation doesn't know or care that a player exists." This clearly describes a development sequencing (build the simulation before adding authored content sprints). But the Groundhog Day opening (alarm clock, routine day, no authored crisis yet) sounds like Phase 1 IS also what the player experiences at the start of every session — you're living your life in the uncaring world before anything authored targets you.

Why it matters for the storyteller design: If Phase 1 is only a dev concept, the storyteller simply operates on whatever authored content exists at a given sprint. But if Phase 1 is also a per-session player experience — "this is what normal days feel like before the world starts targeting you specifically" — then the storyteller needs a "quiet mode" at session start, and the transition from quiet to injected pressure becomes a designed moment in every session, not just a dev milestone.

Paula's Phase Zero (build warmth before the crack arrives) and the Groundhog Day opening are both pointing at the same design. The question is whether this is built into the session structure permanently (every session starts quiet) or whether it's a one-time first-run design and after that the player is always in a world that has ongoing authored pressure.

The concrete question: After the player has established their career and relationship with their FRIEND — on day 50 of their playthrough — does the Groundhog Day structure still mean "quiet phase then potential escalation," or has the world permanently graduated to Phase 2?

---

Q3: For the career model rhythm (Active/WFH/Gig) — does the storyteller calibrate pressure per career model, or does it abstract above them?

The tension: Three career models coexist. A bar cook on Active career is in continuous high-density verb interaction during their shift. A hacker on WFH/Remote may have long stretches with minimal verb interaction while income ticks. A smuggler on Gig/Freelance operates in mission bursts with downtime between. These are structurally different rhythms.

The Rimworld storyteller (confirmed as a reference) calibrates pressure based on perceived player state — it escalates when things are quiet, backs off when things are already stressful. But "quiet" means something completely different for an Active career vs. a Gig career between jobs. A Gig player sitting at home waiting for the next board posting is "quiet" — but they're also exactly where they should be. The storyteller shouldn't interpret Gig downtime as "player needs stimulation."

Why it matters for the storyteller design and verb architecture: If the storyteller is career-model-aware, it needs a concept of "normal quiet for this career model." The verb system can help here — the server already knows what verbs are available and how often the player is interacting. But the threshold for "this player needs something to happen" is radically different for a bar cook mid-shift vs. a remote hacker vs. a smuggler between runs.

The concrete question: Should the storyteller track "time since last meaningful player decision" uniformly, or should it understand what career model the player is operating in and adjust its pressure clock accordingly?

---

My Single Most Important Recommendation

Design the skills-verb coupling before any other content work resumes.

This is the load-bearing decision that sits upstream of: the verb spec, VerbPriorityProfile, character creation UI, content authoring triggers, visual grammar for skill indicators, and onboarding arc design. Every other Round 3 proposal assumes skills and verbs interact in some way — but nobody has specified how. If the answer is "skills gate availability" (most interesting, most powerful), the verb computation becomes skill-aware and everything downstream changes. If the answer is "skills affect outcomes only" (simplest), the verb spec stays clean and the skill system is mostly a resolution layer.

This decision costs a day to make and weeks to untangle if made wrong mid-implementation.

---

GESTALT — Round 4 complete. The architecture is ready. The three unresolved questions (skills-verb coupling, Phase 1 as player experience, storyteller per career-model calibration) are all upstream of my implementation work. Get decisions on these before Sprint 25 begins.