[testing] Allow to join matches (faction controlled by AI when no player)

[MirceaKitsune]

MegaGlest got some big improvements in regards to playing online compared to Glest. But there's still a major problem with internet matches; You have to join while everyone is getting ready, and cannot enter an ongoing match. This makes it difficult to find a game, since everyone spends little time in the lobby setting up a game and more time actually playing.

In most FPS games, online matches are free to join at any time. Also, if there are less than two players fighting on a map, a bot can be added so the player doesn't get bored while waiting for someone else to join. I'm thinking of something similar for Glest in this sense.

My idea is to create an optional server flag which allows players to join at any time during an ongoing match. When enabled, player slots which are set to Network but no one is occupying when the game starts will be taken by a CPU, and an AI plays that faction. Then, if anytime during the game a player wishes to join, he can select the server in the server list and take a free player slot if any is available. Once that player is connected, the faction is switched to him from AI control. If he disconnects, it's then switched back to an AI (already happens by default). Although new players would inherit what the AI or other players built before them (which is not most fair), it would fix people having to wait for a new match each time.

This would go nicely with another feature, also seen commonly in FPS and other genres. An admin can leave the server running, and after a match is over it automatically selects a new map and starts a new game. It doesn't care if anyone has joined or not, and until a real player connects it can let AI factions battle each other. Such would allow people to run servers with full uptime which anyone can join at any given moment. This is a different feature from the one I mentioned above though, and can be done separately.

[softcoder]

We have the code to be able to do this, however its not yet implemented and I have some questions about how this should work?

1. Does the player request to join the current game and the main host user get notified and then answer yes / no? How do we avoid spamming requests from annoying players?
2. How do we decide which player slot the connecting player joins into?

We would have to pause all players while the new player joins, would it be ok to just put a message in the char area indicating this?

[Omega]

This is how I would do it: if there are any open "network" slots, clicking the "start game" button would prompt the user if they want to start with AIs controlling the empty network slots. Clicking no returns the user to the custom game screen, while clicking yes would prompt the user to choose the AI setting (easy, normal, ultra, mega). For simplicity, probably best to use the same AI setting for all these network-AIs.

