2
\$\begingroup\$

I'm making a multiplayer game built upon a lockstep system and I'd just like a better grasp on the concept. My main question is on how to get every command to simulate at the same time on every client, or rather, on the same points in each client's timeline. I'm using a fixed update of 10 frames per second for simulating every object's position from movement commands (Click and move style) the same way. How do I tell all clients to execute all commands at the same relative time to the first command? Note I'm using Unity3D and a sufficiently accurate physics implementation. I just need to get across every command at the correct time.

\$\endgroup\$
3
\$\begingroup\$

You need to have a future command queue that will only be acted upon once all parties will have confirmed reception of the command.

This queue will include no-operation null commands if no new command is to be executed.

The delay for each command can be dependent on the ping/lag.

The simulation on every peer only executes to the point (call it frame number, time, or step) where all commands have been confirmed as received so every peer will execute the same thing at the same time.

So let's say the step granularity is every 100ms, got a 175ms max network ping, we're at 332ms, the user click to move a unit, we send a packet "#N: unit A move to XY at 600ms" (332 rounded up to 400ms + rounded up ping to 200ms).

So long as a reply from all peers comes in saying "Packet #N Confirmed" before game time 600ms the game wont need to wait, if we don't receive confirmation we hold the game simulation and we resend the command packet every N ms (don't flood the network) until we get confirmation.

We also need to receive command packets from all peers for all steps, even if there are no commands send a no-command sync packet eg: "Nothing to do at 700ms".

"Confirmation of the confirmation" is simply the next command packet which is only sent if the peer has received confirmation of its previous packet, it will resend its previous command if no confirmation arrives until it gets a confirmation (or a time out and the connection is considered lost).

Confirmation can be sent as part of the next command packet to reduce traffic by increasing the queue to 2 commands with half the time (same lag overall, half the packets).

From there a lot can be added such as variable lag/ping detection/adjustments, prediction and rollbacks, etc, to reduce the perceived network lag.

| improve this answer | |
\$\endgroup\$
  • \$\begingroup\$ Thank you! This is exactly what I needed! I see now why SC2 does that lag screen if someone's packets are lost. Thanks very much :) \$\endgroup\$ – JPtheK9 Jan 5 '15 at 23:08

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.