-
Notifications
You must be signed in to change notification settings - Fork 8
Calculate the latency of both the clients to server
advanceFrameAfterTime
> 2 * max(ClientLatency1, ClientLatency2)
Currently, after server state is received by the client, animations trigger to interpolate from old state to the new state. This adds animationDuration
time after which the client knows what the current state is.
Time taken for the correct state (after turn application) to get to end user =
-
clientLatency
+ - (remaining time in)
advanceFrameAfterTime
+ -
clientLatency
+ entitiesAnimationDuration
On keypress, setState() to re-render. Time taken to get the correct state to end user =
entitiesAnimationDuration
Need a setInterval for non-interactive state updates and event listener for the interactive state changes.
- Game works until
clientLatency
becomes larger thanadvanceFrameAfterTime
- Becuase the animations start earlier, the user gets more time to make the turn on the fresh state.
Previously,
pacman stayed at a cell from
Ts + Tl
to 2Ts + Tl
-
Ts + Tl
: State changed @ server @time = Ts. Then, it took Tl (latency time) for the changes to reach the client. - Pacman stays at this position unless the next state is received by the client.
- @
2Ts + Tl
, client receives the new state.
Time user THINKS they gets to change direction: Ts + Tl
to 2Ts + Tl
The Time they really get to change direction: Ts + Tl
to 2Ts - Tl
.
After 2Ts - Tl
, turn request will reach the server after 2Ts
. Thus, it will be applied to the newer (next) state. An unwanted change.
With client prediction,
pacman stayed at a cell from
Ts
to 2Ts
Time user THINKS they gets to change direction: Ts
to 2Ts
The Time they really get to change direction: Ts
to 2Ts - Tl
.
Since no Tl
is included in the time for the animations to trigger, user gets more time to make the turn changes.