3 ms·

The issue of floating-point determinism only really comes up in lock-step networking where you are in effect simulating a distributed state machine. Rather than

The issue of floating-point determinism only really comes up in lock-step networking where you are in effect simulating a distributed state machine. Rather than continually transmitting the current state, you synchronize the state at startup and afterwards transmit only actions. In an RTS, where lock-step networking is still most commonplace, an action might be "order unit to move from A to B". In this context determinism is absolutely paramount, because any mismatch in the simulation between clients will compound itself over time, so even if the divergence starts small, it will soon grow to be very large. Whereas with client-server networking, as in Quake, a mismatch in the floating-point specifics between clients will only manifest self as a constant level of error. The error does not contaminate the simulation since it's client-side only, and the server is authoritative. The issue of latency is totally unrelated and something intrinsic to the workings of distributed systems.

iam 15y ago
Still, he brings up a good point. If the source of non-determinism is known to be exactly in the physics engine, maybe it's possible to share the global physics state every once in a while. I don't know much about game network code, but is this feasible at all? Another post brought up the reason for using lock-step networking is because of "thousands" of units, so I assume the biggest data is the physics data (x,y,z velocity, etc of said units). If some physics errors could be tolerated for a few ticks, maybe a binary search of the gamespace could be used to figure out where the error came from, and sync up the game state in that area. Could be fairly low bandwidth right?
- psykotic 15y ago
  Yes, you can mix these approaches. Almost every client-server game does that to some extent, e.g. Unreal Engine 1, 2 and 3 supports both replicated state and replicated function calls, although it's mostly based on state replication. However, even a small amount of constant error with lock-step networking means that you can't distribute the authority. Imagine a case where a unit is low on health and a tiny error in the unit's position makes the difference between whether it's out of range or in range of an enemy unit's fire. Thus it either lives or dies based on the presence of absence of that error. With fully deterministic lock-step networking, a client can make that determination on its own, without checking in with anyone else for confirmation. Without perfect determinism, the best it can do is make a tentative decision, which it might have to reverse soon thereafter if the server's view of the situation disagrees.

iam 15y ago

Still, he brings up a good point. If the source of non-determinism is known to be exactly in the physics engine, maybe it's possible to share the global physics state every once in a while. I don't know much about game network code, but is this feasible at all? Another post brought up the reason for using lock-step networking is because of "thousands" of units, so I assume the biggest data is the physics data (x,y,z velocity, etc of said units). If some physics errors could be tolerated for a few ticks, maybe a binary search of the gamespace could be used to figure out where the error came from, and sync up the game state in that area. Could be fairly low bandwidth right?

psykotic 15y ago
Yes, you can mix these approaches. Almost every client-server game does that to some extent, e.g. Unreal Engine 1, 2 and 3 supports both replicated state and replicated function calls, although it's mostly based on state replication. However, even a small amount of constant error with lock-step networking means that you can't distribute the authority. Imagine a case where a unit is low on health and a tiny error in the unit's position makes the difference between whether it's out of range or in range of an enemy unit's fire. Thus it either lives or dies based on the presence of absence of that error. With fully deterministic lock-step networking, a client can make that determination on its own, without checking in with anyone else for confirmation. Without perfect determinism, the best it can do is make a tentative decision, which it might have to reverse soon thereafter if the server's view of the situation disagrees.