25 lines
1.8 KiB
Markdown
25 lines
1.8 KiB
Markdown
## Why
|
|
|
|
The client currently treats authoritative `PlayerState` mostly as a position-correction signal, so rotation, HP, and optional velocity do not have one explicit owner on the receiving side. TODO step 3 now depends on making server truth visible and consistently applied on both local and remote players before snapshot interpolation or combat-result handling can build on top of it.
|
|
|
|
## What Changes
|
|
|
|
- Introduce an explicit client-side authoritative player-state capability that defines where received `PlayerState` data lives and how local versus remote presentation consumes it.
|
|
- Apply authoritative `position`, `rotation`, `hp`, and optional `velocity` on the client while keeping local-player reconciliation keyed by authoritative `PlayerState.Tick`.
|
|
- Expose authoritative HP and related state changes through existing player-facing UI or diagnostics so MVP development can observe server truth during playtests.
|
|
- Keep remote authoritative-state application minimal for this step and leave buffered interpolation behavior to the next TODO step.
|
|
|
|
## Capabilities
|
|
|
|
### New Capabilities
|
|
- `client-authoritative-player-state`: Defines client-side ownership, application, and observability of authoritative `PlayerState` data for local and remote players.
|
|
|
|
### Modified Capabilities
|
|
- None.
|
|
|
|
## Impact
|
|
|
|
- Affected code: `Assets/Scripts/MovementComponent.cs`, `Assets/Scripts/Player.cs`, `Assets/Scripts/MasterManager.cs`, and client UI/diagnostic scripts that expose authoritative state.
|
|
- Affected behavior: Local reconciliation remains prediction-based but consumes full authoritative state, while remote players stop relying on ad hoc position-only updates.
|
|
- Testing: Edit-mode regressions will need coverage for authoritative-state application, stale-state rejection, and explicit ownership of HP/rotation data on the client.
|