Spring RTS Engine

Is it possible already possible to do that?
And if not, Will it be possible to add such feature?

To clairify you mean to hop into a game that's in lobby that didn't start with you right? You can watch a game currently if it starts with you by checking the "spectate" checkbox in the lobby game menu.

I don't know how plausable having new players hop into a game that's currently in progress is, and many game hosts probably wouldn't like the possibility of extra lag created by specating players that they didn't give permission to watch from the getgo.

Maybe the host could set special slot before the game and even in game?

It technically not really feasible, unless the game would be paused, the entire gamestate send over to the new spec, and then unpaused (sortof a resync but against an empty gamestate).

Another (maybe better) way would be that the host sends the old network (replay) stream as fast as possible to the spec, so the spec fastforwards through the first part of the game and as soon as the spec is at the same frame as the host, the host seamlessly starts sending the real networking stream instead of the recorded one.

Tobi wrote:Another (maybe better) way would be that the host sends the old network (replay) stream as fast as possible to the spec, so the spec fastforwards through the first part of the game and as soon as the spec is at the same frame as the host, the host seamlessly starts sending the real networking stream instead of the recorded one.

Couldn't this be used to resync as well? Of is it less efficient then copying the entire game state.

If there was a desynced game state, there are clever tricks you could use to keep the 'good' parts of the desynced gamestate and thus not need to send the whole gamestate to the desynced machine. In the case of a new spectator joining mid-battle, they start with nothing, so you have to send them the whole game state one way or the other - either in onne big chunk or as a replay stream, which would make more sense I think and cause less disruption to players. Of course it depends on the size of the total game state data vs the size of the replay-up-to-that-point.

It's slighly more efficient in terms of network bandwidth, much less efficient in terms of CPU power (as you'd have to rewind + fast forward the entire game on a resync).

Perhaps the host could set a certain percentage of bandwidth to be dedicated to spectators. Data transferred to spectators would be limited based on this bandwidth. If the bandwidth allows, the instant-replay method could be used.

Another way to do it is to have a continuous "catch-up" sync process. Things that are sent out across the network (new units built, map deformations, game time, whatever is sent) are sent as usual to the new spectator. Other things are sent as bandwidth allows - so the units on the map would slowly appear one-by-one as the game progresses. For spec/host pairs with larger throughput the "lag time" between joining the game and seeing every unit might be a few seconds (essentially a resync without game pause), but with smaller throughputs it might take a minute or two for the host to transfer all of the previously built units etc. to the spectator.

Did that make any sense at all? Basically, with each packet of data sent to the spectator as usual, attach a certain amount of additional data detailing things that were already part of the game state when the spec joined.

Felix the Cat wrote:Perhaps the host could set a certain percentage of bandwidth to be dedicated to spectators. Data transferred to spectators would be limited based on this bandwidth. If the bandwidth allows, the instant-replay method could be used.

Yeah, this sounds like a good idea, if joining a running game is ever implemented.

Another way to do it is to have a continuous "catch-up" sync process. Things that are sent out across the network (new units built, map deformations, game time, whatever is sent) are sent as usual to the new spectator.

Note that these things you mention aren't send over the network at all. Only commands are send over the network.

If you havent noticed, replays are a highly structured format, and under certain circumstances can be comrpesssed at huge ratios, I compressed an 8MB replay into 200kb using winrar not too long ago.

I think rather that a replay file should be pruned of things like explosions etc and heightmap data, then the existing heightmap is appended to the replay and the lot is compressed, leaving much less data to transmit, then the new player starts recieving backlogged data that arrived after the process started and then the game accepts the new player....... Different elements of the transfer can be left out and instead could be applied using a resync, and vice versa.

AFAIK there is no heightmap data in the replay at all. It's just the network stream dumped to file. That already explains the high compression ratios achieved: if you queue ten solars and later another ten that could be two bitwise identical blocks in the stream.

Anyway, good to know that in practise it really compresses so well, that would make the required bandwidth for in game joining somewhat lower.

The point being that a lot fo commands sent early game dotn affect present game but they do afefct the heightmap so they are all redundant and should instead be replaced with cumulatives, e.g. 2 explosions fo 10 pwoer should be replaced by 1 of 20, but there's no point, sending a heightmap would mean you could get rid of all the explosions in the replay and terrain restore commands etc.