Here is some background info:

I have shared PhysicsEngine which is fully deterministic (if you have the same exact state feeding the same exact inputs and tick the same exact number of times, the end result will be the same). The simulation “ticks” at a constant frequency 20Hz. RenderEngine is working separately at its own refresh rate, so I will no describe it here.

Client-side step:

1. Creates Input package based on the current keyboard/mouse state.
2. Assigns unique id (basically frame number) to the Input and send it to the server.
3. Saves  Input in the array for future reconciliation.
4. Passes the Input to the PhysicsEngine and calculates predicted WorldState.
5. Receives WorldState from the server, search for the relevant Input in the array and make server reconciliation (re-applies inputs that are not confirmed yet and clears all confirmed inputs based on the id)
6. Makes a smooth transition from predicted to the authoritative position (if needed).

So, on every step of the simulation, we receive two snapshots:

• Input - a packaged information about the current input device state (mouse position, keys pressed and attached unique id)
• WorldState - calculated with PhysiscsEngine information about all entities (position, velocity, etc.). Also includes unique  id.

Server-side step:

1. Generates a WorldState based on received Input packages.
2. Sends a current WorldState to the clients.

QUESTION:

Basically, client-side prediction and server reconciliation works well except one thing. As I said before, both client and server sides running with the same PhysicsEngine code (thanks to js) at the refresh rate 20 times per second. BUT on the client side it runs a little bit faster (here is why).

So WorldState and Input snapshots are generating faster on the client side that server side, e.g. while server generates 484 tick, a client is at 502 or even more. After some time, a difference so big that the client starts to be littered with non-accepted inputs because they are produced more frequency than on the server side.

In ideal will be cool if client and server simulation rates will be independent.

How to deal with that? Any ideas?

1. Fix your system so that it runs 20 times a second on average. It doesn't matter that you don't have 100% control over exactly when each tick happens. It's not reasonable to expect to have full control over exactly when the updates occur, so you should just ensure that you're running the correct number over a longer period of time, by looking at the time elapsed and running sufficient updates to 'catch up'.

2. Drop the expectation that the client physics should be deterministic. It's impractical to have 2 deterministic simulations running in sync because you don't have control over the latency between the 2 simulations, unless you drop the update rate down to a point where you know you will always have time to synchronise them, which usually rules out real-time physics.

On 01.12.2017 at 3:04 PM, Kylotan said:

1. Fix your system so that it runs 20 times a second on average.

Thanks, will do.

On 01.12.2017 at 3:04 PM, Kylotan said:

Drop the expectation that the client physics should be deterministic.

Yes, I know that it is almost impossible to make physics absolutely deterministic on different machines, but anyway I think it is better to have as deterministic system as possible to reduce differences between client&server.

It is possible to run client physics on the different rate from server physics? For example client update internal physics (and predict movement) at 40Hz, but at the server physics is running on 20Hz to save CPU time. Also, how to deal with Input packages in this case? How often do I need to send them on the server?