clearup
This commit is contained in:
+17
@@ -0,0 +1,17 @@
|
||||
## ADDED Requirements
|
||||
|
||||
### Requirement: Server authoritative movement uses a fixed cadence contract
|
||||
The shared server runtime SHALL define a fixed authoritative movement cadence for simulation and snapshot production. Authoritative movement updates MUST be stepped from that configured cadence instead of arbitrary caller-provided elapsed values.
|
||||
|
||||
#### Scenario: Runtime advances movement using configured cadence
|
||||
- **WHEN** the server runtime advances authoritative movement while one or more managed peers have movement state
|
||||
- **THEN** the authoritative movement coordinator steps simulation using the configured cadence interval
|
||||
- **THEN** the same cadence governs later authoritative `PlayerState` production for that runtime
|
||||
|
||||
### Requirement: Cadence information is observable for diagnostics and regression tests
|
||||
The shared runtime SHALL expose the active authoritative movement cadence through diagnostics or runtime state that tests and debugging tools can read without inspecting private loop internals.
|
||||
|
||||
#### Scenario: Tests can read active movement cadence
|
||||
- **WHEN** an edit-mode regression or debugging path inspects the server runtime after movement setup
|
||||
- **THEN** it can observe the authoritative movement cadence configured for that runtime
|
||||
- **THEN** the observed value matches the cadence used by authoritative movement stepping
|
||||
+15
@@ -0,0 +1,15 @@
|
||||
## MODIFIED Requirements
|
||||
|
||||
### Requirement: Local player reconciliation applies the full authoritative state by tick
|
||||
The controlled client SHALL continue reconciling local prediction from authoritative `PlayerState` snapshots while keeping authoritative HP and optional velocity synchronized with the owned player-state snapshot. Reconciliation MUST use the acknowledged movement-input tick defined by the sync strategy, and the visible controlled-player transform MUST apply cadence-aware bounded correction for small divergence while preserving immediate authoritative snap for large divergence.
|
||||
|
||||
#### Scenario: Local authoritative state corrects predicted presentation
|
||||
- **WHEN** the controlled player accepts an authoritative `PlayerState` whose acknowledged movement-input tick is `N`
|
||||
- **THEN** local reconciliation prunes or replays predicted movement using tick `N` according to the sync strategy
|
||||
- **THEN** the local player's visible transform converges toward authoritative `position` and `rotation` through cadence-aware correction when the remaining error is small
|
||||
- **THEN** the local player's authoritative HP on the client matches the accepted `PlayerState`
|
||||
|
||||
#### Scenario: Large local divergence bypasses bounded correction
|
||||
- **WHEN** the controlled player accepts an authoritative `PlayerState` and the remaining transform error exceeds the configured snap threshold
|
||||
- **THEN** the controlled player's visible transform snaps immediately to authoritative `position` and `rotation`
|
||||
- **THEN** later local prediction resumes from that authoritative baseline instead of continuing from stale local presentation
|
||||
+23
@@ -0,0 +1,23 @@
|
||||
## MODIFIED Requirements
|
||||
|
||||
### Requirement: Gameplay-flow regressions include a fake-transport authoritative round trip
|
||||
The edit-mode regression suite SHALL include at least one deterministic fake-transport test that spans client send behavior, server-authoritative processing, and outgoing authoritative results. That round-trip regression MUST cover `MoveInput -> PlayerState` and `ShootInput -> CombatEvent` within the same MVP gameplay-flow suite, and it MUST assert that authoritative movement stepping follows the configured cadence contract.
|
||||
|
||||
#### Scenario: Fake-transport round trip preserves server authority across movement and combat
|
||||
- **WHEN** an edit-mode regression test drives gameplay input through fake client/server transports and advances the server authority loop
|
||||
- **THEN** the authoritative server path emits `PlayerState` snapshots in response to movement input using the configured authoritative movement cadence
|
||||
- **THEN** the authoritative server path emits `CombatEvent` results in response to shooting input
|
||||
- **THEN** the combined test protects both client single-session input flow and server multi-session authoritative behavior from regression
|
||||
|
||||
### Requirement: Gameplay-flow regressions cover controlled-player correction decisions
|
||||
The edit-mode regression suite SHALL cover the controlled-player reconciliation path after authoritative movement replay, including bounded correction for small cadence-aligned error and hard snap fallback for large divergence.
|
||||
|
||||
#### Scenario: Controlled-player reconciliation uses bounded correction for small error
|
||||
- **WHEN** an edit-mode regression test applies an authoritative local `PlayerState` that leaves only small post-replay divergence
|
||||
- **THEN** the controlled-player path keeps authoritative ownership of the snapshot
|
||||
- **THEN** visible correction converges without an immediate hard snap on the acceptance frame
|
||||
|
||||
#### Scenario: Controlled-player reconciliation snaps on large divergence
|
||||
- **WHEN** an edit-mode regression test applies an authoritative local `PlayerState` that leaves divergence beyond the configured snap threshold
|
||||
- **THEN** the controlled-player path immediately applies the authoritative transform state
|
||||
- **THEN** later prediction resumes from that authoritative baseline
|
||||
+19
@@ -0,0 +1,19 @@
|
||||
## MODIFIED Requirements
|
||||
|
||||
### Requirement: Authoritative correction prunes acknowledged prediction history
|
||||
The client sync strategy SHALL reconcile local prediction against authoritative player-state updates by pruning acknowledged movement inputs at or before the authoritative acknowledged movement tick and only reapplying newer pending `MoveInput` messages. For the controlled player, reconciliation MUST classify authoritative error after replay into a bounded-correction path for small cadence-aligned divergence and an immediate snap path for large divergence.
|
||||
|
||||
#### Scenario: Reconciliation removes already acknowledged movement inputs
|
||||
- **WHEN** the client accepts an authoritative `PlayerState` update that acknowledges movement tick `N`
|
||||
- **THEN** locally buffered predicted `MoveInput` messages with tick less than or equal to `N` are removed from the replay buffer
|
||||
- **THEN** only `MoveInput` messages newer than `N` remain eligible for re-simulation
|
||||
|
||||
#### Scenario: Small post-replay error uses bounded correction
|
||||
- **WHEN** the controlled client finishes replay after accepting an authoritative `PlayerState` and the remaining position or rotation error stays within the configured bounded-correction threshold
|
||||
- **THEN** the client keeps authoritative ownership of the accepted snapshot
|
||||
- **THEN** local presentation converges through bounded correction instead of an immediate hard snap on that frame
|
||||
|
||||
#### Scenario: Large divergence snaps immediately
|
||||
- **WHEN** the controlled client finishes replay after accepting an authoritative `PlayerState` and the remaining error exceeds the configured snap threshold
|
||||
- **THEN** the client immediately applies the authoritative transform state
|
||||
- **THEN** later local prediction continues from that authoritative baseline
|
||||
+32
@@ -0,0 +1,32 @@
|
||||
## MODIFIED Requirements
|
||||
|
||||
### Requirement: Server owns authoritative movement resolution
|
||||
The shared server networking path SHALL own the final movement state for each managed peer, including position, rotation, velocity, and stop state. Zero-vector movement input MUST stop authoritative movement rather than leaving the peer in its previous moving state. The authoritative movement integrator MUST advance using the runtime's configured authoritative movement cadence so that movement resolution and later `PlayerState` snapshots are produced from the same server-side stepping contract.
|
||||
|
||||
#### Scenario: Non-zero input advances authoritative movement state
|
||||
- **WHEN** the server processes an accepted non-zero `MoveInput` for a managed peer during an authority update step
|
||||
- **THEN** the server updates that peer's authoritative position, rotation, and velocity from server-side movement resolution using the configured authoritative movement cadence
|
||||
- **THEN** the resulting state becomes the source of truth for later `PlayerState` broadcast
|
||||
|
||||
#### Scenario: Zero-vector input stops authoritative movement
|
||||
- **WHEN** the server processes an accepted zero-vector `MoveInput` for a managed peer
|
||||
- **THEN** the peer's authoritative velocity becomes zero
|
||||
- **THEN** subsequent authoritative state snapshots reflect that stopped state until a newer movement input is accepted
|
||||
|
||||
### Requirement: Server broadcasts authoritative `PlayerState` snapshots on the sync cadence
|
||||
The shared server networking path SHALL emit authoritative `PlayerState` snapshots for managed peers at a fixed cadence using the existing sync-lane message contract. Each snapshot MUST be derived from the server-owned authoritative player state and include the authoritative tick for client reconciliation and interpolation. Authoritative HP changes produced by server-side combat resolution MUST be reflected in later snapshots for the affected peer.
|
||||
|
||||
#### Scenario: Authority update step emits sync-lane player snapshots
|
||||
- **WHEN** the server reaches the configured authoritative movement cadence while one or more managed peers have authoritative player state
|
||||
- **THEN** it sends `PlayerState` snapshots using the sync-lane delivery policy when a distinct sync transport exists
|
||||
- **THEN** each snapshot includes the authoritative position, rotation, velocity, HP, and tick from server-owned state
|
||||
|
||||
#### Scenario: Combat-driven HP changes appear in later player snapshots
|
||||
- **WHEN** the server applies authoritative combat damage or death to a managed peer
|
||||
- **THEN** later `PlayerState` snapshots for that peer carry the updated authoritative HP value
|
||||
- **THEN** clients do not need to invent or persist a separate HP truth outside authoritative server snapshots
|
||||
|
||||
#### Scenario: Reliable transport remains fallback when no sync transport exists
|
||||
- **WHEN** the server broadcasts authoritative `PlayerState` snapshots without a dedicated sync transport
|
||||
- **THEN** the shared routing path still emits `PlayerState` through the existing fallback lane behavior
|
||||
- **THEN** the authoritative snapshot contract remains unchanged
|
||||
Reference in New Issue
Block a user