62 lines
3.4 KiB
Markdown
62 lines
3.4 KiB
Markdown
# E1.M1 — InputAndMovementRuntime
|
|
|
|
## Summary
|
|
|
|
| Field | Value |
|
|
|--------|--------|
|
|
| **Module ID** | E1.M1 |
|
|
| **Epic** | [Epic 1 — Core Player Runtime](../epics/epic_01_core_player_runtime.md) |
|
|
| **Stage target** | Prototype |
|
|
| **Status** | In Progress (see [dependency register](module_dependency_register.md); [implementation snapshot](#implementation-snapshot)) |
|
|
|
|
## Purpose
|
|
|
|
**Authority:** [Client vs server](client_server_authority.md#e1m1-inputandmovementruntime) — server owns `PositionState`; client sends move intent and may predict; reconcile to server.
|
|
|
|
Provides the foundational client/runtime path for character locomotion and world interaction: click-to-move or path-follow baseline, interaction trigger range checks, and the authoritative reconciliation surface for where the player is in the world. Other epics attach gameplay (gathering, combat, quests) on top of stable position and movement contracts.
|
|
|
|
## Responsibilities
|
|
|
|
- Character locomotion and movement command handling.
|
|
- Interaction trigger range checks using a single source of truth for distance.
|
|
- Emitting or consuming movement-related state suitable for server reconciliation in multiplayer tests.
|
|
|
|
## Key contracts
|
|
|
|
| Contract | Role |
|
|
|----------|------|
|
|
| `MoveCommand` | Client or input layer requests movement; server (or sim) validates and applies. |
|
|
| `PositionState` | Current authoritative (or reconciled) position for the avatar. |
|
|
| `InteractionRequest` | Optional path for interaction attempts; pairs with range checks. |
|
|
|
|
Contract readiness is tracked in the [module dependency register](module_dependency_register.md).
|
|
|
|
## Implementation snapshot
|
|
|
|
- **Done (spike):** Server-side authoritative **read** API for `PositionState` (JSON over HTTP, versioned payload); in-memory store. See [NS-15 implementation plan](../../plans/NS-15-implementation-plan.md), `server/NeonSprawl.Server/Game/PositionState/`, and [server README — Position state](../../../server/README.md#position-state-ns-15).
|
|
- **Not yet:** `MoveCommand` ingestion, client sync, persistence, full movement loop per Epic 1 Slice 1.
|
|
- **Alignment:** [Documentation and implementation alignment](documentation_and_implementation_alignment.md).
|
|
|
|
## Module dependencies
|
|
|
|
- **None** — root of the player runtime stack.
|
|
|
|
## Dependents (by design)
|
|
|
|
- **E1.M2** — [IsometricCameraController](E1_M2_IsometricCameraController.md): stable player anchor / position.
|
|
- **E1.M3** — [InteractionAndTargetingLayer](E1_M3_InteractionAndTargetingLayer.md): interaction and targeting on movement/position.
|
|
- **Downstream epics** — Gathering (E3.M1), zone transitions (E4.M1), and others consume position implicitly via higher layers.
|
|
|
|
## Related implementation slices
|
|
|
|
See Epic 1 **Slice 1 — Movement and position sync**: server-authoritative or client-predicted baseline with `MoveCommand` / `PositionState` reconciliation; interaction range single source of truth; telemetry hooks such as `session_start`, lightweight position samples, and `interaction_attempt` failures.
|
|
|
|
## Risks and telemetry
|
|
|
|
- Desync between client prediction and server authority: mitigate with one reconciliation ruleset and log desync via [E9.M1 — TelemetryEventSchema](E9_M1_TelemetryEventSchema.md) when schema exists.
|
|
|
|
## Source anchors
|
|
|
|
- Master plan: [`neon_sprawl_vision.plan.md`](../../../neon_sprawl_vision.plan.md) — Core Epic Map, Epic 1.
|
|
- [Module dependency register](module_dependency_register.md)
|