I'm developing a multiplayer game that does not have prediction. It implements client-side interpolation. The problem with this is that input delay can be perceived. I've measured the various times involved in calculating the delay(packet arrival time, server respond time, time spent interpolating), and it seems about 50ms is spent on interpolating(correct), and 60ms is spent on ping and what I can only assume to be unfortunate message arrival time.

The ping is 18ms, which leaves 42ms. If the message arrives at the server immediately after the server has finished reading it's incoming messages this frame, we suffer at least a 16ms delay(at 60fps) that wouldn't be there if the message arrived right before the reading. If this happens with both the server and the client, the delay really adds up, especially at lower frame rates.

How can posts like this http://pastebin.com/ekk07PKn claim to have exactly 50ms delay with 0 ping if this is an issue?

If it's relevant, this is being developed with Unity3d and the Lidgren networking library in C#. I've moved the server snapshot writing to a different thread with a lock around the game world update method. This helped a lot, but from what I understand moving the reading to a different thread won't help in the same way, because the client won't be able to use the new information until the next frame anyway.


1 Answer 1


To be honest, I can't even imagine a single scenario, where with well implemented client interpolation an input lag would be perceivable.

Just to counter check - Client Interpolation summarized

2 Concepts meet up

1) The Interpolation itself - let the client live in the past (ae 100ms)

2) The client sends every data with a timestamp, and the server has to keep the data of all entities for some time (ae 500ms). Now for actions, that depend on other entities, like shooting, the server now can verify the position of the other entities via the timeline and the send timestamp of the client.

With these 2 concepts merged together, you have a working, well implemented client interpolation.

So first of, if your current implementation doesn't meet the mentioned requirements then change it.

If you have both methods working fine, I will need more information to assist you in locating the problem.

  • \$\begingroup\$ Your second concept sounds more like prediction than interpolation. \$\endgroup\$
    – Ben
    Commented Nov 16, 2015 at 10:20
  • \$\begingroup\$ This is not prediction this one important step of interpolation. When entity A sees the past and plays with this data as it would be present, A would never have the possibility to perform an action against entity B because it's state is not valid that A sees. So the server needs to validate that A h has seen B in A's present. And that can only work with time stamps. If you need more explaination just tell me \$\endgroup\$ Commented Nov 16, 2015 at 11:35
  • \$\begingroup\$ I don't see if the difference. If every one is delayed by the same amount, every one will be seeing the current state of the game. \$\endgroup\$
    – Ben
    Commented Nov 16, 2015 at 12:01
  • 1
    \$\begingroup\$ And as soon as you do a collision detection like a shot or aoe skill u will get a hit on the client and a miss on the server with your method. \$\endgroup\$ Commented Nov 16, 2015 at 14:10
  • 1
    \$\begingroup\$ Wait what? The clients have to wait till the server responds and validates their actions/movement? Interpolation is used when u need very frequent movement. Frequent movement is not possible if the server has to validate everything. Normally the clients send a consistent stream to the server with their actions/movement and the server does not have to validate it, he just accepts the messages and counter checks, only if something invalid happen, he corrects the client. \$\endgroup\$ Commented Nov 17, 2015 at 7:01

You must log in to answer this question.

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