# Executing commands at the exact same time on 2 or more computers

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?

• 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. – Seth Battin Oct 17 '14 at 16:21
• @SethBattin, any suggestions? I am running my simulation thread (where the networking/AI is run) at 10fps, so 60fps is not needed – lolbert hoolagin Oct 17 '14 at 16:28
• 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. – Seth Battin Oct 17 '14 at 16:34
• Perhaps you should try the approach of 1 game actually running a mini server. Both games talk to it and are synced off it. – Joe Swindell Oct 17 '14 at 16:36
• 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) – UnholySheep Oct 17 '14 at 16:39

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:

• 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). – Kostas Oct 24 '14 at 10:38