settled-reach/docs/workshops/v01-content-scoping/round1-stig.md

Round 1 Response: Stig (UI Developer)

v0.1 Content Scoping Workshop

---

Topic 3: What Does the Client Need from Content Files?

The client is a renderer. It doesn't decide what happens — the server does. So the client's content needs are narrow: display strings, visual parameters, and layout hints. Everything else stays server-side.

What the client loads directly

Data	Format	Why
NPC display names	display_name: "Kael Davan"	Name label above entity rectangle. Must be the name the player character knows — "Dock Worker" before identification, "Kael Davan" after. Server sends the current display name per entity via state update, not the content file.
Location display names	display_name: "The Terminal"	HUD location indicator, minimap labels. Short names only — "The Terminal", not "Sova Transit Logistics Hub, Bay 7-C".
Monologue text	text: "Morning shift. Recycled air..."	Rendered by the monologue display system. The server selects the line; the client receives the id + text. Client doesn't evaluate prerequisites.
Dialogue text	text: "Container 4471 sat in temp..."	Rendered in the dialogue panel. Server selects, client displays.
Entity color palette	relationship_colors map in a client config	D-033 palette. Client derives color from RelationshipState sent by server. Not per-NPC content.
Time of day	Phase enum: morning, afternoon, evening, night	HUD clock display. Server sends current phase. Client renders as text and ambient lighting tint.

What the client does NOT need

• NPC profiles, axes, secrets, triangle definitions — server-only
• FactId catalog, prerequisite maps — server-only evaluation
• Access tiers, trust levels — server filters before sending to client
• NPC routines/schedules — server simulates, client receives position updates
• Knowledge graph state — server tracks, sends display-relevant slices

Format recommendation

Client content should be a thin layer. I don't need to parse the full wiki YAML. What I need is:

# content/client/strings.yaml
locations:
  terminal:
    display_name: "The Terminal"
    short_name: "Terminal"
    minimap_label: "T"
  bar:
    display_name: "The Last Shift"
    short_name: "Last Shift"
    minimap_label: "LS"
  corridor:
    display_name: "Corridor B-7"
    short_name: "B-7"
    minimap_label: "B7"

hud:
  time_phases:
    morning: "Morning Shift"
    afternoon: "Afternoon"
    evening: "Evening"
    night: "Night Cycle"

Monologue and dialogue text can arrive as part of the server state update — {type: "monologue", id: "terminal_m_001", text: "Morning shift..."}. The client doesn't need the full YAML pools on disk. Server selects, client renders. This keeps the client thin and prevents any information leakage (the client literally cannot show what it doesn't have).

Bottom line: The client needs display strings + the server's state stream. It should never have access to content it shouldn't be rendering. Every pixel of information passes through the server's information boundary first.

---

Topic 4: UI Elements for the Minimum Interaction Model

I'll walk through each element: what it looks like, where it sits, how the player reaches it.

4.1 The Screen Layout (Overview)

+------------------------------------------------------------------+
|                                                                    |
|                                                                    |
|                                                                    |
|                        GAME WORLD                                  |
|                     (full viewport)                                |
|                                                                    |
|                                                                    |
|                                                                    |
|  [MONOLOGUE]                                                       |
|  bottom-left, 1-2 lines                                            |
|                                                                    |
|                               [INTERACTION PROMPT]                 |
|                               near-player, contextual              |
|                                                                    |
+------------------------------------------------------------------+
|  LOCATION    |    TIME     |                    | [MINIMAP]        |
|  The Terminal|  Morning    |                    |   (insert)       |
|              |             |                    |                  |
+------------------------------------------------------------------+

The game world fills the viewport. UI elements float over it, positioned to stay out of the player's sightline toward the center of the screen where the action is.

Core principle: the center is sacred. Nothing permanent lives in the center third of the screen. That's where the character is, where NPCs are, where the player looks. UI lives at the edges and appears only when relevant.

4.2 Interaction Prompt

What it is: A single-action context label that appears when the player is close enough to interact with something.

Position: Offset from the target entity, above and slightly right. Tracks the entity position in world space (not screen-fixed). Small — 12-14px equivalent at reference resolution.

