I have an RTS game, with deterministic simulation, but if I want multiplayer to actually work, I need commands sent between computers to be executed at the exact same time. My game's networking is just sending commands between the players' computers, and the simulator executes the commands in order, which, hopefully, will result in each player seeing the exact same game. However, if the commands aren't executed at the EXACT same time, then the simulation will become out of step and everything will be wrong. How could I do this, and are there other ways to make sure everything is in sync?

  • \$\begingroup\$ The problem is not solvable in the way you described. You would need network latency less than 16ms (for 60 updates per second), without ever having a spike above that. An alternate system definitely would be necessary. \$\endgroup\$ Oct 17, 2014 at 16:21
  • \$\begingroup\$ @SethBattin, any suggestions? I am running my simulation thread (where the networking/AI is run) at 10fps, so 60fps is not needed \$\endgroup\$ Oct 17, 2014 at 16:28
  • 1
    \$\begingroup\$ I don't think that makes the problem go away entirely, because a single 110ms lag spike would break everything. I think a working system must be able to handle lost or out-of-order packets, but obviously that is a large, difficult problem. \$\endgroup\$ Oct 17, 2014 at 16:34
  • \$\begingroup\$ Perhaps you should try the approach of 1 game actually running a mini server. Both games talk to it and are synced off it. \$\endgroup\$ Oct 17, 2014 at 16:36
  • 1
    \$\begingroup\$ Networked physics is a really broad topic with different solutions depending on a bunch of factors (e.g.: is there an authoritative server or is the game p2p?) In fact there is literature dedicated to just this problem you have described in your question (and the lag compensation mentioned in the comments) \$\endgroup\$ Oct 17, 2014 at 16:39

1 Answer 1


There are two possible approaches to what you are describing, one wrong and the other useful.

  1. The wrong approach is to simply delay the user input from activating the command. Assuming you know the other clients can be informed 99.9% of the time in half a second, delay the command for half a second and send it to the other clients as the pair <command, activationTime> so the other clients could all preform the command synchronously. Obviously, you have to sync the clocks when the processes start which is a question on it's own.

  2. The correct approach would be to perform the command slightly later on other clients but have them behave programmatically as if the command occurred at an earlier time. i.e you time-step back some milliseconds into the past, preform the command and then re-evaluate the simulation from that point, preforming any other later command as necessary until the current time. This could lead to jittering (sudden changes in position). You can smooth these out by interpolating the animation between the true state and the subjective state on the client. i.e starting from t * trueState + (1 - t) * subjectiveState and increasing t by easing out and easing in.

  3. Alternatively, you could abandon this approach completely and use one of the clietns as a Server and the others as "dumb terminals" that only accept input and display the current state of the game; this way instead of sending orders, you constantly send updates on the new positions of units, evaluating a few steps into the future for slower connections and a more accurate present state for faster (LAN) or low latency connections.

Doing the third approach is easier, there is only one simulation. Synchronizing two simulations would be very hard, to the point of impossible. It is an interesting academic experiment and perhaps could yield useful lessons but does not seem likely unless the gameplay is very insensitve to slight variations in timing which most real time games simply aren't.

This is an example of the graph for easing out and easing in when interpolating / tweening states: ease out, ease in

  • \$\begingroup\$ I think that the second approach would be only possible if the AI simulation, while usually running at 10fps is light enough to run at 20fps bursts when needed (to fix previously corrupted state). \$\endgroup\$
    – Kostas
    Oct 24, 2014 at 10:38

You must log in to answer this question.

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