To clarify for some who might be reading:
When we talk about sync here, we mean sync between simulations running on different machines.
e.g. I see a krogoth in my game, and issue a command. Because we are in sync, it is a valid assumption that there is also a krogoth in your game, because our game states are identical, we are 'in sync'.
If we were desynced we would be issuing the same commands but the result would be nondeterministic. We might both win, with different units, and different outcomes, with all sorts of bugs.
Thus, synced code must be the same on all machines with the same data fed in. This is why our networking model is the way it is. Unsynced code generates commands. Unsynced code only interacts with synced code in a read only manner. To employ change in the simulation commands are issued, and that is how the simulation progresses.
AI, player GUI, the camera, etc etc, are all examples of unsynced code. They differ from machine to machine and don't necessarily need to run on everybodies machine for the game to have the same outcome.
Population Limit/Unit Cap - Containers - Inquiery
Moderator: Moderators
Re: Population Limit/Unit Cap - Containers - Inquiery
Spring is a perfect example of model-view-controller done right.
- Forboding Angel
- Evolution RTS Developer
- Posts: 14673
- Joined: 17 Nov 2005, 02:43
Re: Population Limit/Unit Cap - Containers - Inquiery
jlwing wrote:zwzsg Sorry If I offended you with my questions your post is almost aggressive in nature. I was and am being formal because I thought it would help.
Hehe don't worry, that's just Z's way of carrying the discussion, he doesn't mean anything by it, and he's actually a really nice guy (the vast majority of us around here are, but you'd never know it from the way we talk to each other

Re: Population Limit/Unit Cap - Containers - Inquiery
Hello!
I found this topic by chance.
The discussion was very interesting, and i was especially intrigued by the explanation about the synchronization.
In fact, i was wondering about the case of a lag of a player.
How is it possible to continue to simulate the behavior of this player when he is lagging?
When his connection is lost, I assume other player's computers try to run the simulation anyway. But, i suppose that the player lagging is able to play too on his computer.
How do you manage the situation when you see he acted and moved his troops during the lag? (the desynchronization in fact)
Do you freeze the game for the lagger? So he can't play and there is no desynchronization.
Or maybe do you teleport his units by an update of all his units coordinates?
Or perhaps something else? :p
Thanks for the answer! (and sorry for the mistakes: i'm not an English native speaker
)
I found this topic by chance.
The discussion was very interesting, and i was especially intrigued by the explanation about the synchronization.
In fact, i was wondering about the case of a lag of a player.
How is it possible to continue to simulate the behavior of this player when he is lagging?
When his connection is lost, I assume other player's computers try to run the simulation anyway. But, i suppose that the player lagging is able to play too on his computer.
How do you manage the situation when you see he acted and moved his troops during the lag? (the desynchronization in fact)
Do you freeze the game for the lagger? So he can't play and there is no desynchronization.
Or maybe do you teleport his units by an update of all his units coordinates?
Or perhaps something else? :p
Thanks for the answer! (and sorry for the mistakes: i'm not an English native speaker

Re: Population Limit/Unit Cap - Containers - Inquiery
If a player is lagging, his orders just take longer to arrive at the server, and even longer before they make it back to that client to be executed. Server messages telling the client to execute a new simulation frame will also be delayed. The server will then start slowing down the game speed (if the lag was caused by high client CPU usage) for all clients so stragglers have a chance to catch up their local simulations.
If a player still gets too far behind the rest (measured by "ping" in simulation frames), the server drops his connection.
If a player drops, he no longer sends or receives orders at all.
If a player still gets too far behind the rest (measured by "ping" in simulation frames), the server drops his connection.
If a player drops, he no longer sends or receives orders at all.
Re: Population Limit/Unit Cap - Containers - Inquiery
A player can be several frames behind other players in this model. Because the simulation runs on the orders sent from the host, any lag caused by the cpu manifests as a simulation that is several frames behind. This does not mean the machine has desynced, it just means it needs to catchup.
So the simulation runs and eventually catches up with the rest. The main result being the frontend and what the user sees, and the much bigger gap between when you send your command, and when the simulations on each machine reach it.
So the simulation runs and eventually catches up with the rest. The main result being the frontend and what the user sees, and the much bigger gap between when you send your command, and when the simulations on each machine reach it.
Re: Population Limit/Unit Cap - Containers - Inquiery
Thanks a lot both of you for this detailed and surprising answer. (nice solution!)
This is really rare to be able to speak with developers (and this is interesting!).
That's why I will abuse and ask an other question (an open question) not really about spring itself but concerning more the subject of this topic:
Do you think a strategic view could be a way to free some CPU resources?
I'm not a pro in RTS development, but I mean that if you convert 3D objects to 2D object with the zooming out, I suppose you can gain some CPU resource (the rendering cost of theses objects decrease).
However, if you consider zooming in/out very frequently, maybe should you keep the different versions of one object loaded, and maybe is it more costly than always keeping the 3D units in the view in spite of the zooming level.
Do you think that could be a way to manage more units or maybe some other gameplay elements?
This is really rare to be able to speak with developers (and this is interesting!).
That's why I will abuse and ask an other question (an open question) not really about spring itself but concerning more the subject of this topic:
Do you think a strategic view could be a way to free some CPU resources?
I'm not a pro in RTS development, but I mean that if you convert 3D objects to 2D object with the zooming out, I suppose you can gain some CPU resource (the rendering cost of theses objects decrease).
However, if you consider zooming in/out very frequently, maybe should you keep the different versions of one object loaded, and maybe is it more costly than always keeping the 3D units in the view in spite of the zooming level.
Do you think that could be a way to manage more units or maybe some other gameplay elements?
Re: Population Limit/Unit Cap - Containers - Inquiery
That would free GPU not CPU. And Spring is more limited by CPU than GPU.
Re: Population Limit/Unit Cap - Containers - Inquiery
rendering blips/icons/billboarded sprites in place of geometry for us makes it easier for us to see units that are tiny at large zooms, and has a small rendering performance boost. I dont think we gain anything cpu wise from it though, as the simulation is just as costly, and if anything, those rendering gains are wiped out by the rendering of the entire map all at once.
Re: Population Limit/Unit Cap - Containers - Inquiery
Rendering the whole map at a reasonable detail level (viewradius 60) is not really expensive (for cpu or gpu), because even though viewed map area increases, the amount of vertexes pushed only increases by the root of the viewed area increase.