Appearance:

         [Talk]          <- NPC within interaction range
     Kael Davan          <- entity name (if known)
       [====]            <- entity rectangle

Or for objects:

      [Examine]
    Manifest Terminal
       [====]

Behavior:

• Appears when player enters interaction radius (~1.5 tiles) AND has line of sight
• Disappears when player moves away or breaks LOS
• Changes based on context: The same NPC shows "Talk" normally, "Ask about..." after contradiction discovery, or nothing if no interaction is available
• Single action. No menus. No radial wheels. The server decides what the primary interaction is based on entity state + player knowledge. The prompt shows ONE thing. Press [E] or [Space] to do it.
• If multiple interactions are available, the prompt shows the most relevant one. The player gets a decision about whether to interact, not a menu of options.

Why single-action: Too many clicks. A radial menu means the player stops, reads, selects, then engages. A single prompt means: approach, press, you're in. The game should feel like walking into a conversation, not operating a database.

Edge case — multiple valid actions: If the player needs to choose between "Talk" and "Examine" on the same entity, the prompt changes based on proximity angle or a simple toggle (tap [E] = primary, hold [E] = secondary). But for v0.1, I'd argue: default to "Talk" for NPCs, "Examine" for objects, and handle the edge cases when they arise.

4.3 Dialogue Display

What it is: How conversation text appears once the player initiates dialogue.

Position: Bottom-center of the screen, overlaying the game world. The world stays visible behind it — the player can still see NPCs moving, can still read the room.

Layout:

+------------------------------------------------------------------+
|                                                                    |
|                        GAME WORLD                                  |
|                     (still visible, slightly dimmed)                |
|                                                                    |
|                                                                    |
+------------------------------------------------------------------+
|                                                                    |
|  KAEL DAVAN                                                        |
|  "Container 4471 sat in temp storage overnight.                    |
|   Scheduling backed up again."                                     |
|                                                                    |
|  > [Continue]                          [End conversation]          |
|                                                                    |
+------------------------------------------------------------------+

Specifications:

• Width: ~60% of screen width, centered horizontally
• Height: Variable, 3-5 lines maximum. If the line is longer, it scrolls on input
• Background: Semi-transparent dark panel (80% opacity). Not opaque — the world behind bleeds through. The conversation is happening IN the world, not in a separate screen
• Speaker name: Top-left of the panel, in the entity's relationship color (D-033). Teal if unknown, green if friendly, amber if person of interest
• Text: Off-white, clean sans-serif, left-aligned. One NPC line at a time
• Advance: [Space] or [E] advances to next line. No auto-advance — the player controls the pace
• Exit: [Escape] or [Q] ends conversation at any point. The NPC reacts (server determines reaction based on conversation progress)

What this is NOT:

• No branching dialogue trees visible on screen. The server determines what the NPC says next based on access tier, trust, and state. The player experiences a conversation, not a menu
• No portraits. Top-down game — we see the entities. A portrait would be a second representation that contradicts the top-down perspective
• No response selection in v0.1. The conversation flows. The player's choices are: continue, leave, or (post-discovery) confront. Confrontation is a separate interaction prompt, not a dialogue option

4.4 Monologue Display

What it is: The player character's internal voice. Text that represents what the character thinks, notices, feels.

Position: Bottom-left of the viewport, above the HUD bar. Offset from the dialogue panel position so they never overlap.

Layout:

+------------------------------------------------------------------+
|                                                                    |
|                        GAME WORLD                                  |
|                                                                    |
|                                                                    |
|                                                                    |
|                                                                    |
|  +-----------------------------------------+                       |
|  | Kael's here. Good -- I was starting     |                       |
|  | to worry.                               |                       |
|  +-----------------------------------------+                       |
|                                                                    |
+------------------------------------------------------------------+

Specifications:

