unity3d – Synchronizing moving objects Unity


The age-old problem of synchronization. Faced a synchronization problem, re-read a bunch of material, but clearly more is needed on this issue. The problem is this: I am following an authoritarian client-server communication architecture. The player pressing the go forward button sends a command to the server, the server moves the car and poisons the coordinates of its current position, after which, through the Lerp linear interpolation function, I move the object to a new location, but apparently, between the arrival of the next signal and reaching the end point of movement machine, too much time passes, as a result of which jerks are observed, attempts to change the third parameter Lerp slow down the movement of the machine, but do not completely exclude jerks.

It seems to me that you need to use extrapolation, that is, move in a given direction until the next message arrives with a new point. What is the best way to implement this mechanism? I don't have enough knowledge of Unity, because we have to move the object in a loop until the loop receives a message about a new coordinate. But to implement this scheme, you need to know the method of listening to the channel in order to interrupt the cycle when a new message arrives.

And you get something like this:

moveCar(Vector3 newPosition, float delta)
   Vector3 direction = new Vector3(transform.position - newPosition)
   transform.position = Vector3.Lerp(transform.position, newPosition, Time.deltaTime * delta);

while(не пришел сигнал)
       transform.position = Vector3.Lerp(transform.position, transform.position+direction,Time.deltaTime * delta);


I don't remember exactly what the approach is called, but you can implement something like this:

  1. The input is being processed. The data goes to the client logic and the server.
  2. The client retains its previous state and starts moving in the direction indicated by the input.
  3. Ideally, in parallel with the 2nd point, the network module sends data to the server.
  4. A response comes from the server. In case the server has given permission do nothing. If the server refused, we return the client to the previous state.
  5. From time to time we send a full state from the server for synchronization.

But, in particular, for races, this approach may not work, because all requests must be executed strictly sequentially, changing the order will break the state. And state synchronization can lead to "jerking", because in racing everything is considered in floating point numbers and because of this, precision may leak.

Scroll to Top