Files
settled-reach/docs/sprints/sprint-3/client.md
T
jpmschweitzerandClaude Opus 4.6 bccdcfcdcb docs(docs): add frontmatter to all sprint briefings
Standardized YAML frontmatter on all 115 sprint briefing files across
sprints 1-26 with title, description, type, status, sprint number, and
team fields.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
2026-03-14 00:15:45 +01:00

3.1 KiB

title, description, type, status, sprint, team
title description type status sprint team
Sprint 3 — Client Briefing Interaction prompt system, client-side interaction infrastructure sprint archived 3 client

Sprint 3: Content Foundation — Client Tasks

Goal: Build client-side interaction infrastructure to support v0.1 gameplay.

Branch: client Agents: Stig (UI), Tyre (architecture), Hoshe (QA)

Tickets

# Title Priority Blocked by
#405 Interaction prompt — client extensible prompt system high #404

Use db/connectors/ticket show <id> for full details.

Key Decisions

  • decisions/architecture.md — D-020 (IPC protocol), D-030 (testability)
  • decisions/perception.md — D-016 (internal monologue), D-017 (perception modes)
  • decisions/content.md — D-028 (dialogue architecture), D-035 (tag taxonomy)

Notes

#405 (Interaction prompt system):

Client-side interaction prompt designed for extensibility from day one. v0.1 implementation: single context-sensitive "E" prompt (pick first available verb). Architecture supports v0.2 multi-verb radial menu (show all available verbs from server).

Context: This is a new system — currently the player can move but cannot interact with NPCs, objects, or environment. This ticket adds the UI layer that receives InteractionOptions data from the server (via ObserverSnapshot v3, ticket #404) and displays the appropriate prompt.

v0.1 behavior:

  • Server sends InteractionOptions { verbs: ["Talk", "Examine"] } for an NPC in proximity
  • Client picks first verb ("Talk") and displays "E - Talk to [NPC Name]"
  • Player presses E → client sends interaction request to server

v0.2 behavior (architecture must support this):

  • Client displays radial menu with all verbs
  • Player selects verb → client sends specific verb + target to server

Separation of concerns: This is NOT ticket #240 (Player interaction system and dispatcher). #240 was the general-purpose dispatcher infrastructure. This ticket (#405) is specifically the UI prompt system that reads InteractionOptions from server state and displays context-sensitive interaction prompts. Different team, different scope, different definition of done.

Files:

  • client/scripts/ui/interaction_prompt.gd (new UI component)
  • client/scripts/protocol/local_bridge.gd (read InteractionOptions from ObserverSnapshot v3)

Blocked by #404: Cannot implement until server sends InteractionOptions data via ObserverSnapshot v3 protocol extension.

Integration: Reads from existing IPC bridge. Display layer only — no game logic. All interaction logic stays on server side (ticket #404).

Dependency Chain

#404 (server: proximity + InteractionOptions) → #405 (client: interaction prompt)

Single ticket this sprint. Start as soon as #404 (server) is complete.

PR Workflow

When ready to submit, create a PR with tea CLI. All flags are required to avoid TTY prompts (see CLAUDE.md "Gitea access" section):

tea pr create --repo jpmschweitzer/settled-reach --login schweitz --title "feat(client): description" --description "body" --base main --head client