   Dead Reckoning - Error correction
  I have made a decent movement prediction algorithm for my dead reckoning system and I have it working with cubic interpolation for the intermediate steps.I thought about how to best correct errors when the algorithm makes wrong predictions.In this image the blue ball moves forward most of the time which makes the prediction engine guess that it should keep moving forward. The small dots are received position updates. When the blue ball has moved to the predicted position it then gets the position update that it should have been at the shiny blue dot's position. In that same update, the predicted next position is at the shiny red dot.My question:What would be the best way to move the blue ball to the red dot without it looking unnatural?In most games, when there is lag, I see characters jump back and forth and suddenly teleporting to their destinations.A simple way would be to move it very quickly to the last received position update (blue dot) and then move it with normal speed as usual. This quick error correction would look very unnatural though. I think an approach that moves more quickly in the beginning and then slowing more and more down would be better.I thought about having it start out the interpolation with the direct line to the red dot and then combine it more and more with one of the sketched cubic interpolated curves I guess.How would you manage error correction to give smooth movement but still prioritize movements happening almost as fast as it does on the server?   
  The best solution depends on the actual game, with trade offs between accuracy vs smoothness and different movement solutions looking better/worse depending on what's moving. My current project is a top-down space sim that's fairly forgiving for latency. Smoothness is much more important than accuracy.My solution (which is for a top-down space game) looks pretty good and tolerates pretty bad latency, works like this:The client model spaceship might be at 100,100 moving at 10,30. A new message comes in saying the client is really at 120,130 moving at 8,25. In addition to the normal physics update, this new data is extrapolated into an imaginary "best guess" model (which can actually be shown on screen during debugging). This best-guess model pulls on the client model like an elastic updating both the position and velocity as a small percentage of the difference, so the farther away the client is from its best guess, the faster it corrects.If it exceeds a maximum distance the model is snapped to the best guess. I tweak the correction percentage to find a good balance between smoothness and accuracy.The player's own ship is modeled in a slightly different way, accepting immediate updates from input (so the player doesn't have to wait for his command to reach the server, the server to hit its next tick and for the response message to come back).   ;  If you look at EPIC, the way it works is to continually guess "where will the object be 100 milliseconds from now," and move the object towards that position, with a velocity such that it will get "there" in 100 milliseconds.EPIC uses linear prediction based on previous data points, but there's no reason you couldn't do it with cubic as well. Personally, I've found that cubic causes more jittery extrapolation, though.