5
\$\begingroup\$

I'm working on a multiplayer game that for the purposes of this question, is most similar to Team Fortress.

Each network data packet will contain the 3D position of the target moving object. (this object could be another player) The packets are sent on a fixed interval, and linear interpolation will be used to smooth the transition between packets. Under normal circumstances, interpolation will occur between the second-to-last packet, and the last packet received.

The linear interpolation algorithm is the same as this post:

Interpolating positions in a multiplayer game

I have the same issue as in that post, but the answers don't seem like they will work in my situation. Consider the following scenario:

  1. Normal packet timing, everything is okay
  2. The next expected packet is late. That's okay, we'll just extrapolate based on previous positions
  3. The late packet eventually arrives with corrections to our extrapolation. Now what do we do with its information?

The answers on the above post suggest we should just interpolate to this new packet's position, but that would not work at all. If we have already extrapolated past that point in time, moving back would cause rubber-banding.

The issue is similar in the case of an early or dropped packet.

So I believe what I am looking for is some way to smoothly deal with new information in an ongoing interpolation/extrapolation process.

Since I might be moving on to quadratic or even cubic interpolation, it would be great if the same solutiuon could be applied to those as well.

Improve this question
\$\endgroup\$
1
  • \$\begingroup\$ After doing a bit more research, it seems what I'm looking for is called "reconciliation". Unfortunately there is very little information in how to do this properly. \$\endgroup\$
    – Ben Cracknell
    Jun 6, 2014 at 2:37

2 Answers 2

Reset to default
1
\$\begingroup\$

Latency, the #1 enemy of networked games.

So, your problem is, that you don't know if packet loss happened or packet is late and thus you might receive packet, that should be discarded.

You have to timestamp your packets or use incrementing id that is sent with packet, that helps you to identify packets that should not be cared anymore. If you use id for example, you could check on client, if justArrivedPacketID > lastPacketId and process it.

Improve this answer
\$\endgroup\$
0
\$\begingroup\$

I would never extrapolate. It leads to strange artifacts (e.g. a player frozen in place) but it's arguable whether that's worse than extrapolating. Also, when you get the packet, just "teleport" the player.

It's not great, but then again, losing packets sucks.

Improve this answer
\$\endgroup\$
2
  • \$\begingroup\$ That's how I started it, but packets very rarely arrive exactly on time, resulting in constant jitter. \$\endgroup\$
    – Ben Cracknell
    Jun 5, 2014 at 20:45
  • \$\begingroup\$ @BenCracknell Store early packages until you can use them and make sure you get most of them too early rather than too late. \$\endgroup\$
    – API-Beast
    Oct 10, 2014 at 9:31

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .