Spring RTS Engine

So Spring uses a client-server deterministic lockstep which is different from most RTS games past and present. I'm assuming that the main reason is because it reduces network traffic?

I noticed that the Syncing System page on the wiki was last updated in 2013. Has the syncing system changed since then?

I'm asking since I've noticed that when there are a lot of units, players with slow CPUs start to "lag out" whilst players with fast CPUs can keep playing at normal speed.

This thread from 2009 suggests that the game proceeds at the pace of the slowest machine but this doesn't seem congruous with my previous observation.

So my question is, what actually happens to players when they lag behind the server's simulation? Do their commands just get ignored by the server and their units don't move, making them equivalent to NullAI? So the rest of the players are essentially playing with/against a NullAI player whilst that player is lagged out? How does this work exactly?

Technically speaking, if all the players are desynced with the server due to slow CPU, does the game continue to happen on the server, so that when a player catches up eventually he can start playing the game again?

More technical detail would be nice.

Thanks a lot.

grinman wrote: ↑10 Sep 2018, 21:48 So Spring uses a client-server deterministic lockstep which is different from most RTS games past and present. I'm assuming that the main reason is because it reduces network traffic?

It is exactly like most past and present RTS games such as AOE, SupCom, SC:BW, SCII and many more.

grinman wrote: ↑10 Sep 2018, 21:48 I noticed that the Syncing System page on the wiki was last updated in 2013. Has the syncing system changed since then?

Yes, we no longer have abundant syncing errors. Resyncing is therefore not a big goal.

grinman wrote: ↑10 Sep 2018, 21:48 So my question is, what actually happens to players when they lag behind the server's simulation? Do their commands just get ignored by the server and their units don't move, making them equivalent to NullAI? So the rest of the players are essentially playing with/against a NullAI player whilst that player is lagged out? How does this work exactly?

Their commands just get inserted in the queue when they arrive in the server, i.e., in the present, while they see the past, so it will take time for them until they see the result of their actions. Just like regular lag but larger.
This has nothing to do with syncing though.

grinman wrote: ↑10 Sep 2018, 21:48 Technically speaking, if all the players are desynced with the server due to slow CPU, does the game continue to happen on the server, so that when a player catches up eventually he can start playing the game again?

That doesn't count as desynced, that's being synced with the past, so yes, when they catch up their commands will have a shorter (more manageable) lag.

hokomoko wrote: ↑10 Sep 2018, 22:35 That doesn't count as desynced, that's being synced with the past, so yes, when they catch up their commands will have a shorter (more manageable) lag.

I want to check if my mental model of this is correct. In my understanding, the game host server runs its own copy of the simulation, and computes a checksum of the game state every tick. It keeps a record of all of these checksums in a vector for the entire duration of the game, for the players to check their game state against?

So each player sends a checksum of his game state to the server, and the server checks if this checksum matches in the vector of checksums, if so then the player is synced, otherwise he's out of sync?

Is it true to say that the "true" game is being played on the host server, and that clients are merely sending commands to the server to influence the game on the server, whilst running an out of date replica of the "true" game on their own machines?

The server regulates game speed based on (by default) the average CPU usage value of all clients, which means players with slower-than-average CPU's will fall further and further behind the reference time but can stay ingame with increasing order latency. Eventually (though in practice never, since most players tend to disconnect as soon as lag starts exceeding tolerable levels) this breaks the simulation, but it provides a smoother experience than "pure" lockstep models do.

Kloot wrote: ↑10 Sep 2018, 22:59 The server regulates game speed based on (by default) the average CPU usage value of all clients, which means players with slower-than-average CPU's will fall further and further behind the reference time but can stay ingame with increasing order latency. Eventually (though in practice never, since most players tend to disconnect when lag starts exceeding tolerable levels) this breaks the simulation.

How does the server know how far behind a player's simulation is?

Does it do a search through a vector containing past game state checksums for every tick and convert the index to a timestamp (by dividing it by the number of ticks per second) or just look it up in a map<gamestate_checksum, timestamp>? I guess the latter would be more efficient right?

In my understanding, the game host server runs its own copy of the simulation

No, the simulation(s) exist(s) only on the client side.

and computes a checksum of the game state every tick

Clients do this.

So each player sends a checksum of his game state to the server, and the server checks if this checksum matches in the vector of checksums, if so then the player is synced, otherwise he's out of sync?

If, for a given tick, clients do not all compute the same local checksum, then the value that most of them agree on determines who is seen as (de)synced.

How does the server know how far behind a player's simulation is?

The server knows the current simulation time (because it runs the clock which instructs clients when to tick), clients tell it at what point in simulation time they actually are.

Is it true to say that the "true" game is being played on the host server, and that clients are merely sending commands to the server to influence the game on the server, whilst running an out of date replica of the "true" game on their own machines?

There is no "true" state, just N perfectly correlated and (assuming no desyncs) uniformly evolving parallel universes.

It's a chess game between 5 players and the mailman transferring the movements and a photo of all tokens silhouette on the board doesn't have a clue.