5 replies to this topic

[coffeecup]

i wrote an authoritative server / client model and read through a few tutorials about clientside prediction. most of them assume that if the client presses a key it sends a messages like "move right one point".

when a server update arrives, the client sets the local player position back to the snapshot and replays all inputs which aren't acknowleged by the server yet.

i have got client side prediction working with this approach, but i would like to set my velocity from input and calculate the position over time, so when i press "W" my client starts moving forward until i release "W", but this way my client always gets out of sync because it takes some time to get this message to the server, so for example if i press W for about 150ms, the server simulates 153ms and on the next snapshot it causes stuttering.

what's troubling me here is that in many tutorials i read "if the client/server use shared code for their entities, prediction errors will never really occure", but in my case they always occure slightly.

i tried timestamping the inputs "in the future" and appling them for the same duration which the client tells the server but this doesn't feel right since it should be an authoritative server/client model.


how can i overcome this?

Edited by coffeecup, 03 December 2012 - 09:58 AM.

[BeerNutts]

I wouldn't classify this as a "For Beginners" problem, but rather a Network and Multiplayer problem.

Please post this question in this forum.

[swiftcoder]

I wouldn't classify this as a "For Beginners" problem, but rather a Network and Multiplayer problem.

I concur. Moved.

Please post this question in this forum.

We'd much rather nobody posts duplicates. Mods can move topics as needed.

Edited by swiftcoder, 03 December 2012 - 02:13 PM.

[papalazaru]

You need to abstract the algorithm a bit better.

You start off with inputs, whatever they may be (usually, keyboard / mouse inputs, but also random number seeds, and importantly the frame time step used to update a state with those inputs).

You apply those inputs on states, whatever they may be (position, orientation, velocities).

You use sequence numbers (sqn) as a mean to refer to a particular client prediction.

You record the input / state / sqn combination on the client in a queue.

You transmit the sequence numbers and inputs to the server.

The server will run those inputs and compute new states.

The server will send back his latest state to the client (and other clients), along with the latest sequence number received.

The client will then check that state against his local prediction.

If the server state and client state diverge significantly, the client rolls back and re-sync.

This system rely on determinism. Meaning, given a state, and some inputs, you will always end up with the same result.

There are variations on the theme. I added a small example.

Attached Files

•  netpred.zip   32.06K   34 downloads

[Inferiarum]

i tried timestamping the inputs "in the future" and appling them for the same duration which the client tells the server but this doesn't feel right since it should be an authoritative server/client model.

As far as i know this is how it is done usually. The client runs ahead of the server. How does this make the server not authorative?

[coffeecup]

thanks for your inputs and thanks for moving to this forum.

I added interpolation as mentioned in the faqs to lerp the clients position to the corrected position which makes it much smoother, but it's not completly deterministic yet since I just apply the inputs as they arrive.

It seems what I am missing is timestamping the inputs to process them for the same duration, I discarded this at first because I wasn't sure how to handle things if an input arrives in the past and how to set the clienttime correctly, at the moment I set my current client time to the server time which I get from the latest snapshot and substract RTT/2 to match the server time, but I guess that I have to set the client time to latest snapshot time + some average size of the last 10 RTTs sampled instead to make sure the inputs get to the server just before they are needed.

Edited by coffeecup, 05 December 2012 - 09:31 AM.