Improving Movement Replication

By far, the most important events to copy across clients are the movements of the vehicles. In my current implementation, I simply send events that describe what command a player pressed: forward, backward, turn left or right, etc. This works, however, there are two problems that create large difference between clients.

One is lag. Events do not reach other clients right away, so all commands are executed later than they are actually started on the original client. So, this leads to some differences. However, this difference is not that big. The main problem comes from the second problem.

Physical simulations do not run the same way on different computers. This means that if a vehicle turns to the left for one second on computer A, the vehicle may turn 40 degrees, while on computer B it will turn 35 or 45 degrees. This causes large differences very quickly.

So, another solution is required. One roadblock is the way my vehicles move. Their movement is produced by a complex interaction of bodies, joints, and motors. So, I cannot do what many other simpler games do: manually "move" the tank from one position to another, and then smooth out the movement by using dead reckoning. I simply can't do that on my vehicles. They want to be controlled by physical laws (Newtonian), and do not like to be warped from one place to another (This may be limited to the specific engine I am using) or be forced into one position or another (by using direct external forces on vehicles, for example).

However, while these vehicles want to be "manly" and not be pushed around, I can control those vehicles via usual commands, exactly the same way that player controls the vehicles: IVehicle::moveFoward(), etc.

So, my idea is to send updates on vehicles position and orientation, and have vehicles on other clients, try to get into this position. They can turn turn and move, whatever they decide to do to get into desired location. (Btw, control is performed via IRobot's)

This solves one important problem for vehicle movement: even though simulation may run differently, robot-controlled vehicles will take care of the differences by adjusting their movements to get into the position.

Granted, this does not resolve the first problem, the problem of network lag. But this is something I cannot remove at this moment. Lag simply exists. I may decide to predict the movement on remote clients, however, if there will be a need to further improve the movement replication.