Networked Physics with PhysX

Development Programming & Scripting C++
162

Thank, this confirms my approach.

For short summary.

  1. They fixed timestep.
  2. By fixing timestep, They can index history buffer and input buffer using physic tick count.
  3. Client and Server has their own physic tick count. They exchange it during replication. This help locate in history buffer.
  4. Their method is server authoritative with client prediction for both car and ball. So, the car can hit the ball with precision. Client doesn’t predict other player car. So, Hit with the car can still create discrepancy.
  5. Client send input array to server to handle packet loss.
  6. To handle jitter/latency variance, They wait a few physic ticks before consuming input buffer.
  7. They use method call downsteam to handle too long or too short input buffer.

  • If Server’s input buffer is too short, Server consume 1 input for more than one physics tick.

  • If Server’s input buffer is too long, Server consume more than 1 input per physics tick.

  1. They recommend using upsteam, which Overwatch is using, instead of downsteam. This technique is available on GDCValut: “Overwatch” Gameplay Architecture and Netcode.

  • If Server’s input buffer is too short, Server tells client to run faster.

  • If Server’s input buffer is too long, Server tells client to run slower.

  • I assume that server tells all client . Can we do this using dilation and change upper limit of framerate?