6 ms·

One of the more interesting techniques in my opinion is deterministic lockstep (DL). DL is achieved with fixed point numbers (or standard floating point but thi

One of the more interesting techniques in my opinion is deterministic lockstep (DL). DL is achieved with fixed point numbers (or standard floating point but this is very very brittle) and an incredibly high level of attention paid to all sources of randomness, lest your clients become desynced. DL allows your clients and servers to run the same simulation at the same time. Not “in the future” or “in the past”... at exactly the same time, frame for frame exactly equal. This means the server doesn’t have to dictate the transform results for any objects, they are entirely computed on the client. My understanding is that while this sounds like the holy grail in theory, in practice it doesn’t work with a large number (read: greater than 2) of clients because “lockstep” means lowest common denominator latency. I am very interested in hearing ways to beat this limitation though, as it seems like an ideal model for network performance.

Liquid_Fire 6y ago
> in practice it doesn’t work with a large number (read: greater than 2) of clients I'm not sure I agree with that. Pretty much all real-time strategy games use this sort of lockstep simulation, and many are perfectly playable with 8-12 players. There are various techniques for hiding some of the latency (making it less obvious). For example, for an RTS game if you issue a move command to a unit, you might locally play an acknowledgement sound immediately and animate the unit starting to turn towards the destination even before it actually starts moving. It's true that one player with particularly bad latency can ruin the latency for everyone. But the same is true even with just 2 players. It's also worth noting that a lockstep simulation is probably not suitable for games where immediate feedback on player actions is required/desirable (e.g. a fast-paced FPS), due to the inherent extra latency of having to synchronise player actions to all clients before actually simulating them.
- AnIdiotOnTheNet 6y ago
  IIRC, the original DOOM netplay (and serial/modem) used deterministic lockstep. If you have a low enough latency and a solid guarantee against packet loss it works fine for FPS. Problem is, of course, that neither of those things are true outside of a LAN (and sometimes even within them).

Liquid_Fire 6y ago

> in practice it doesn’t work with a large number (read: greater than 2) of clients I'm not sure I agree with that. Pretty much all real-time strategy games use this sort of lockstep simulation, and many are perfectly playable with 8-12 players. There are various techniques for hiding some of the latency (making it less obvious). For example, for an RTS game if you issue a move command to a unit, you might locally play an acknowledgement sound immediately and animate the unit starting to turn towards the destination even before it actually starts moving. It's true that one player with particularly bad latency can ruin the latency for everyone. But the same is true even with just 2 players. It's also worth noting that a lockstep simulation is probably not suitable for games where immediate feedback on player actions is required/desirable (e.g. a fast-paced FPS), due to the inherent extra latency of having to synchronise player actions to all clients before actually simulating them.

AnIdiotOnTheNet 6y ago
IIRC, the original DOOM netplay (and serial/modem) used deterministic lockstep. If you have a low enough latency and a solid guarantee against packet loss it works fine for FPS. Problem is, of course, that neither of those things are true outside of a LAN (and sometimes even within them).