1.8 KiB
1.8 KiB
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
PlayerStatedata lives and how local versus remote presentation consumes it. - Apply authoritative
position,rotation,hp, and optionalvelocityon the client while keeping local-player reconciliation keyed by authoritativePlayerState.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 authoritativePlayerStatedata 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.