Movement Prediction
ObjectNet provides an embedded Movement Prediction system to allow users of competitive games to reduce or mitigate latency problems.
Movement Prediction has a few options to adjust a fine-tuning.
Prediction Buffer Size:
This option creates a buffer where each past position is stored to be used as a database of predicted positions, you can adjust according to your needs.
Prediction Mode:
Prediction mode tells the ObjectNet how the system will check the parameters ( such as distance, angular velocity, linear velocity, etc.. ) needed to predict movement and the values can be :
Automatic : The system will automatically select the best approach
By Transform : The system will use transform to calculate needed values, this can be useful if your objects don't have a rigid body.
By Physics: The system will use physics objects ( such as Rigid Body ) to calculate needed values.
Latency Factor
This topic explains how latency affects your game and how the Latency factor parameter can be used to mitigate this problem.
Latency is a challenge that has been a pursuit in multiplayer games since its first appearance, the latency in short, makes thing appear different from different players depending on how much time event and information arrives on their local instance.
The following drawing illustrates a latency problem in a racing game :
In the example above the vehicle on the client is always one step behind the vehicle on the server side, this can generate a lot of conditions that may break some game logic, In the ideal universe, both vehicles should keep synchronized.
Latency is a problem that you can mitigate or leave with but is impossible to solve completely. The Latency Factor tells the engine how in front object shall appear depending on player latency.
The above example illustrates how the Latency Factor works according to latency to keep the player close to the real position event when latency delay packet to be delivered to the client, how much more latency, more in front vehicle shall appear.
Speed Factor
This topic explains how objects' speed affects how prediction shall calculate real object position and how the Speed Factor parameter can be used to mitigate this problem.
When an object is moving, the amount of traveled distance can vary according to its speed, this can be expressed by the physics formula [ DISTANCE = SPEED x TIME ].
This means that much faster the object is moving, the more in front it should appear when latency increases.
Suppose that a vehicle is moving at 10 Km/h and you do not consider its speed during prediction, the result could be that you put the vehicle in front where the real appears on the server.
The following drawing(s) illustrates a latency problem in a racing game :
Now let's suppose that the same vehicle starts to move at 80km/h and you still do not consider his speed during prediction, the result could be that you put the vehicle in behind where the real appears on the server.
In both examples, the vehicle isn't synchronized with regard to his real position on the server due to the variation in vehicle speed.
Speed Factors mitigate this problem including object speed on prediction calculation. This means how much faster an object is moving, how much in front they shall appear when latency increases.
The above example illustrates how the Speed Factor works to mitigate this problem by adding object speed during calculations.
Custom Prediction
Embedded Movement Prediction provided by ObjectNet should work on all cases, nonetheless, ObjectNet provides an API to allow developers to create their own movement prediction and override the default prediction.
You can override the default prediction system by checking "Use custom prediction" option.
To create your own prediction system you need to create a provider script that implements the interface IPrediction ( see Providers Scripts).
You can also check the example script PredictionProvider in the examples folder. This script has a skeleton implementation of a custom prediction system.