process TODO.md step2
This commit is contained in:
SepComet
@@ -0,0 +1,34 @@
|
||||
# client-gameplay-input Specification
|
||||
|
||||
## Purpose
|
||||
Define how the controlled Unity client captures MVP gameplay intent, preserves immediate local prediction, and sends movement and shooting through split gameplay messages.
|
||||
|
||||
## 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
|
||||
@@ -38,3 +38,16 @@ The shared networking contract SHALL define the MVP payload fields for gameplay
|
||||
- **WHEN** client or server code constructs or parses `CombatEvent`
|
||||
- **THEN** the message exposes `tick`, `eventType`, `attackerId`, `targetId`, `damage`, and `hitPosition`
|
||||
- **THEN** `CombatEventType` provides explicit combat-result categories for interpreting that event payload
|
||||
|
||||
### 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
|
||||
|
||||
@@ -71,3 +71,16 @@ The networking stack SHALL route sync-designated traffic through the sync transp
|
||||
#### Scenario: Dedicated sync transport unavailable
|
||||
- **WHEN** sync-designated traffic is sent from a session whose integration wiring does not include a sync transport
|
||||
- **THEN** the traffic SHALL be dispatched on the primary reliable transport without failing session operation
|
||||
|
||||
### 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
|
||||
|
||||
Reference in New Issue
Block a user