Joining (as a spec) in the middle of a game
Moderator: Moderators
Joining (as a spec) in the middle of a game
I sometimes miss games I want to watch by just a few seconds. Could there be a way to connect in the middle of a game (I don't need a replay)?
Re: Joining (as a spec) in the middle of a game
Spring can't do this.
Re: Joining (as a spec) in the middle of a game
Can't the server just give the client all the information it needs?
(I just want to be able to watch all of a game, so if the host saved all their replays that would be fine too. Most of the time, I have to leave in the middle of a game.)
(I just want to be able to watch all of a game, so if the host saved all their replays that would be fine too. Most of the time, I have to leave in the middle of a game.)
Re: Joining (as a spec) in the middle of a game
Much bigger can of worms than you'd think, though the implementation of this would also bring in resync.
Re: Joining (as a spec) in the middle of a game
spring's state can be quite big and doing this without pausing the game would require quite some patching all around.
Re: Joining (as a spec) in the middle of a game
yeah i think that would just annoy people a lot, if there keeps joining many people, and it would make about 20 seconds lag for each person... though, it would be cool to invite a friend to watch your game, if you are having gg atm.
whats exactly the problem with the resync functionality?
whats exactly the problem with the resync functionality?
Re: Joining (as a spec) in the middle of a game
unless you can run the net code at high enough speeds to catch up
Re: Joining (as a spec) in the middle of a game
Well there's 2 ways to do this. Either you send the person connecting the replay of the game up to this point, or you send themn a snapshot of the gamestate at the current point.The latter would seem to be the sensible option, however a hybrid of the 2 would probably eliminate the need for extended pauses.

- Client starts joining
- Server sends client a snapshot of game state at current frame (frame X)frame X.
- Game keeps running, server sends the 'normal' game data stream to client, the client buffers it.
- Once client has restored the local game state to frame X, it processes the normal data stream as quickly as possible (with graphic updates still turned off).
- Once client runs out of data in the buffer, it turns on graphics and is now effectively a 'normal' spectator.

Re: Joining (as a spec) in the middle of a game
snapshot can be a couple of mb
Re: Joining (as a spec) in the middle of a game
Also the snapshot isn't that easy to identify, the gamestate is influenced by craptons of things that all have to be synced, missing one = desync.
Re: Joining (as a spec) in the middle of a game
well spring can save/load
but it takes a few seconds, then several mb needs sent
then the client needs to load
then the client needs to catch up
it would work, but it might take a while
but it takes a few seconds, then several mb needs sent
then the client needs to load
then the client needs to catch up
it would work, but it might take a while
- Forboding Angel
- Evolution RTS Developer
- Posts: 14673
- Joined: 17 Nov 2005, 02:43
Re: Joining (as a spec) in the middle of a game
Why not allow it as a hosting option? For myself I have 1.5 MB upload rate, which means that I could send the state to a client or 2 or 3 clients without breaking a sweat.
Besides, if the game is only 2 or 3 minutes in, then the state is not going to be that large.
Have the lobby client set joining specs to off after 30 minutes or something simple like that. That way there is a finite amount that the gamestate could be.
Besides, if the game is only 2 or 3 minutes in, then the state is not going to be that large.
Have the lobby client set joining specs to off after 30 minutes or something simple like that. That way there is a finite amount that the gamestate could be.
Re: Joining (as a spec) in the middle of a game
once i pressed that save button in accident, and my spring freezed for like 2 minutes, and then it crashed. and which is why the saving buttons have been changed now.aegis wrote:well spring can save/load
but it takes a few seconds
- Stealth870
- Posts: 166
- Joined: 13 Sep 2004, 00:25
Re: Joining (as a spec) in the middle of a game
I don't know the technical side of it, but wouldn't the following be possible somehow:
Game 1 is in progress. Bob from Game 1 wants Billy to watch after 1/2 an hour of intense fighting.
Billy connects to game in progress. Spring loads map, connects. Slowly each piece gets into sync. For example, Billy starts receiving the list and coordinates of all units of Bob's team, they start streaming in to Billy and soon enough it gets in sync with the game. Then Spring continues syncing up each team, one by one? It doesn't have to all be in one gulp is what I'm getting at.
In fact, even a simple "SpringTV" would work. A way to connect to a Spring game and simply get the x,z, coordinates of all the units. All you get in Spring in that large mini-map mode (like when you tab) and you see the unit icons going around. Even with just that, would be pretty fun to watch.
Game 1 is in progress. Bob from Game 1 wants Billy to watch after 1/2 an hour of intense fighting.
Billy connects to game in progress. Spring loads map, connects. Slowly each piece gets into sync. For example, Billy starts receiving the list and coordinates of all units of Bob's team, they start streaming in to Billy and soon enough it gets in sync with the game. Then Spring continues syncing up each team, one by one? It doesn't have to all be in one gulp is what I'm getting at.
In fact, even a simple "SpringTV" would work. A way to connect to a Spring game and simply get the x,z, coordinates of all the units. All you get in Spring in that large mini-map mode (like when you tab) and you see the unit icons going around. Even with just that, would be pretty fun to watch.
Re: Joining (as a spec) in the middle of a game
It has to be in one gulp due tot he way the simulation works. Synched code relies on everything being there and so a command to attack unit X wont work if unit X isnt loaded on someones machine. A rather simplified example but hope it makes sense...
Re: Joining (as a spec) in the middle of a game
There's no need - just stream a fixed (server-defined) amount every game frame... If it takes a spec a minute or 2 to connect then so be it - at least we can display a progress bar!Forboding Angel wrote:Have the lobby client set joining specs to off after 30 minutes or something simple like that. That way there is a finite amount that the gamestate could be.
Re: Joining (as a spec) in the middle of a game
Ideally, you could setup a relay server that could act as
a "playerless" connection to the main server. It would
receive all synced events, and maintain a gamestate. Real
clients could then connect to relay server and sync-up.
If setup properly, relay servers could also connect to other
relay servers.
Steps:
1. Start the game with a relay server as a player.
2. New client connects to the relay server
3. Relay server records a snapshot of the current game state
4. Relay server sends the game state snapshot to the new client
5. After the snapshot has been transferred, relay server sends all
network messages that have occurred since the snapshot to the client.
6. Continue to send new network messages, or do some kind of
hand-off to the real server if trying to join an active player.
There are obviously a number of details to work out, but I think that
that's how you'd eventually want to set it up. You could have 1 relay
server connected to the main server, that relays to 10 other relay
servers, that each relay to 10 other relay servers (100 end relays in
total). Each relay could host 10 real observers. 1000 observers for a
game at the expensive of a single observer's worth of bandwidth on
the real server.
Allowing mid-game connections for active players might be a bit trickier,
be should still be doable (once the sync update process has been
completed).
Don't expect this to be coded anytime soon
a "playerless" connection to the main server. It would
receive all synced events, and maintain a gamestate. Real
clients could then connect to relay server and sync-up.
If setup properly, relay servers could also connect to other
relay servers.
Steps:
1. Start the game with a relay server as a player.
2. New client connects to the relay server
3. Relay server records a snapshot of the current game state
4. Relay server sends the game state snapshot to the new client
5. After the snapshot has been transferred, relay server sends all
network messages that have occurred since the snapshot to the client.
6. Continue to send new network messages, or do some kind of
hand-off to the real server if trying to join an active player.
There are obviously a number of details to work out, but I think that
that's how you'd eventually want to set it up. You could have 1 relay
server connected to the main server, that relays to 10 other relay
servers, that each relay to 10 other relay servers (100 end relays in
total). Each relay could host 10 real observers. 1000 observers for a
game at the expensive of a single observer's worth of bandwidth on
the real server.
Allowing mid-game connections for active players might be a bit trickier,
be should still be doable (once the sync update process has been
completed).
Don't expect this to be coded anytime soon

Re: Joining (as a spec) in the middle of a game
that's more or less how GTV/HLTV works; the relay server also adds some delay to prevent cheating.
Re: Joining (as a spec) in the middle of a game
trepan, sounds like a good idea
directly streaming the gamestate from someone participating would be difficult
because their client needs to freeze sync for however many seconds it takes to save it
directly streaming the gamestate from someone participating would be difficult
because their client needs to freeze sync for however many seconds it takes to save it
Re: Joining (as a spec) in the middle of a game
What about distributing it bittorrent like from all the clients? Given asymmetric bw and likely multiple clients with the same gamestate vs one that needed it.