0

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?

Kromster
  • 10,643
  • 4
  • 53
  • 67
Dup Dup
  • 3
  • 4

1 Answers1

1

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.

DMGregory
  • 134,153
  • 22
  • 242
  • 357
  • 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? – Dup Dup Dec 03 '18 at 03:48
  • That sounds like it would work. – DMGregory Dec 03 '18 at 03: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? – Dup Dup Dec 03 '18 at 04: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. – DMGregory Dec 03 '18 at 12:58