How do I handle input in a deterministic lockstep for a 2D RTS to avoid desyncs?
#1
I’m trying to get my head around the concept of a deterministic lockstep networking model for my 2D RTS prototype. I’ve got the basic simulation loop running with fixed steps, but I’m really struggling to figure out how to handle player input in a way that stays perfectly synchronized without any desyncs creeping in.
Reply
#2
In deterministic lockstep we learned the inputs for each tick are the only thing that should change the world. We freeze the world state, collect inputs from every client, and replay the same steps on all machines using the same seed and fixed math. Any drift from non deterministic math or a different RNG sequence wrecks it, so we swapped to fixed point and integer math and hashed the state every tick to check for agreement. If the hashes mismatch, you pause and rebuild that run instead of chasing a ghost.
Reply
#3
We buffered inputs per tick and ran the sim in a fixed order, but desync still showed up when one client evaluated a tiny optimisation differently or when a float comparison drifted. We forced the entire simulation to a single deterministic path and moved to fixed point for positions so every machine ends up with identical comparisons.
Reply
#4
I once spent a weekend chasing a desync that turned out to be a UI frame that ran a couple of milliseconds later on a slower client. The lockstep still matched the world, but the rendering made it look off and you chase the wrong thing. Still, input handling was the thing that kept biting us in tests, so we kept tightening that loop.
Reply
#5
Do you think the real problem is input sync, or should you look at rollback or other approaches to manage latency?
Reply


[-]
Quick Reply
Message
Type your reply to this message here.

Image Verification
Please enter the text contained within the image into the text box below it. This process is used to prevent automated spam bots.
Image Verification
(case insensitive)

Forum Jump: