jpmschweitzerandClaude Opus 4.6
ed09439a31
NPC data model, pathfinding, observation events, and interaction foundation. Briefings for server, client, joint, and copy teams. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
59 lines
3.2 KiB
Markdown
59 lines
3.2 KiB
Markdown
# Sprint 3: Know — Client Tasks
|
|
|
|
**Goal:** Player character can observe NPCs, track their knowledge, and interact with the environment through a working observation event pipeline.
|
|
|
|
**Branch:** `client`
|
|
**Agents:** Stig (UI), Tyre (architecture), Hoshe (QA)
|
|
|
|
## Tickets
|
|
|
|
| # | Title | Blocked by |
|
|
|---|-------|------------|
|
|
| #345 | Fix entity_renderer.gd field name bug (id vs entity_id) | — |
|
|
| #240 | Player interaction system and dispatcher | — |
|
|
|
|
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
|
|
|
|
**#345 (Critical bug fix):**
|
|
- **Context:** Line 26 of `client/scripts/rendering/entity_renderer.gd` checks `entity_data.has("entity_id")` (correct per Protocol v2), but this was identified as a field name bug in the Architecture Review Audit. Verify the check is correct and that entities render properly. If the bug is real, the fix is trivial (XS effort). If entities already render, mark done and document why the audit flagged it incorrectly.
|
|
- **File:** `/var/home/jeroenschweitzer/Projects/settled-reach/main/client/scripts/rendering/entity_renderer.gd`
|
|
- Start with this — it's blocking basic entity rendering if the bug is real.
|
|
|
|
**#240 (Interaction system):**
|
|
- **Context:** General-purpose interaction dispatcher that routes player Interact input to appropriate subsystems. Currently there is no interaction system — player can move but not interact with anything.
|
|
- **Routing logic:**
|
|
- NPC → dialogue (Sprint 4+, stub for now)
|
|
- Object → examine (Sprint 4+, stub for now)
|
|
- Door → open/close (Sprint 4+, stub for now)
|
|
- Terminal → info access (Sprint 4+, stub for now)
|
|
- **Implementation:** Add `Interactable` component concept on server side. Client sends `Interact` input when player presses interact key near an entity. Server dispatcher checks entity type and routes to appropriate handler. For Sprint 3: infrastructure only, all handlers return placeholder text.
|
|
- **Files:**
|
|
- Server: `server/src/simulation/interaction.rs` (new module)
|
|
- Client: `client/scripts/autoloads/input_mapper.gd` (add interact key binding)
|
|
- **Integration:** Builds on existing input system (`server/src/simulation/input.rs`, `client/scripts/autoloads/input_mapper.gd`). New input type: `PlayerInput::Interact { target_entity: Option<u64> }`.
|
|
- This is foundation work for dialogue (#168, Sprint 4+) and follow/examine mechanics (#241, #242, Sprint 4+).
|
|
|
|
## Dependency Chain
|
|
|
|
```
|
|
#345 (bug fix) → standalone, critical for entity rendering
|
|
#240 (interaction dispatcher) → #168, #241, #242 (Sprint 4+ dialogue/mechanics)
|
|
```
|
|
|
|
Both tickets are independent and can run in parallel if multiple agents are available.
|
|
|
|
## 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):
|
|
```bash
|
|
tea pr create --repo jpmschweitzer/settled-reach --login schweitz --title "feat(client): description" --description "body" --base main --head client
|
|
```
|