question about synchronization on network

[sjinny]

i suppose there will be simulations both on the server side ( prevent cheating ) and the client side ( provide more detailed simulation ).

in the figure:
T is the network delay
the read line is the path which a server side object following
the green & blue lines are the pathes which a client side object following

if a message contains the position, velocity and the time of this status, the client could know where the server side object would be when the client received the message. but if the server side object's status is changing ( e.g. a user is changing the object's acceleration ) this prediction could be mistaken and before the next message arrives the synchronization can't be done correctly. this may be a serious problem if the user is continually changing the object's status. if don't do this prediction the client's simulation would just be the same as the server's which is just a little late.
but if there's no prediction the position between server & client's simulation could be very different when the velocity is high and if that's an FPS game the player won
t be able to aim correctly.

how would you deal with this situation ?

[bone]

You've pretty much nailed the description of the problem.

Most good networked games use some sort of prediction. Velocity doesn't always have to be the only variable used for prediction, although for an FPS that might be the best you have. If acceleration is modeled, you can use that as well (but you have to cap it or it will get really twitchy with big latencies). If there is some sort of common path that the player usually takes, you could get really smart and predict that he will follow it.

The server usually arbitrates the final outcome, so yes, the client is never going to have perfect information with which to aim in an FPS.

[Enki]

Yep. No way to avoid the problem, it is inherently built in because of network latency. You can mask it a bit by not only pushing velocities/accelerations across the network, you can go as far as pushing a subset of the inputs and that will help mask the problem. While that sounds of the wall, objects generally don't immediately react to a control input as they do in a computer simulation, real objects have dead zones and slop built into the mechanical actuation system as the control mechanisms take up all the slack and begin applying whatever controlling force results. This even happens with nerve and muscle. This is only measured in a handful of milliseconds, but for a 60fps rate a frame is only 17ms away so your inputs can sent instantaneously, but applied about a half frame later and be correcting with only about one frame lag which shouldn't make much difference for aiming.

You can also fudge the virtual size of the projectiles to equalize lag effects for the remote players, more lag, bigger projectile hit criteria. As long as your players are within a couple dozen ms of latency that should work just fine. Much more than that and the problem cannot be masked away.