Skip to content

Calculate the latency of both the clients to server

Shivang Tripathi edited this page Apr 6, 2019 · 2 revisions

Find the latency for both the clients.

Currently:

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

With Client Prediction

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.

Advantages:

  • Game works until clientLatency becomes larger than advanceFrameAfterTime
  • 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.