Anyway, the game would play as normal with the AIs until a user tries to join the game. For this person joining the game, they'd see the game on the master server as usual and would get the same custom game screen, but none of the options would be changeable (so basically just a preview of the game's settings). The only thing they can do on this screen is choose a player to take control of. Choosing one of these will make main host get a message that this player wants to join the specified player's slot (and should state the faction and team). If it's reasonably possible, this prompt should pause the game (for all players) and it should be possible for the players to chat amongst themselves while the prompt is still up, allowing them to discuss if they should let the player join. If also possible, their chat (provided it's set to "all", not "team") should also be displayed to the joining player, allowing them to tell the joining player things like "join a different slot instead".

If the main host chooses "no" to this prompt, the joining player is not allowed in and cannot submit any more prompts for this position. However, they can choose a different slot instead. This "ban" only lasts for the single game. Presumably the existing methods of banning annoying players would still be in effect as well (though I'm unfamiliar with the workings of these).

For a very rough first implementation, it could be possible to skip the pausing and ability to talk to the joining player, although it would be much more limited.

[MightyMic]

1. Does the player request to join the current game and the main host user get notified and then answer yes / no? How do we avoid spamming requests from annoying players?
2. How do we decide which player slot the connecting player joins into?

1. I wouldn't mind if the player was just connected or if the host had to ok it.
2. My thought is to have a list of open slots showing which team and which faction each one is, allowing the player to choose one. Or if there is only one open slot, immediately put him into it.

[MirceaKitsune]

We have the code to be able to do this, however its not yet implemented and I have some questions about how this should work?

1. Does the player request to join the current game and the main host user get notified and then answer yes / no? How do we avoid spamming requests from annoying players?
2. How do we decide which player slot the connecting player joins into?

We would have to pause all players while the new player joins, would it be ok to just put a message in the char area indicating this?

My answer would very much be what Omega said. But to form my own idea:

1. I don't believe the host should have to confirm anything, but that could be a setting so the owner can decide (disabled by default though). The point is to make it as easy as possible for anyone to join and free-for-all servers to exist.

2. Let the player decide between free slots, just like the existing lobby screen (and within it). Was considering to let them change team and faction too, but that would be impossible since the AI already played that slot and such would break it.

Long version: Servers with ongoing matches already appear in the server list, so that part is good. Now when selecting one, the player would have the 'join' button available. When they join an ongoing server, they see the same lobby screen as setup servers... but all options are grayed out except for free player slots (useful so they can see match settings and know what they're joining). The player can pick one of those slots like they do during lobby mode and that's it. They then enter and play on that slot from where the AI left off. Other players (including the host) are only notified through a chat message that "Player X entered and is now playing on slot #", the same way they're already notified of players disconnecting and being switched to AI mode.

[softcoder]

I am making great progress on this. Watch for something soon to be commited to svn.

[MirceaKitsune]

I am making great progress on this. Watch for something soon to be commited to svn.

Can't wait!

[softcoder]

The initial work is now in svn to allow joining in progress games. Here is the current flow, feel free to offer feedback about how it should work:

1. Host player checks a checkbox indicating the game allows joining the game in progress
2. Host starts the game
3. Slothful player #2 decides to join the game he should have joined earlier but because he slept in he missed his chance...
4. Player 2 (for now) goes to the join game menu and enter's the IP address to connect to and clicks connect
5. The host and all other players get a chat message indicating player 2 wants to join, and they keep playing
6. Player 2 is in the game lobby and can see the game settings. He can chat with in game players and either a) disconnect or b) join the game
7. Play 2 clicks to join the game.
8. The host game is paused for all players, the game is saved to XML and sent to player 2
9. Player 2 loads the saved game
10. Player 2 now plays the game as it is unpaused

A few notes:
- We still need to hook into the internet games menu to allow for easy connecting to such games
- We still need to allow the joining player to change to other slots if any are available
- We still need to add support for join in progress games for headless server mode

Thats it, try it and offer your feedback

[MirceaKitsune]

That's fantastic, thanks for adding this great feature! Being able to choose which player slot to take when joining an ongoing game is most important next IMHO, but it's great that the base system is there and usable

[tomreyn]

I'm very much looking forward to this!

[softcoder]

Latest svn now also supports switching slots

[MirceaKitsune]

Wonderful! I shall try the latest SVN

[titi]

uh, there are many different crashes with svn now , looks like this is still work in progress

Some thoughts about the new feature:

I asume this is how it works now:
1. The server pauses the game
2. The server saves the current game
3. the saved game is send to the new client
4. new client loads game, takes slot and says "ready" to the server
5. server provides info about new player to all clients
6. server resume game.

As our current savegame feature is maybe not 100 % complete here is an idea how this can be done more error tolerant:
1. The server pauses the game
2. The server saves the current game
3. the saved game is send to all clients
4. Now all clients  and the server load this game state and say "ready" to the server
5. server provides info about new player to all clients
6. server resume game.

[tomreyn]

I also tried the current state (r4121) of the new feature to join a game in progress. I was hosting and joining a game on the same computer, using the same build. Ever since I joined and the game resumed, the joining client was lagging between 4-8  key frames (I think that's what the number in the 'n'/network display before parantheses indicates, right?).

But it was not just the lag which seemed wrong: those two players (the one hosting and the one joining in) were playing completely different games - without any error message or warning. The player who was hosting was winning on his screen, having defeated the opponent and destroyed all his structures and units. On the other hand, the client who had joined the in-process game, on his screen, also won, having defeated the opponent (the one who was hosting) and destroyed all his structures and units. Neither side detected an out of synch.

So I see the following issues here:

• With the current implementation of this feature, game states differs across server (who has the full game state) and joining clients (which load the savegame)
• Currently, savegames seem to not provide a complete / adequate representation of the game state
• Detection of out of synch does not work as reliably as you would hope for (this is not just the case here, I've experienced this before, both with and without using memory editors).

I can see how Titi's suggestion can fix the first and work around the second issue.

It would also be nice to allow joining clients to join into slots which were network slots before the game started, or which were setup as closed slots (the latter may need more discussion).

[MirceaKitsune]

Attempted to try the changes, but like it's been said there are many crashes in latest SVN when opening some menus. But I could see the new options in the menu at least

[softcoder]

The latest svn has a lot of bugs fixed, give it a try (also fixes save / load game in general which had a number of bugs)

[MirceaKitsune]

Yes, I reported the crashes on IRC too and you fixed them the same day. Also, I tested this feature with another player, and I could connect and disconnect anytime during the ongoing match, so it works nicely

He did however mention that at some point me joining the ongoing game caused an "out of sync" error and even crashed the server. It was discussed with titi_linux and he suspected that while a player connects (and the game is paused) commands are still being issued somehow, causing the game to be modified from the xml the connecting player receives or something. That's been during the same day... might have been fixed too since then.

[tomreyn]

According to my tests (just playing with myself) this should be fixed by now, too.I'm looking forward to test head of trunk with more people.

[MirceaKitsune]

According to my tests (just playing with myself) this should be fixed by now, too.I'm looking forward to test head of trunk with more people.

Going to update. Poke me on IRC later when you wanna run such a server again to test. I'm curious if you get the sync error again... if not it's probably fixed.

[softcoder]

What are the outstanding items before this feature can be marked done?

[MirceaKitsune]

What are the outstanding items before this feature can be marked done?

From what I know, it is done. Just more bug testing I imagine, but IIRC there are no more known bugs left.

[tomreyn]

While this is not a feature, there are performance issues with the current implementation (it adds 5-10 seconds software caused latency on top of network link caused latency) which make it unusable for most network games.

A feature aspect I'd like to see implemented is that a player joining an in-process game could not just replace a CPU player, but could also choose to play in a slot which, by the time the game started, was one of:

• set to "network" (but not "closed")
• set to "network" or "closed"

I guess the first option would be preferrable (but is probably harder to do).

The above performance issue and other, less serious issues, are discussed in the bugs forum.

[titi]

I would like to use this feature just to allow people to join a game where they dropped out before . Beside of testing it doesn't make a lot of sense to me to join a running game where I never was a part of.
In general I see this more as a fallback systems for people who suddenly had a small network issue or something like this.

This is  way I thing it makes sense:

1- When game starts all players get their own special key which identifies them as beeing part of the game. For example a random number for each which is then stored on the server should be good enough. This random number is given to each client where its stored too and the server ip is stored too.
2- if player drops out for whatever reason the game is paused and a message is given (mesage is already given ).  The server ( or controller on headless ) can unpause the game or theywait in this state.
3- If the player whos game crashed or whatever restarts MG ( or just goes to the internet menu ) the server is shown as open for him too ( identified by the stored ip ). Now he can join into this game identifiying himself with the key he got from the server before.

( In general the server(or controlling player)  can deny this rejoin if people always drop out because of too bad hardware or whatever )

[MirceaKitsune]

I would like to use this feature just to allow people to join a game where they dropped out before . Beside of testing it doesn't make a lot of sense to me to join a running game where I never was a part of.
In general I see this more as a fallback systems for people who suddenly had a small network issue or something like this.

This is  way I thing it makes sense:

1- When game starts all players get their own special key which identifies them as beeing part of the game. For example a random number for each which is then stored on the server should be good enough. This random number is given to each client where its stored too and the server ip is stored too.
2- if player drops out for whatever reason the game is paused and a message is given (mesage is already given ).  The server ( or controller on headless ) can unpause the game or theywait in this state.
3- If the player whos game crashed or whatever restarts MG ( or just goes to the internet menu ) the server is shown as open for him too ( identified by the stored ip ). Now he can join into this game identifiying himself with the key he got from the server before.

( In general the server(or controlling player)  can deny this rejoin if people always drop out because of too bad hardware or whatever )

Anyone playing anytime is the reason why I initially wanted the feature. While it is indeed best to play a game from start to end, there can be moments when it doesn't matter and you just want to play. It's the concept in nearly all shooter games, where 99% of them allow joining at any point. Many might find this useful in a RTS too... I know I do.

This is however also useful to reconnect when you drop. I don't believe any key identification should be added however, the current system is fine. If the server is private, people will know where and how to rejoin.

[titi]

I know and its really ok for shooters, but as you said its an RTS game and not a shooter.

Imagine the following: You start a game and play for 30 minutes, than you drop out because your internet connection had a reset. Then you want to join the game again, but the slot is already taken by someone else who was waiting in the lobby. This is not really fun ... Thats why we really need a id-key.

But if people think a free for all game where everyone can join and quit whenever he wants we can have this too ( but please NOT as default ).