Synchronous RTS Engines and a Tale of Desyncs

[jamerlan]

I think that this is interesting article: "Synchronous RTS Engines and a Tale of Desyncs"

http://altdevblogaday.com/2011/07/09/sy ... f-desyncs/

[PicassoCT]

Highly interesting.. if everything is determinstic.. then who does calculate AIs? and is the AIs Comands transfered like playercomands?

[FLOZi]

Very interesting - and shows how advanced Spring really is with in-game join.

And Supcom only has 10 gameframes per second, quite a difference to Spring's 30.

[PicassoCT]

looks like a lot of emperors out there are naked -

why do people not take the spring engine for comercial games, by the way? Its for free, its under constant development.. fear of GPL much?

[smoth]

instability, poor performance, hostile community, lack of prebuilt fancy shader systems, lack of normal model formats, issues with hard coded behaviors of the engine etc..

where as you can grab ogre 3d and have an easier time etc.

oh and opengl.

[zwzsg]

So I was wrong, other RTS are synced too.

[FLOZi]

But you were right that TA system differs from Spring.

[knorke]

Very interesting - and shows how advanced Spring really is with in-game join.

And Supcom only has 10 gameframes per second, quite a difference to Spring's 30.

The game is actually running at two separate frame rates.[...]
The user layer runs at full frame rate. This layer can be thought of as strictly visual. User interface, rendering, animation, and even unit position can run at a silky smooth 60fps. Each UserTick updates at a variable time delta which is used to interpolate the game state (such as unit positions). This is why the game can look and feel smooth when itÔÇÖs secretly slow in the background.

That actually seems more advanced then the fixed 30 fps.
I think some games (flight or racing simulations) update physics at 100hz but if 10 is smooth enough for the (rather simple) physics of an RTS, then that is saving some cpu.

[FLOZi]

In terms of unsynced animation and position, yes.

And I wasn't saying 30 frames is better than 10, it's just an interesting comparison.

[Licho]

Supcom actually runs much faster than current stable spring with slow pathing.

[hoijui]

in general though, springs performance is not bad.

about stability...
if we did what all commercial games do, which is setting a high minimal set of required hardware, and refuse to run on older stuff, spring would be at least as stable. (95+% of problems with current release are GFX related)

decoubling of sim and render frames...
we discussed this extensively in.. i think two meetings so far.
i would like it, but it is a LOT of work to get there, and...
first we would have to get a much cleaner general code base, which itsself is advantageous already. for example, we would have to remove all dependencies from simulation on rendering (where not possible to remove completely, abstract through listeners or the like).
one problem with separated sim & rendering is, that it will always be more performance heavy on single-core systems, and if not done very well, and depending on factors like #cores and free ram, may also be slower on multi core systems.

[se5a]

How many people only have a single core these days?

[aegis]

going forward from today (and even the last few years), dual-core machines are going to represent the minimum system requirement for gaming.

only the very lowest-end + cheapest new machines have single cores, and save for very badly-made custom machines, anything with a good video card will have at least a dual-core. I built my mother an extremely cheap computer a couple of years ago, and it was a dual core (athlon x2)...

the only problem comes with people using geforce series 4-7 (capable of running spring with varying ability), who are more likely to be using a pentium 4 or athlon XP than a dual core... but I've already heard users with P4s complaining about performance in larger games.

anyone with an older single core will have trouble running anything well with more intense hardware requirements than say, Portal 1 (which was released around four years ago)... they're going to be accustomed to modern games not running very well, including the latest versions of spring (which have varying performance on my quad-core laptop )

[hoijui]

if we ever arrive there (nicely decoupled sim and rendering), it will be.. at the very earliest, in 3 or 4 years from now (i consider that very optimistic). at which time, even fro spring standards, it may be save to say we require two or more cores. or more practically speaking, people with too few cores will not ever be a reason to not go there, but rather the immense amount of work and possible new bugs will delay it.

[KDR_11k]

So I was wrong, other RTS are synced too.

Pretty much any complex game is synced. I had desyncs in GTA 1.

[PicassoCT]

So I was wrong, other RTS are synced too.

Pretty much any complex game is synced. I had desyncs in GTA 1.

If it has game influencing physixs its synced.

[camo]

Oh, nice article.

Since I understood the basic concept of the spring-sim, i have been wondering, when and how to decide in which synced-frame to place the input.

"The exact number of SimTicks into the future to execute a command can be dynamically determined based on the peer-to-peer topology"
Check ping and try to find a usefull value?
What happens if it fails in one step, i.e. typically it is possible to set it X frames in the future but one client in one occasion fails to receive it in time?


How are those things handled in spring?

[Tobi]

"The exact number of SimTicks into the future to execute a command can be dynamically determined based on the peer-to-peer topology"
Check ping and try to find a usefull value?
What happens if it fails in one step, i.e. typically it is possible to set it X frames in the future but one client in one occasion fails to receive it in time?

If there is a host (not p2p), then the host could simply insert the message a bit later in the stream, and adapt the frame number in which it should be executed.

How are those things handled in spring?

Spring does this in a really primitive way.

All user input that is sent over the network by clients is simply broadcasted immediately by the game server. Hence the game server serializes the input, i.e. after it passes through the game server, it will be in the same order for all clients. Every 1/30th of a second the game server inserts a message that instructs clients to run a new simulation frame. The clients execute this stream as they receive it, with a small bit of buffering to filter out very short lags in the network traffic.

So there is no mechanism in Spring to make all orders be executed a fixed time after they are given by the user - it's just first come first serve. This means an order should typically be executed one roundtrip time after you gave it in Spring, so players with a better connection to the host have a slight advantage.

[camo]

So far I assumed the clients act autonomous to process their frames. Sending an order to do so actually makes more sense. Now the concept seems to be clear to me.
Thanks for the explanation

[abma]

we now have also a syncing macosx (development) version (tested this night with daftalx)