• Width: ~40% of screen width, anchored left
• Height: 1-2 lines. Monologue is brief (authoring guide says "one breath")
• Background: Minimal. A subtle text shadow or very faint panel (20-30% opacity). The monologue should feel like it's floating in the character's head, not displayed in a UI box
• Text color: Character-specific tint. Detective: cool blue-white #c8d8f0. Smuggler: warm amber-white #f0e0c8. Subtle — not a spotlight, just a whisper of character identity
• Animation: Fades in over 0.3s, holds for 4-6 seconds (adjusted by text length), fades out over 0.5s. Does not stack — a new monologue replaces the current one. If the old one hasn't finished, it fades faster (0.15s) before the new one appears
• Audio cue: Soft chime on appearance (D-038: sfx_monologue_chime.ogg). Sharper variant for anomaly observations (sfx_monologue_chime_urgent.ogg)
• During dialogue: Monologue can appear DURING a conversation (post_conversation trigger fires after exchange, but observe_anomaly can fire mid-conversation if the player spots something while talking). When dialogue panel is active, monologue shifts up slightly to sit above the dialogue panel, maintaining the same left-anchored position

Critical rule: monologue must not compete with dialogue. They occupy different screen regions (left vs. center), use different visual treatments (floating vs. paneled), and serve different functions (character's inner voice vs. NPC's spoken words). If both are on screen simultaneously, the player reads dialogue first (center, larger, solid panel) and catches monologue peripherally (left, smaller, ghostly). This mirrors how internal reactions work — you hear the other person speaking while your own thought forms underneath.

4.5 Knowledge Panel (Neural Lattice Interface)

What it is: The player's diegetic notebook. A neural lattice overlay that shows what the character knows — people, facts, relationships.

Diegetic framing: This isn't a game journal. It's the character checking their implant's records. The detective's Analytical lattice organizes information automatically. The smuggler's Baseline lattice shows simpler records — people they know, places they've been.

Access: Press [Tab] to toggle. Pauses the game (or slows to near-pause — design decision for Gestalt). The lattice overlay slides in from the right side of the screen.

Layout:

+------------------------------------------------------------------+
|                                                                    |
|                 GAME WORLD              | LATTICE OVERLAY          |
|                 (visible,               |                          |
|                  dimmed)                | PEOPLE          [tab]    |
|                                         |   Kael Davan    [green]  |
|                                         |   Sera Venn     [green]  |
|                                         |   Voss          [teal]   |
|                                         |   "Dock Worker"  [teal]  |
|                                         |                          |
|                                         | PLACES                   |
|                                         |   The Terminal            |
|                                         |   The Last Shift          |
|                                         |                          |
|                                         | OBSERVATIONS             |
|                                         |   "Manifest discrepancy  |
|                                         |    — Container 4471"     |
|                                         |                          |
+------------------------------------------------------------------+

Specifications:

• Width: ~30% of screen width, anchored right
• Sections: People / Places / Observations. Simple tabs or vertical scroll
• People entries: Display name + relationship color dot. Click/select for detail: known attributes, last seen location, relationship state
• Places: Location names discovered so far. Click for minimap highlight
• Observations: Key facts in plain language. These are the FactIds rendered as human-readable sentences. "Manifest discrepancy observed at Terminal" not "investigation.manifest_discrepancy: Suspects"
• Visual treatment: Dark panel with a subtle scan-line effect or faint grid overlay — this is a lattice interface, not a paper notebook. The diegetic feel comes from the typography and visual treatment, not from elaborate 3D renders
• Character-specific: The detective's lattice shows more analytical structure (observations auto-categorized, flagged items highlighted in amber). The smuggler's lattice is simpler — people and places, fewer analytical overlays
• Empty state: At game start, the lattice is sparse. Detective has a few case-file entries. Smuggler knows people but has no "observations" section initially. The lattice fills as the player discovers things

4.6 HUD Elements

What's always visible:

+------------------------------------------------------------------+
|                                                                    |
|                        GAME WORLD                                  |
|                                                                    |
+------------------------------------------------------------------+
| The Terminal  |  Morning Shift  |                   +----------+  |
|               |                 |                   | MINIMAP  |  |
|               |                 |                   |   (D-013)|  |
+------------------------------------------------------------------+

Location name: Bottom-left corner of the HUD bar. Shows current area. Updates on zone transition with a brief fade.

