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.
- Server is on T.
- 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.
- Client sends input at T+3 to "jump".
- Server receives input at its T+3, simulates it, and sends it to other clients.
- 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.