I've currently implemented rollback netcode with a central, authoritative server (wooh!). I'm running into issues where if players have zero input delay, the other players see them "teleport" to their locations once the clients receive the update.

Below is an example, assuming a 6 tick round-trip time (3 ticks to server, 3 ticks to clients) and both the client and server running at 60TPS.

  1. Server is on T.
  2. Client is enforced to always be simulating N steps ahead of its last known server frame. Let's assume it's hard-coded to T+3.
  3. Client sends input at T+3 to "jump".
  4. Server receives input at its T+3, simulates it, and sends it to other clients.
  5. Other clients receive the T+3 input at T+6. The clients roll-back to the T+3 frame and simulate back to T+6 with the corrected input.

Step 5 causes us to lose drawing T+3, T+4, and T+5 accurately so it can look like the player "teleports" to their T+6 position. One way to solve this would be to add an input delay of 3 (client sends at T+3 for T+6), but I don't think this would scale well for clients with differing round-trip times and the input delay can feel rather bad.

How is this problem typically solved? I've watched the Overwatch + Rocket League rollback netcode talks and the great videos from Net_ on YouTube, but nothing mentions how to handle smoothing out this portion.

  • \$\begingroup\$ I remember this talk on Watch Dogs multiplayer looked at some formulas they use to interpolate the motion of vehicles based on new authoritative info. They take the authoritative state as a goal to blend toward, rather than a place to teleport to instantly. In particular, in your case the T+6 is a guess at what the server will tell us next, so it's reasonable to hold it tentatively rather than committing to matching it 100% right away. \$\endgroup\$
    – DMGregory
    Nov 28 '21 at 13:29

You must log in to answer this question.

Browse other questions tagged .