0
\$\begingroup\$

I'm working on networking code for a social MMO (very low-intensity compared to an FPS) and have a question about fixed timestep.

This answer does a good job of explaining the forward-dating part of utilizing a fixed timestep, but doesn't seem to have the whole picture. If the forward-dating was meant to account for the packet getting all the way through the server to the other clients, wouldn't it have to either take into account the latency of the most latent client in order to arrive in time, or deal with it being late? I assume this is where the "simulate other clients as being a few ticks behind" concept comes in.

My question is: how is this back-dating offset calculated? Is it a single number for all other clients, or should it be variable through the server sending each client's latency? What goes into the calculation?

I would assume that the starting point is any delay caused by differences in tick rate between the game tick and networking tick (e.g. game is 60 ticks/s, network is 20 and both are in phase, you need to push clients back at least 2 ticks to let the server's network re-tick.) Is this understanding accurate?

Improve this question
\$\endgroup\$
3
  • \$\begingroup\$ An alternative to forward-dating is to simply apply all the inputs at the time they were entered by their respective player. Since you don't find out about a remote player's input until some time after that moment, this involves predicting the input you expect, keeping a history you can rewind and replay with the new information when it arrives, and interpolating to correct for any misprediction. Glenn Fiedler of "Fix Your Timestep" fame describes this approach here \$\endgroup\$ – DMGregory♦ Apr 29 '20 at 11:14
  • \$\begingroup\$ Interesting, so this is all happening on the client with regards to its own inputs? Does the server do the same thing at all? (predicting inputs, but backing up and replaying if they don't line up) Does it really work out fine for all participants with only the client-side buffer accounting for latency? \$\endgroup\$ – Archduke Apr 29 '20 at 20:17
  • \$\begingroup\$ Yes, the prediction happens on the client, as does the rewind-replay for the local player's actions. (For remote replicas, you can just interpolate to what the server says is their current state, which might change as the server gets more info and folds that into its own replay). The server needn't predict. But it does need to rewind and replay when information arrives (tolerably) late. \$\endgroup\$ – DMGregory♦ Apr 29 '20 at 20:23

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.