State Synchronization Details
You can enable State Synchronization per Network View by choosing either Reliable Delta Compressed or Unreliable from the State Synchronization drop-down. You must then choose what kind of data will synchronized in the Observed property.
Unity can pack/unpack some specific classes: Transform, Animation, Rigidbody and MonoBehaviour.
Transforms are serialized by storing position, rotation and scale. Parenting information is not transferred over the network.
Animation serializes each running animation state, that is time, weight, speed and enabled.
Rigidbody serializes position, rotation, velocity and angular velocity.
Scripts (MonoBehaviours) call the function OnSerializeNetworkView().
Reliability and bandwidth
Network Views currently support two types of reliability. Reliable Delta Compressed and Unreliable.
Both have their own advantage and disadvantages, and the right mode should be chosen on a case by case basis.
For additional information about minimizing bandwidth, please read the Minimizing Bandwidth page.
Reliable Delta Compressed
Reliable Delta Compressed mode will automatically compare the data that was last received by the client. If no data has changed compared to it, no data will be sent. But on top of that the data will also be compared on a per property basis. For example, if your position has changed but your rotation has not. Only the position has to be sent across the network.
In this mode, Unity internally packs one bit prior to each property that determines if the data has actually changed. If it has not changed, the property will not be included in the serialized data thus saving a lot of bandwidth.
Unity will also ensure that every packet that is sent will arrive by resending the packet in the case of UDP packet drop until it is received. This means that if a packet is dropped, any packets sent later will not be applied until the dropped packet is re-sent and received. Until then, all later packets will wait in the buffer.
Unreliable
In Unreliable mode, Unity will send out the current state regardless of if it has changed or not. State will not be delta compressed since it is unknown if the sent data will actually arrive on the receiver.
Deciding which method to use
The Network layer uses UDP which is an unreliable unordered protocol but it can send reliable ordered packets, just like TCP does. It internally uses ACKs and NACKs do control packet transmission, ensuring no packets are dropped. The downside to using reliable ordered packets is that if a packet is dropped or delayed, everything stops until that packet has arrived safely. This can cause noticeable delays in transmission in lag intensive networks.
Unreliable sending is useful for data where you know that it is going to change every frame anyway. For example, in a racing game, you can practically rely on that the player's car is always moving. Thus delta compression and reliable transfer only adds overhead without adding an practical gain.
In general, you should use Unreliable sending when you know data is changing all the time and minimizing lag is critical. If the data tracked by the Network View is not changing every frame and bandwidth is important to you, then delta compressed is preferred.
It is important to understand that lag is not the same thing as bandwidth. They are two separate properties that you want to optimize for in different use case.
Prediction
When the server has full authority over the world state, the clients only update the game according to these states they receive from the server. One problem which arises is that controls feel unnatural as when a player pushes the forward button for example, he won't move until the updated state is received from the server. This delay depends on the latency of the connection so the worse the connection the more unnatural the actions of the player become.
One way to help with this is Player Prediction which means the client, knowing how the server calculates his movement, predicts the movement himself. So the player moves instantly with the control but the server sees his position from his last update. When the state update arrives from the server, the client will compare what he predicted with what actually happened. This might differ as the server might know more about the environment around the player, the client just knows what he needs to know. Errors in prediction are corrected as they happen, if they are corrected gradually the correction will look more smooth and less noticeable.
Dead reckoning or interpolation/extrapolation
It is possible to apply the same principle with player prediction to the opponents of the player. Extrapolation is when several last (buffered) known position, velocity and direction of an opponent is used to predict where he will be in the next frames. When the next state update finally arrives with the correct position, the client state will be updated with accurate information, possibly skipping if the prediction was bad. In FPS games the behavior of players can be very erratic so this kind of prediction only has limited effect. If the lag gets high enough the opponent will skip badly as the errors in prediction get larger.
Interpolation is when packets get dropped on the way to the client and the opponent position would normally pause and then jump to the newest position when a new packet finally arrives. By delaying the world state by some set amount of time (like 100 ms) and then interpolating the last known position with the new one, the movement between these two points, where packets were dropped, will be smooth.
Page last updated: 2010-07-19