# How do online games deal with lerp overshooting?

From what I understand, when you lerp in an online game, you travel from point a to b based on the elapsed time since the last update. The problem is when you have a higher latency, and you start receiving updates at inconsistent rates. So lets say I have variable t, variable t tracks the time since the last update and is only reset when a new update is received. The variable t is also responsible for moving the lerp like so:

lerp(a, b, t)

But when we receive updates at an inconsistent rate, t is reset inconsistently, so if there is any lag between the updates, t will keep incrementing, thus, the lerp will overshoot. How do online games deal with this?

• Have you read some existing Q&A on client-side interpolation for some ideas? Dec 3, 2018 at 3:01
• @DMGregory, prediction is not an option for me as my game is very simple and lacks a lot of the things needed for it. Dec 3, 2018 at 3:12
• Perhaps then, instead of asking what other online games do, it would be better to tell us about your game's situation, and ask how to solve the problems you're encountering in that particular case. Dec 3, 2018 at 3:17
• @DMGregory Its as I described, the lerp overshoots due to the lag of the updates. Dec 3, 2018 at 3:19

Often, we'll just accept some overshoot, and blend it out as needed when we eventually get the next update packet some milliseconds later.

A lot of things in games move in reasonably straight lines or or broad arcs on the timescale of update packets, so assuming the object keeps going the direction it was last known to be travelling in is often a very accurate first guess.

If you have some domain-specific knowledge, of course, you can propose better predictions. Say you're dealing with an object on a tether, or a vehicle with its wheels turned to steer around a corner - you might decide to predict its motion in an arc instead of a straight line.

If prediction is absolutely off the table, then you could clamp your lerp parameter at 1 so the object will stop and wait for the next update before proceeding, but that can cause it to visible hesitate & stutter in its motion.

To avoid this without predicting, you can instead choose to let it live further in the past. Say, instead of living one average packet interval behind the server, you let it stay up to 2, or even 3 updates back. This gives you a much longer buffer to absorb a late or missing packet before you run out of movement history to replay.

In Watch_Dogs 2's multiplayer, they allow this "time in the past" parameter to vary as a function of the player's average measured lag as well as vehicle speed and collision probability, so they keep the movement looking as smooth and accurate as possible with interpolated history most of the time, and zero-in toward the current moment in cases where a collision is likely so that the two sides observe roughly the same collision event.

• I think the buffer method would work best for me. So to do this would I add every server frame to a list and interpolate to them, deleting them from the list as they are completed, correct? Dec 3, 2018 at 3:48
• That sounds like it would work. Dec 3, 2018 at 3:49
• When I set the speed of the lerp by going: t = timeElapsed / updateRate;, the lerp completes too quickly, in turn the coords that were just lerped get deleted. As a result the list gets depleted of frames quickly, leaving nothing to be lerped to. What speed should it be set to to avoid this? Dec 3, 2018 at 4:45
• Sounds like something you should ask as a new question, showing the details of how you calculate timeElapsed, UpdateRate, the blended position, and how you update your history buffer. Dec 3, 2018 at 12:58