Dealing with lag in XNA + lidgren

I've been looking at writing a multiplayer fps game, starting with a demo of just moving some cubes around and replicating the position/rotations on another machine, which is in a spectator mode.

I'm using your code sample above and it's working well (I've had to tweak the interpolation constant higher than 1 to make it look smooth).

I've seen a few interpolation examples which take into account the time difference between the current time and the time stamp on the received message.

I see this code does not use the time difference, so interpolation will take as long as it needs to, to get to the target value (or at least within the threshold value to then snap into position). My question is, is there any advantage to this?

Many thanks.

The sample you linked directly sets the position to whatever it receives from the network, this is a bad idea for a multiplayer game!

What you should do in a real game is interpolate between the local position and the remote position. So, your receive method would look a little like this:

void Receive(packet)
{
    unit.RemoteX = packet.Read_X_Position();
    unit.RemoteY = packet.Read_Y_Position();
}

This has no affect on the local position on the unit, instead in your update method (every frame), you move the local position towards the remote position:

void Interpolate(deltaTime)
{
    difference = unit.RemoteX - unit.LocalX
    if (Math.Abs(difference) < threshold)
        unit.LocalX = unit.RemoteX
    else
        unit.LocalX += difference * deltaTime * interpolation_constant
}

You then display the "local" position of the unit, this achieves lagless movement like so:

1. If the unit position is almost at the remote position, it will jump to the remote position (however, it will jump such a tiny distance that it won't look laggy).
2. If the difference is too big to jump, then move slowly towards the position you should be in.

Since the unit moves smoothly towards where it should be, it looks like there is no lag at all!

The interpolation constant controls how fast the local and remote positions will converge:

• 0: Ignore network updates
• Small: Snap into place very quickly (possibly look laggy)
• Large: Slide slowly into place, looks smooth but may feel unresponsive

You need to choose a compromise somewhere in between these options.

There are some other things to consider when implementing this kind of system, for example you often want an upper limit on how far apart units can be from their remote position otherwise the local and remote state can become "unstuck" in some situations. If they are too far apart (which should never happen except in cases of extreme lag) you can either halt the game and tell the user it's too laggy, or jump the unit straight into position, which will look laggy but at least the game will continue.

Addendum: Rereading this answer, it occurs to me that an enhancement would be to track time differences. If you know (roughly) what the lag is in the system, then you know that when you receive a packet with a remote position in you know roughly how far into the past that packet is from. If you send remote velocity too, you can predict where the object is now (assuming constant velocity). This may make the difference between estimated local state and true remote state smaller in some games, in other games (where you have lots of changing velocities) it might make things worse.