koobas.hobune.stream
How do I reconcile discrepancies between client side prediction and my authoritative server?
My problem is with my client side prediction system. Right now I'm using photon to do my networking and I'm using the master client as the server.
When I start to move everything seems to work fine but over time the simulation on the server and the predicted movement on the client de-sync. I tried just using a lerp to move the client back to the last known good state but the de-sync happens so often that the jitter makes the game unplayable.
Both the client and server use the exact same commands for translation, physics have been disabled, and the server receives the players inputs via a buffered RPC call so I'm not sure why the simulation would be different even with packet loss. Any help with this is greatly appreciated as I'm pretty well stuck on this one.
The simulation is different because the commands reach each system at a different time.
Have a look at
http://developer.valvesoftware.com/wiki/Source_Multiplayer_Networking
and this series of articles:
http://gafferongames.com/networking-for-game-programmers/
for a deeper understanding of your problem and ideas how to fix the problem.
Yes I've read these already and have a lag compensation system. This is not the problem. The client saves it's state or snapshot (as valve calls it) every tick and the server sends its snapshot to the client every tick, both have network time stamps. When the client receives its snapshot it checks an array of previous snapshots for the one with the corresponding time stamp and validates that snapshot not the current state of the client. The problem is even though its checking this correctly they can be off by something like 2-5 units between the server and client after a bit of play and I can find no good way to reconcile this.
send positions now and then.. this is needed anyways for new players and it allows you to recover not only from prediction errors and off-ti$$anonymous$$g(And you have this, you don't have completely in sync frames/fixedFrames), but also from package loss if you switch to the faster UDP etc.
so... positions every second and between that only commands/deltas
Sorry but I'm not completely sure what you mean. If your referring to the rate at which packets are sent that's already being done. Inputs are sent from the client when there's a change using TCP i assume as they are sent using a buffered rpc call and transform data is sent from the server every 10ms, these are not buffered because they all have a time stamp and anything older then the last valid command is ignored.
I don't understand how your state can deviate if you get a fresh copy from the server every 10ms. If you project the snapshot the server sends you back in time and then apply all your local commands that you sent to the server in the meantime and simulate forward till current time, you should have more or less the same as the server. Small deviations are fixed every 10ms.
Okay, after hours of testing I think the problem happens when I send the input data to the server. I think what's happening is even when using a buffered call some times the packet gets dropped and if the player was supposed to move one unit based on that command that results in the server being one unit's worth of movement behind the client. Even knowing this, I'm not really sure what I would do to fix it.