Time of day: Next to location. Shows the current phase in plain language ("Morning Shift", "Evening", "Night Cycle"). Updates on phase transition. No clock numbers — the character doesn't check the time, they feel the shift rhythm.

Minimap (insert): Bottom-right corner. Small — 120x120px at reference resolution. Shows:

• Player position (character-color dot, D-033)
• Known NPC positions within close range (relationship-colored dots)
• Location boundaries (thin lines, muted)
• POI markers for discovered locations (small icons)
• Fog — areas not yet discovered are dark

The minimap IS the neural lattice navigation overlay (D-013). It should look like a technology interface, not a game map. Subtle grid lines, faint glow at the edges, no terrain texturing. Information appears on it only as the character learns it.

What's NOT always visible:

• Character name — the player knows who they are. Don't waste pixels reminding them
• Health/status bars — no health system in v0.1
• Inventory indicators — no inventory in v0.1 (knowledge-based, per Gestalt's direction)
• Quest markers — this is not that kind of game
• Mini-objectives — the player decides what to do

4.7 News Ticker

The Meridian news feed in The Last Shift. This is a diegetic element — it exists in the world, on the bar's display screen.

Implementation: A world-space text object attached to the bar's display entity. Scrolling text, left-to-right, station news headlines. The player reads it by standing near the display, not through a HUD overlay.

Why world-space: D-039 Wow Moment #5 requires the same ticker to produce different monologue reactions per character. If the ticker were a HUD element, it would feel like a notification system. In world space, it's a thing in the bar that you walk over to and read. The monologue fires because your character is looking at it, not because the UI decided to inform you.

---

Topic 5: Minimum UI for a 30-Minute Vertical Slice

Must be polished (player-facing, first impression)

Element	Why polished	Effort level
Monologue display	This IS the game's voice. If monologue feels janky, the character feels dead. Smooth fade, correct timing, readable text, audio chime sync.	Medium — text rendering + animation + audio trigger
Interaction prompt	First thing the player tries. Walk to NPC, see "Talk", press key, it works. If this is clunky, the game feels broken.	Low — context label + input handler
Dialogue panel	Second thing the player tries. Text must be readable, pacing must feel natural, exit must work cleanly.	Medium — text display + input flow + state management
Entity relationship colors	D-033. The color palette tells the player who matters before any text appears. Green = safe, amber = something changed. THE FRIEND's color shift (green to amber) is Wow Moment #3.	Low — shader/tint parameter driven by server state
Fog of perception	D-011. If the player can see everything, there's no game. LOS shadowcasting must work.	High — but this is Dudley/Tyre territory, not UI

Can be placeholder (functional, not pretty)

Element	Why placeholder is OK	Placeholder spec
Minimap	Players will use it but don't expect polish in a vertical slice. A dot on a dark rectangle is sufficient.	Player dot + area boundary lines. No labels, no icons.
HUD bar	Location name + time phase in plain text, no styling.	Left-aligned text, default font, dark background strip.
Knowledge panel	Players may not even find it in 30 minutes. But it must exist for the detective's analytical loop.	Plain text list on a dark overlay. No scan-line effects, no diegetic styling. Functional data display.
News ticker	D-039 Wow Moment #5 needs it, but the ticker itself can be simple scrolling text. The wow is in the monologue reaction, not the ticker's visual polish.	Scrolling text on a world-space panel. Monospace font. Functional.

Can be deferred entirely (v0.2+)

Element	Why defer
Perception mode overlays	D-017: only natural vision in v0.1. No thermal, no camera feeds, no tracking.
Inventory UI	No inventory system in v0.1. Knowledge-based interaction.
Character selection screen	v0.1 can start with a character toggle or separate launch configs. No menu needed.
Settings/options menu	Dev builds. Hardcode resolution, keybindings.
Tutorial/onboarding	Monologue IS the tutorial (D-016: "That terminal might have access logs"). No separate tutorial UI.
Map zoom/pan	Camera locked (D-015). No map interaction beyond the minimap.

The 30-minute visual journey

Here's what the player actually sees, minute by minute:

Minute 0-1 (Arrival): Black screen fades in. Station ambient plays. The game world appears, character in the center, fog surrounding them. First monologue fades in at bottom-left: "Morning shift. Recycled air and cargo lubricant." Chime sounds. HUD bar shows "The Terminal | Morning Shift". Minimap shows a small illuminated area around the player.

Minute 1-5 (Exploration): Player moves with WASD. Fog recedes as they explore. NPC rectangles appear in the viewport — colored dots. Walking near an NPC shows their display name and [Talk] prompt. First dialogue: the panel slides up from the bottom, semi-transparent, NPC name in relationship color. Text advances on input. Conversation ends, panel slides down. Monologue fires: "Kael's here. Good."

Minute 5-15 (The Character's Eye): Monologue fires unprompted with the urgent chime — the character noticed something the player didn't. The text is different: sharper, the urgent variant. "Dock worker Davan -- lattice activity spiked." The player hasn't done anything — the game is teaching them that their character has a mind.

Minute 15-20 (Building routine): Player moves between Terminal and Bar. Location name transitions on the HUD. The bar is warmer (amber lighting tint). Minimap updates with new area. Monologue at bar entry: different tone, different character voice. Dialogue with Sera Venn — the panel text feels different from Kael's. Same UI, different voice.

Minute 20-25 (THE FRIEND's contradiction): Kael's entity color shifts — green to amber. 0.5s fade per D-033. This is silent, visual. No fanfare. The urgent monologue chime fires. "Kael? By the service hatch? And that's -- I don't know them." If the player presses [Tab], the knowledge panel now shows Kael as "Person of Interest" with an observation entry.

Minute 25-30 (The quiet moment): Player standing still in a corridor. After idle time, monologue fades in without chime. Reflective. Quiet. "No Meridian signal down here. No eyes, no ears." The game breathes. The UI is invisible. The world is present.

Summary: v0.1 UI bill of materials

System	Files/Scenes	Priority
Monologue renderer	1 scene + 1 script	P0 (must ship)
Interaction prompt	1 scene + 1 script	P0
Dialogue panel	1 scene + 1 script	P0
Entity color system	Shader + config	P0
HUD bar (location + time)	1 scene + 1 script	P1 (placeholder OK)
Minimap	1 scene + 1 script	P1
Knowledge panel	1 scene + 1 script	P1
News ticker (world-space)	1 scene + 1 script	P1
Fog rendering	Shader + integration	P0 (shared with server team)

Total: ~9 scenes, ~9 scripts, 2 shaders. This is a tight UI. Every element earns its pixel.

---

Open Questions for Other Participants

For Dudley (server):

• What does the state update message look like? I need: entity positions, display names, relationship states, monologue triggers (id + text), dialogue lines (id + text + speaker), time phase, location zone ID. What's the IPC message format?
• Does the server send the full text of monologue/dialogue lines, or just IDs that the client looks up locally? I prefer full text in the message (keeps client thin, prevents info leakage), but there's a bandwidth trade.

For Gestalt (systems):

• Does opening the knowledge panel pause the game? Semi-pause? If NPCs keep moving while you read, you miss things. If the game pauses, it breaks immersion. I lean toward semi-pause (simulation runs at 10% speed).
• Single-action interaction prompt: does this work for the systems design? Or does the player need to choose between "Talk" and "Observe" on the same NPC?

For Mellanie (copy):

• Maximum monologue line length? I'm designing for 1-2 lines of display text (~80 characters per line, ~160 max). Is that enough for the voice?
• How many monologue lines can fire in sequence before it feels like a wall of text? I'd say 1 at a time with 2-3 second gaps minimum.

For Araminta (visual):

• Diegetic styling for the knowledge panel — how far do we push the "lattice interface" look in v0.1? My instinct: minimal. Faint grid, slightly blue-shifted palette, clean type. Save the fancy scan-line effects for when we have art budget.
• Monologue text color per character — I proposed detective blue-white and smuggler amber-white. Does this conflict with the entity color palette (D-033)?

---

The player's eye goes to the center. Everything else stays out of the way until it's needed. Then it appears, does its job, and vanishes.