Joining (as a spec) in the middle of a game

[aegis]

execution still needs to be paused while synced data is saved to send

[Acidd_UK]

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.

Nice idea.

[eyu100]

trepan:

Would it work to save all the packets received and send them to the spectator in the same order? Maybe the relay server could remove some information specific to the relay server if there is any (like the username of the relay server). I think this would be easier to code, but the spectator wouldn't be able to interact with the game at all.

[Dragon45]

[eyu100]

Bump - does someone know if that would work?

[IllvilJa]

The ability to join ingame (and even reconnect to one's previous session for instance in order to recover from some problem on the client side causing an involuntary disconnect) would be a very useful addition to the Spring engine.

I know there are cases when this feature would be impractical (too much data needs to be prepared and then sent to the connecting player's client) but imagine these uses:

Mods may be written that more or less expect players to leave and join dynamically (for example, more tactically focused mods or FPS-focused mods like, say, Battlefield clones) and as such, those mods are deliberately designed to keep down the memory footprint of the game state. For instance, certain information may be aged out and deleted, like in the Battlefield games and many other FPS games where dead players and destroyed vehicles are lying around only for a limited time, then they disappear and are "forgotten" and require no memory any more. Another way to bring down the memory footprint of the game state is to bring down the number of units per player (in an FPS focused game we have just one unit for each player).

(Why create an FPS game based on the Spring engine?? Well, the Spring engine is pretty much the ONLY option available AFAIK if one want's to have an open source game with both FPS functionality as well as vehicles already implemented and yes, I'm pondering the insane idea of some open source game inspired by the Battlefield series... Could be an interesting twist for the Spring44 project for instance.)

Another situation is when a number of players gather in a LAN (or a WAN setting but being a bit more patient) and one player is disconnected (or desynced) due to network failure, client crash, computer crash etc. and that player and everyone else in the game REALLY want him/her to rejoin and continue the game where he/she "lost contact". In that context, a pause in the game might be acceptable for everyone involved (and at the end of the day, it ought to be the player hosting the game who decide whether or not to allow these kind of "mid game (re)joins". Players not liking the feature may simply avoid joining games with "mid game joins" enabled).

Then of course, the question is how to implement this and how to do it in a way that is controllable in the already complex (and according to another thread, to some extent messier than necessary) source code of Spring. We want to add features (and associated complexity) into the game in a way that DON'T cause too many bugs being added, especially not bugs causing desyncs etc.

Perhaps a good start is to create a mod with a small game state footprint and then use that game as a test case for mid-game-join, resync and rejoin-after-disconnect code. A small game state in memory footprint makes it feasible to create a brute force solution which is focused on getting the job done at all by using simplistic, non complex code that require smaller changes to the spring engine and thus is less likely to mess up the source code of it.

Ok, just my $0.02. Thanks for a great game! (...or rather, thanks for a great engine with great mods :) )

[PhailQuail]

I would not mind having to wait a few minutes if someone drops from a very fun game. Provided this person does not do so often.