Dealing with lag in XNA + lidgren

Question

I am experimenting with lidgren in XNA and I'm having some issues with the 'lag'.

I've downloaded their XNA sample and noticed that even their sample lags. The thing is, the movement is not smooth on the other side, and I'm trying this on a LAN (on the same computer actually) not over the internet.

Has any had the same issues as regards unsmooth movement due to a lagging connection with lidgren and XNA ?

Answer 1

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 (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.