Re: Dealing with latency extrapolation and overshooting

This is the basic latency problem of networked games. Because there is
latency between a local player seeing immediate feedback, and a remote
player seeing the same action, you only have a few options:

1) Treat input as commands queued for the future. Don't apply them
immediately to the local player; instead play a "command received"
animation. This is why RTS units say "yes, sir!" before they start moving.

2) Live with the slide. This allows as much forward extrapolation as you
want, but may also put players out of place (like, walking off cliffs etc).

3) Delay remote entities. When you received a packet "here's where I am,"
start moving the entity towards that point with velocity such that it will
reach destination by the time the next packet arrives.

You can mix these three up a bit, too, like forward extrapolating, but queue
important messages like "stop."

Sincerely,

jw

--
Americans might object: there is no way we would sacrifice our living
standards for the benefit of people in the rest of the world. Nevertheless,
whether we get there willingly or not, we shall soon have lower consumption
rates, because our present rates are unsustainable.



On Mon, Feb 1, 2010 at 11:11 PM, Blair Holloway <
[email protected]> wrote:

> I just dropped in a first iteration of interpolation to synchronise player
> positions in our networked game, but I'm having an issue where, when a
> player stops movement, remotely the player will stop ahead of where he
> should have, and then slide back into place. This seems to be a side effect
> of extrapolating the player's position ahead in order to compensate for lag.
> The problem is compounded by the fact that players don't have a lot of
> momentum, and therefore can stop dead within mere frames of applying input.
>
> What methods might I use to avoid the stop-then-slide-back effect I'm
> seeing? The only one I've been able to think of thus far is to "not
> extrapolate", which solves the problem 90% of the time, but isn't desired,
> as remote player movements will always lag behind their actual positions.
>
> Some more detail: player movement is all locomotive in a two-dimensional
> plane, driven by an animation system; animation playback itself is
> synchronised by a separate system, but one that does not (and can not)
> easily account for the drift caused by latency between machines.
>
> The current code essentially, does this:
>   * Receive (position, velocity, orientation) for remote player.
>   * Determine time since send, and extrapolate current remote position to
> hide latency.
>   * Store current time, local pos, vel, ori for remote player, and
> extrapolated pos, vel, ori for remote player.
>   * Then, every frame:
>     * Extrapolate stored local position and remote position based on
> current time.
>     * Interpolate between these two positions based on current time (aiming
> to converge in ~300ms).
>     * Apply interpolated position to player model.
>
> There is also some extra smoothing based on previous interpolation states
> going on, but I've omitted this for clarity. Positional updates are
> currently sent ten times per second.
>
> Any help would be appreciated. :)
>
> Cheers,
>
> - Blair
>
> _______________________________________________
> Sweng-Gamedev mailing list
> [email protected]
> http://lists.midnightryder.com/listinfo.cgi/sweng-gamedev-midnightryder.com
>
>

_______________________________________________
Sweng-Gamedev mailing list
[email protected]
http://lists.midnightryder.com/listinfo.cgi/sweng-gamedev-midnightryder.com