# Epic 1 - Core Player Runtime (Client Controls + Character Loop)

## Source Anchors

- Master epic reference: [`neon_sprawl_vision.plan.md`](../../../neon_sprawl_vision.plan.md) — Core Epic Map, System Modules Epic 1
- Related modules: E1.M1, E1.M2, E1.M3, E1.M4

## Ownership and success (Level 1)

- **Ownership focus:** Gameplay Engineering + Technical Design
- **Success criteria:** Stable 3D isometric control loop feels responsive and readable across supported hardware tiers.

## Objective

Deliver the foundational client runtime: movement, locked isometric camera, world interaction and targeting, and ability input scaffolding so all other epics can attach gameplay, combat, and content without rewriting controls or presentation.

## Module Breakdown

### E1.M1 - InputAndMovementRuntime

- Responsibility: Character locomotion, click-to-move/path-follow baseline, interaction trigger range checks.
- Key contracts: `MoveCommand`, `PositionState`, `InteractionRequest`
- Dependencies: None
- Stage target: Prototype
- Status: **Ready** in the [module dependency register](../modules/module_dependency_register.md); Linear project [E1.M1](https://linear.app/neon-sprawl/project/e1m1-inputandmovementruntime-20eb28dd3db4) **Done** for prototype scope — [module doc](../modules/E1_M1_InputAndMovementRuntime.md#implementation-snapshot) for snapshot and follow-on work.

### E1.M2 - IsometricCameraController

- Responsibility: Locked isometric camera follow, zoom bands, occlusion handling, no-rotation enforcement.
- Key contracts: `CameraState`, `ZoomBandConfig`, `OcclusionPolicy`
- Dependencies: E1.M1
- Stage target: Prototype

### E1.M3 - InteractionAndTargetingLayer

- Responsibility: World object selection, target lock, focus swap rules, hover/highlight feedback.
- Key contracts: `TargetState`, `InteractableDescriptor`, `SelectionEvent`
- Dependencies: E1.M1
- Stage target: Prototype

### E1.M4 - AbilityInputScaffold

- Responsibility: Hotbar bindings, cooldown slot UI hooks, ability activation request path to combat systems.
- Key contracts: `AbilityCastRequest`, `HotbarLoadout`, `CooldownSnapshot`
- Dependencies: E1.M3, E5.M1
- Stage target: Prototype

## Implementation Slices (Backlog-Ready)

### Slice 1 - Movement and position sync

- Scope: Server-authoritative or client-predicted movement baseline with `MoveCommand` / `PositionState` reconciliation suitable for multiplayer tests.
- Dependencies: E1.M1
- Acceptance criteria:
  - Avatar moves reliably in the prototype district without rubber-banding artifacts above agreed thresholds.
  - Interaction range checks use a single source of truth for distance.
- Telemetry hooks: `session_start`, movement sample or `position_tick` (lightweight), `interaction_attempt` failures.

### Slice 2 - Locked isometric camera

- Scope: E1.M2 end-to-end: follow-center, zoom bands, occlusion policy, **yaw fixed in prototype UX** with **`CameraState.yaw`** and rig seam (`allow_yaw` / `presentation_yaw_deg`) documented for optional mid-project orbit ([E1_M2 — rotation policy](../modules/E1_M2_IsometricCameraController.md#mid-project-rotation-policy-practical-compromise)).
- Dependencies: E1.M1
- Acceptance criteria:
  - **Orbit not exposed in UX** for players in prototype (`allow_yaw` default off); zoom stays within configured bands; player remains readable during motion; occlusion policy active; `CameraState` contract documented for dependents.
- Telemetry hooks: `camera_zoom_changed` (optional throttled), occluder stress markers if needed for perf.

<a id="epic-1-slice-3"></a>

### Slice 3 - Interaction, targeting, and ability input wiring

- Scope: E1.M3 + E1.M4 with stub or live combat consumer for `AbilityCastRequest`.
- Dependencies: E1.M2, E5.M1 (minimum combat hook)
- Acceptance criteria:
  - Players can select targets/interactables and fire hotbar-bound abilities when combat module accepts casts.
- Telemetry hooks: `target_changed`, `ability_cast_requested`, `ability_cast_denied` with reason codes.

## Risks and Mitigations

- Risk: Input latency or camera occlusion hides telegraphs in isometric view.
  - Mitigation: Tune occlusion policy and feedback early; add readability checklist to prototype gates.
- Risk: Movement and interaction diverge between client prediction and server.
  - Mitigation: Single reconciliation ruleset; log desync events via E9.M1 taxonomy.

## Definition of Done

- Functional behavior validated for prototype region.
- Dependencies on E5.M1 for E1.M4 are documented and integration-tested.
- Telemetry events emitted per slice where valid E9.M1 schema exists.
- No blocker defects for prototype demo of core loop.
