Remix.run Logo
bakies an hour ago

Why wouldn't you just send the positions to both clients in the same tick? Seems trivial to solve.

Sayrus an hour ago | parent | next [-]

Peeker's advantage is not directly related to fog of war. The peeker is moving so before the movement is even sent to the server, the client's camera began moving. As such, the peeker will have at least a tick, usually more before that new position is available to the opponent.

"Fixing" this would make movement sluggish: any movement would need to be validated by the server. Meaning delay between pressing keys and actual movement.

dvt an hour ago | parent | prev [-]

"Same tick" is a misnomer for a few reasons. First of all, games use UDP, which is basically a "fire and forget" protocol (which means packets get dropped routinely). Second of all, realtime games use some interpolation/prediction to make up for latency (and aforementioned dropped packets).

So it's sort of a "relativistic" temporal system, not a linear "oh now you're at t=1, now you're at t=2" kind of timeline. And there's all kinds of complicated ways you create concensus between multiple clients, between server and clients, etc. (A lot of this remains an active research area.)