client side prediction
Author
Hey guys, I'm trying to do client-side prediction using a client / server UDP networking model. I'm using the design found here https://developer.valvesoftware.com/wiki/Latency_Compensating_Methods_in_Client/Server_In-game_Protocol_Design_and_Optimization as the basis of my implementation. If you run two instances of the program and use the arrow keys to move the server sends out full state updates many times a second and there is simulated lag of about half a second. If I move on the server, my input is displayed correctly and the client gets the updated state and is correct. When I move on the client, my input is correctly displayed using mypredictedinput() and is updated correctly to the server. When I receive the input acknowledged packet back from the server and I know I have a state with a stateid past my prediction is where I am lost, not sure what I'm doing right / wrong at that point.
not entirely sure what you mean, but usually goes like this.
- The client keeps a cache of each inputs, and its associated predicted state, and each stamped with a sequence number.
- The server then runs those inputs in sequence, hopefully with no gaps, and compute the player state.
- The server sends back the latest player state, along with the latest sequence number received.
- If the server updates diverge from the local prediction (you can compare them by finding the prediction matching the sequence numbers), the client then resets his local player state to the correction, and re-run the subsequent inputs stored in his local cache, to compute the latest local predicted state.
So in short, you need to cache the inputs, and the associated prediction on the client so you can re-apply those inputs and re-adjust the predictions after a divergence is detected.
And so on and so forth. Once diverging, it is likely the client will still diverge to at least the time it takes for a round-trip latency, often more as divergences are generally caused by external event in the player's proximity. So as long as you have some unpredictable perturbation near the player, the client will need to correct himself continuously. Then everything will get in sync once the player is free from external forces.
There is an obvious network optimisation here, but that's a trivial change.
- The client keeps a cache of each inputs, and its associated predicted state, and each stamped with a sequence number.
- The server then runs those inputs in sequence, hopefully with no gaps, and compute the player state.
- The server sends back the latest player state, along with the latest sequence number received.
- If the server updates diverge from the local prediction (you can compare them by finding the prediction matching the sequence numbers), the client then resets his local player state to the correction, and re-run the subsequent inputs stored in his local cache, to compute the latest local predicted state.
So in short, you need to cache the inputs, and the associated prediction on the client so you can re-apply those inputs and re-adjust the predictions after a divergence is detected.
And so on and so forth. Once diverging, it is likely the client will still diverge to at least the time it takes for a round-trip latency, often more as divergences are generally caused by external event in the player's proximity. So as long as you have some unpredictable perturbation near the player, the client will need to correct himself continuously. Then everything will get in sync once the player is free from external forces.
There is an obvious network optimisation here, but that's a trivial change.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
