2.0 KiB
Why
The networking MVP still stops at authoritative movement. Clients can already send ShootInput and receive CombatEvent, but the shared server path does not yet validate shooting, resolve combat outcomes, or drive authoritative HP changes back into the replicated state model. Completing this closes the main gameplay-authority gap in the MVP and prevents combat truth from drifting back to client-side presentation code.
What Changes
- Add a dedicated shared server-authoritative combat capability that accepts
ShootInput, validates sender-scoped fire requests, and resolves hit, damage, death, and rejection outcomes on the server. - Broadcast authoritative
CombatEventmessages on the reliable lane and keep rejection results explicit instead of silently dropping invalid fire requests. - Extend server-owned player state so authoritative HP changes produced by combat resolution are reflected in subsequent
PlayerStatesnapshots. - Preserve per-peer isolation for shoot validation and combat bookkeeping in the multi-session server host/runtime path.
Capabilities
New Capabilities
server-authoritative-combat: Defines how the shared server path validatesShootInput, resolves authoritative combat outcomes, and emitsCombatEventresults.
Modified Capabilities
server-authoritative-movement: Expand authoritativePlayerStatebroadcast requirements so combat-driven HP changes are reflected in later snapshots.multi-session-lifecycle: Clarify that sender-scoped authoritative input validation and combat bookkeeping remain isolated per managed peer.
Impact
Affected areas include Assets/Scripts/Network/NetworkHost/, shared message-routing/runtime composition in Assets/Scripts/Network/NetworkApplication/, edit-mode regression tests under Assets/Tests/EditMode/Network/, and TODO.md / OpenSpec change tracking. No transport contract changes are expected; the work builds on the existing ShootInput, CombatEvent, and PlayerState message types.