process TODO.md step2

2026-03-28 15:02:40 +08:00
parent a0a8c0a89d
commit 4a152e765b
17 changed files with 450 additions and 42 deletions
@@ -0,0 +1,30 @@
+## ADDED 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.
+
+#### 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
+
+### Requirement: Controlled client captures shooting intent as a dedicated gameplay input
+The MVP client SHALL capture local fire intent separately from movement and translate that intent into `ShootInput` messages rather than overloading movement or generic gameplay-action payloads.
+
+#### Scenario: Firing produces a shoot input message
+- **WHEN** the controlled player triggers a fire action
+- **THEN** the client constructs a `ShootInput` containing the current player id, tick, and aim direction used by the MVP client flow
+- **THEN** the message is sent through a dedicated shooting send path instead of a legacy generic gameplay-action message
+
+### Requirement: Local shooting presentation remains cosmetic
+The MVP client SHALL treat any immediate local shooting feedback as optional cosmetic presentation and MUST NOT use it to finalize authoritative combat outcomes.
+
+#### Scenario: Cosmetic firing feedback does not decide gameplay truth
+- **WHEN** the client plays local muzzle flash, animation, or similar fire feedback before server confirmation
+- **THEN** that feedback does not apply authoritative damage, hit confirmation, or death resolution locally
+- **THEN** gameplay truth remains dependent on authoritative server messages
@@ -0,0 +1,14 @@
+## ADDED Requirements
+
+### Requirement: Client gameplay actions use split gameplay messages directly
+The client-facing gameplay send path SHALL express MVP gameplay actions directly as `MoveInput` and `ShootInput`. Controlled-player movement and firing MUST NOT depend on legacy broad gameplay messages such as `PlayerAction`.
+
+#### Scenario: Client movement uses MoveInput directly
+- **WHEN** the controlled client sends gameplay movement intent
+- **THEN** the send path uses `MoveInput`
+- **THEN** the client does not wrap that movement intent in `PlayerAction` or another broad gameplay payload
+
+#### Scenario: Client firing uses ShootInput directly
+- **WHEN** the controlled client sends gameplay firing intent
+- **THEN** the send path uses `ShootInput`
+- **THEN** the client does not wrap that firing intent in `PlayerAction` or another broad gameplay payload
@@ -0,0 +1,14 @@
+## ADDED Requirements
+
+### Requirement: Client gameplay input preserves movement and shooting lane semantics
+The client gameplay-input flow SHALL preserve the MVP delivery-lane contract when sending gameplay actions. Explicit zero-vector `MoveInput` updates generated on input release MUST remain valid high-frequency sync traffic, and `ShootInput` generated from local fire intent MUST use the reliable ordered lane.
+
+#### Scenario: Stop movement update remains sync traffic
+- **WHEN** the controlled client sends a zero-vector `MoveInput` after releasing movement input
+- **THEN** the message is still treated as `MoveInput` for delivery-policy resolution
+- **THEN** the networking stack routes it through the high-frequency sync lane when one is configured
+
+#### Scenario: Shoot input remains reliable traffic
+- **WHEN** the controlled client sends `ShootInput` from the MVP fire-input path
+- **THEN** the networking stack resolves that message to the reliable ordered lane
+- **THEN** firing intent does not share the latest-wins sync delivery behavior used for movement updates