Edit: i found that the problem was the ground-state not correctly setting when re-simulating from a server sent state.

As i dont know how to delete this thread, i have another question:

what do i do when the packet containing the jump-action gets lost (snapping back could mean walking off a cliff)?

Hi,

i recently tried to create a client side predicted multiplayer sample (with unity/Lidgren, simulated 200ms latency).

So far it works ok.

But at some points (kind of randomly) it seems to miss a 'jump'-action, gets corrected, thus glitching the token over half the jump.

i currently do it like so:

client and server start counting up their tick-counter when started.

30times a second client gets its input, sends it to the server (including the tick), applies it on itself and puts it in a list.

on the server i shift the tick according to the incoming number ( if difference > big amount: localtick = incoming tick, else tick++/--)

and move the server entity with the attached input

every 0.1 second i send the state back to the client with the servers (adjusted) tick

the client then resimulates from that tick with the inputs from its past-inputs-list.

from debug.logs i often see (on the server's side):

-intended tick: 259, current: 260

-intended tick 260, current: 259 (<-because i adjusted it before)

i guess that's where the problem lies. (the jump action is only 1 tick long). Though i'm not sure, and also not, how to handle this.

(I still consider myself a newbie)

here's a video which i hope shows what i mean (towards the end):

You have two options:

1) Either speculate on what the player is doing, and be prepared to temporarily show something that's not true (such as falling off a cliff) and having to correct that.

2) Or wait until you know for sure that you have accurate information, and only display this, which means there will be a delay before you display the movement/action.

Note that even with the speculation, when a player first starts moving (or stops moving,) there's no way you can speculate that they will do that, so you will have to snap/correct that kind of display no matter what.

In general, option 2 has much less technical problems, although many developers and some players really do not like the idea that you have to delay the display of the results of an action.

thanks for your answer, but what i meant was, if the packet gets lost on its way to the server, and the server then skips the jump-action, the player will on his client snap back to the ground where he left and, because he held forward, walk off a cliff he meant to jump over.

i had the idea: should i just send the jump and anything alike separately from the normal movement packets (and then reliable) ?

if the packet gets lost on its way to the server, and the server then skips the jump-action, the player will on his client snap back to the ground where he left and, because he held forward, walk off a cliff he meant to jump over

Welcome to the Internet!

should i just send the jump and anything alike separately from the normal movement packets (and then reliable) ?

You will get the same kind of problem with any kind of movement. Perhaps the player dodged to the side to avoid a bullet? Perhaps the player moved forward to avoid a falling piano? If you lose the command, you lose the command.

You can make it less likely that the command is lost, by sending a RLE compressed set of command bits for the last X steps in each packet. This will not add a lot of space, because movement commands typically RLE compress very well. Then, if one packet is lost, you have to rewind and re-play physics from that point.

This will of course cause snapping of your player on the screen of all other players, and if another player somehow had you in the cross hairs, they will now be annoyed at the lag causing that snapping.

You can also make it client authoritative -- let the client tell the server where the client is and what it's doing. Similarly, when a client shoots another client, tell the server whether hitting or not. This, of course, ends up opening holes for cheating, so the server needs to be able to re-create any client viewed state ("I at time T0 shot player X at time T1 when my last update from him was at time T2") which ends up being the Source network model. This is still cheat-able, but you now have a slider for how much time tunneling you will allow (which will effectively exclude any player with more lag than that from the game.)