feat: NetworkTickManager - Calculating tick predictions and controlling physics ticks to synchronize the server with the client. #3943
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is a phase 1 of creating a fully Tick oriented setup.
What is the goal:
The goal is to allow a convenient solution to synchronize the Prediction tick and Server Replay ticks to allow for smooth
and CONSISTENT player experience when running server authoritative architecture while minimizing the latency based on network conditions such as packet loss.
The Network Tick Manager and Network Physics Controller are designed to work in tandem to ensure that the client-predicted tick aligns closely with the server's execution of that tick.
Additionally, it will adjust the server replay tick on the client to ensure that the server replay consistently has the necessary information from the server for accurate playback.
note: The actual timing doesn't matter and can be un-equal for sending and receiving.
All we care about is that my current client inputs arrive at the correct time on the server
and that the server send me the information before i replay server characters actions on the client.
In addition the NetworkTick will be available for easy access to the current status and tick counters.
See its description bellow.
What are the effects
There are 2 main effects of this:
How to add:
Make sure that the physics is set to script instead of fixedUpdate.
Attach NetworkTickManager and PhysicsController to an Entity.
Physics Controller
To request tick to reconcile from:
Physics controller is also built in a way that allows for adjusting for non unity built physics. For example:
NetworkTick
The class
NetworkTick
is there with static fields to allow for access across the project and consists of several static getters:Implementing NetworkedItems and NetworkPhysicsEntity
To make your entities networked the
INetworkedItem
interface was added:Usage example:
How the numbers are calculated:
Client will send his tick to the server and the server will simply return how far the client tick is from the server.
The client will then adjust based on the available data and running minimums.
Same goes for the server but instead of sending to the server we just compare current reply tick with what we receive from the server
Notes:
While testing the most likely tick offset between client predicted and server replay is going to be 2-3.
This is due to Unity fixedUpdate being tied to the framerate and Mirrors optimizations ( batching ).
While 1 tick is possible it is very rare on high tick systems ( 50+ ticks )