Re: Dealing with latency extrapolation and overshooting

Hello,

Well, there are a few things you can do to reduce the impact of this.
The easiest thing to do is (as you termed it) give the player more momentum, when they begin to stop, you synchronize a timer which says "Player X will stop at Y time in Z Position". So while they might reach the position at slightly different times (they will stop faster on the client) the actual position is always correct.

We use this in approach in Fable for movement and we also use it for combat (so the hit always lands at the same time on all of the peers).
It's not ideal, and naturally once action-latency hits 0 you will be back to the same problem. As a general rule, you should try and handle at least 200ms of round-trip latency smoothly.

Are you using a client-server networking model or peer-to-peer? What type of game are you developing?

There are a couple of other approaches which work better for different genres. The one I described works best for a medium paced game (such as an action-rpg).

Hope that helps

Joe Hegarty
Network Programmer
Microsoft Game Studios
[email protected]

From: [email protected] [mailto:[email protected]] On Behalf Of Blair Holloway
Sent: 02 February 2010 07:11
To: [email protected]
Subject: [Sweng-Gamedev] Dealing with latency extrapolation and overshooting

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