The peer to peer lockstep networking model would seem to indicate that everyone's input is delayed the same amount. And so this would indicate that everyone would feel the same lag in response to their input.

But in Warcraft 3 from playing many custom games it is clear that the creator of a custom game has much faster response time to their input. How can this be given the lockstep model?


2 Answers 2


I found the following comment on an article on lockstep, that should explain it http://gafferongames.com/networking-for-game-programmers/what-every-programmer-needs-to-know-about-game-networking/

StarCraft don’t use peer-to-peer it uses client-server model with lockstep (at least warcraft 3 does so). It has the advantage what theoreticaly laggers will not affect gameplay/response latency at all (but to not let them fall behind server do timeouts so the lagger can catch up, also doing temporary local game speed increasing) and imo it’s the only and true way to do sync in RTS like games. (and for some reasons this technic isn’t good covered in the web) most articles are about FPS or peer-to-peer syncs

  • \$\begingroup\$ It's not obvious to me how a client-server model with lockstep works that prevents "laggers will not affect gameplay/response latency at all". Is there a more detailed explanation of what is client-server model with lockstep. \$\endgroup\$
    – user782220
    May 19, 2012 at 10:03
  • \$\begingroup\$ I'm not 100% sure but it seems to resolve around ignoring turns for lagging players until they catch up. \$\endgroup\$
    – Roy T.
    May 19, 2012 at 10:24
  • 1
    \$\begingroup\$ Provided the server has received a response from the client in less than X ms, it simply accepts their commands as it receives them. So laggy players would increase their own response times, but not other players'. \$\endgroup\$
    – SomeGuy
    May 21, 2012 at 1:57
  • \$\begingroup\$ @SomeGuy: In p2p input is scheduled for typically 2 turns later for both peers. I'm not sure if I understand your comment, but are you saying that in a client-server model the server can require the lagger's input to be applied at greater than 2 turns later. And that thinking through all the possible behaviors this will still ensure lockstep and every possible nuance will still maintain consistency? \$\endgroup\$
    – user782220
    May 21, 2012 at 3:36
  • \$\begingroup\$ @user782220 Yes, you could have the lagger's input applied at greater than two turns later. Obviously, were the lagger's input applied immediately on his own machine, we would break lock-step, but since the lagger's actions are only returned to him when the server acknowledges them, lock-step is not broken. Instead, the lagger feels a large degree of latency between his actions and their results. At least, that's how I interpreted the above post. \$\endgroup\$
    – SomeGuy
    May 21, 2012 at 4:30

The server contains the actual running model of the game (the only source of truth).

Each player sends commands to be executed in the server's model, and when they see those actions take place, it's a result of the server accepting that command and echoing back the effect of it.

This echo is also broadcast to all other players in tandem.

If Player A is laggy (experiencing high latency), their actions take longer to reach the server, and their view of the game will be slightly behind the actual game.

If Player B is not laggy (fast connection, low latency), they may very well see the effects of Player A's actions before Player A can!

Now if we had no server, one of the player's must be the source of truth (or worse still a shared truth). This is where being laggy AND the server causes everyone else to be laggy regardless of how awesome their connection is. Being a laggy server is like being a bottleneck.


You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .