clearup

2026-04-06 11:58:36 +08:00
parent b1b38b485e
commit aebc4011c7
84 changed files with 5796 additions and 238 deletions
@@ -0,0 +1,23 @@
+# client-gameplay-input Specification
+
+## MODIFIED Requirements
+
+### Requirement: Controlled client movement input preserves immediate prediction and explicit stop signaling
+
+The MVP client SHALL capture movement intent for the controlled player in Unity-side input code, apply local movement prediction immediately, and send `MoveInput` updates through the networking boundary. When movement input transitions from non-zero to idle, the client MUST send one final zero-vector `MoveInput` so authoritative movement can stop cleanly. When the client reconciles against authoritative state and replays pending `MoveInput` messages, the replay path MUST apply each pending input in fixed-duration substeps matching the server authoritative movement cadence, so that replay trajectory matches live prediction trajectory for the same input sequence.
+
+#### Scenario: Controlled player moves locally without waiting for the network
+- **WHEN** the controlled player provides non-zero movement input
+- **THEN** the client applies local movement prediction immediately for presentation
+- **THEN** the client submits a `MoveInput` carrying the current player id, tick, and planar movement vector through the networking send path
+
+#### Scenario: Releasing movement emits an explicit stop update
+- **WHEN** the controlled player releases movement input after previously providing non-zero movement
+- **THEN** the client sends exactly one final `MoveInput` whose movement vector is zero
+- **THEN** local predicted movement also stops immediately without waiting for authoritative correction
+
+#### Scenario: Replay uses fixed-step substeps matching server cadence
+- **WHEN** the client accepts an authoritative `PlayerState` and replays pending `MoveInput` messages
+- **THEN** each `PredictedMoveStep` is consumed by applying its input in fixed-duration substeps equal to the server authoritative movement cadence
+- **THEN** the replay accumulation shape is identical to the live FixedUpdate prediction path for the same input values
+- **THEN** non-linear trajectories (e.g. simultaneous turn-and-move) produce the same result in both replay and live prediction
@@ -0,0 +1,36 @@
+# client-prediction-replay-granularity Specification
+
+## Purpose
+
+Define the contract that client-side replay of pending movement inputs MUST use fixed-step accumulation matching the server authoritative movement cadence, not a single accumulated duration, so that replay trajectory matches live prediction trajectory for the same input sequence.
+
+## Requirements
+
+### Requirement: Replay uses fixed-step accumulation matching server cadence
+
+The controlled-client prediction replay path SHALL consume each pending `PredictedMoveStep` by applying its input in fixed-duration substeps equal to the server authoritative movement cadence, regardless of the step's total `SimulatedDurationSeconds`. The replay accumulation shape MUST be identical to the live `FixedUpdate` prediction path for the same input values.
+
+#### Scenario: Replay produces same trajectory as live prediction for steady input
+- **WHEN** the client replays a `PredictedMoveStep` with turn=0, throttle=1, duration=0.15s using a 0.05s server cadence
+- **THEN** the replay applies 0.05s + 0.05s + 0.05s substeps in sequence
+- **THEN** the final predicted position matches the position that would result from three consecutive FixedUpdate predictions of 0.05s each with the same input
+
+#### Scenario: Replay produces same trajectory as live prediction for turn-and-move input
+- **WHEN** the client replays a `PredictedMoveStep` with turn=0.5, throttle=1, duration=0.10s using a 0.05s server cadence
+- **THEN** the replay applies two 0.05s substeps where each substep's heading affects the next substep's forward direction
+- **THEN** the final predicted heading and position match the live prediction path for the same input sequence
+
+#### Scenario: Replay handles non-multiples of cadence interval
+- **WHEN** the client replays a `PredictedMoveStep` with duration=0.12s using a 0.05s cadence
+- **THEN** the replay applies 0.05s + 0.05s + 0.02s substeps sequentially
+- **THEN** no remaining duration is lost or double-counted
+
+### Requirement: Replay trajectory determinism is verifiable
+
+The client prediction system SHOULD provide a deterministic way to verify that replay and live prediction produce identical trajectories for a given input sequence, enabling regression coverage.
+
+#### Scenario: Replay and live prediction produce identical results
+- **WHEN** a controlled client records a `MoveInput` sequence during live play
+- **AND** the client triggers reconciliation and replays those same inputs
+- **THEN** the final predicted pose after replay equals the predicted pose that would result from live FixedUpdate simulation for the same input sequence
+- **THEN** the result is stable across multiple replays of the same input sequence