Client/Server Motion Requests [AESOP Client Library]

How do you keep the client and server in sync on object locations? Obviously, this is a deep problem, see references such as http://gafferongames.com/2009/01/25/game-networking-resources/ More...

Collaboration diagram for Client/Server Motion Requests:

How do you keep the client and server in sync on object locations? Obviously, this is a deep problem, see references such as http://gafferongames.com/2009/01/25/game-networking-resources/

AESOP uses a combination of predictive physics and interpolation. See ObjectSync for more details.

There is another question: what do you send over the wire to the server? The client's actual requested position, or just the position delta?

Sending the position has one drawback: the client sometimes has a very bad position idea. For instance, when there is a large change in position due to non-client input. This can lead to oscillations as the client and server try to agree on a position and overshoot due to network lag.

The position has a nice property: it deals well with dropped packets. Regardless of how many packets are missed, once the server gets a position request from the client, it knows exactly where the client wants to go. Also, sending only position deltas requires accumulating deltas on both the client and server, which can lead to rounding errors.

For all of that, I've found that sending deltas is more stable. Rounding errors and occasional packet drops can require correction more often than sending absolute positions, but it tends to be a high rate of very small corrections, rather than the occasional very bad oscillations seen with sending absolute positions. So the player experience is better with deltas.