Suggestion: allow queueing for public games?

[tony_statman]

I know you've mentioned that it would be difficult/impossible to allow players to join mid-game; but would it be possible to make it so that a player could click on a public game, and then there be a little icon by the game [to show that the person will be added], and then have that player automatically added when the mission is complete? I don't mind waiting a few minutes for a game, but I don't like to have to constantly be watching the "server" list just so that I can hit join at the right time ... if I wanted that kind of time-intensive stress, I could bid for stuff on ebay :)

[nornware]

I'm really quite torn on how to proceed with multiplayer, and spent a few hours wandering around in the woods yesterday thinking about all the options / trade-offs / implications.

The main fork in the road (pun intended) is whether or not to switch to a Client-Server architecture (the game is currently Peer to Peer). I'm going to write out my thoughts on this not least to sum it up for myself. I apologize if this gets ranty, technical, or speculative.

Client-Server Pros

• Scales better for more players, and is probably required to be able to go beyond 4 players at all due to bandwidth concerns.
  
• Technically would allow for players to drop in and out of games at any time.
  
• Spectator mode could be supported.

Client-Server Cons

• Adding more players has huge negative implications for user interface screens, split-screen layout, as well as pure physical space in the airlock.
  
• The potential for replays of networked games is lost. This is something that is currently possible and I think would be fun to have.
  
• Calculations indicate that this would be more bandwidth intensive than the current P2P implementation for 4 players, but would probably scale better for more players.
  
• Estimations show that bandwidth usage increases significantly for large maps with many Cores, Doors, Sentries. Large Beast / Creep populations have the same effect, regardless of map size.
  
• One of the players needs to host the game / act as the server, and the bandwidth load would be significantly higher for this machine. The load is currently balanced in P2P.
  
• BIGGEST RISK: There is no way to know how this approach would feel when playing international games without actually going ahead and implementing it. I expect that if the second-to-second gameplay feels worse than the current P2P version, people will call "regression" and be upset. This will also take quite a bit of time.

Peer-2-Peer Pros

• BIG INVESTMENT: The second-to-second gameplay actually works internationally. This took a lot of time to get right and is something that I'd rather not mess with, especially if a vanilla Client-Server implementation feels worse.
  
• The network load is equal for all players, for all maps, and for all Beast and Creep populations since the only thing being sent is player input. This is a very big plus.
  
• Replays of networked games is possible (not implemented currently) but I think it would be fun to have.

Peer-2-Peer Cons

• We are pretty much bandwidth limited to 4 players. This might be a blessing in disguise, because I'd rather avoid trying to sort out user interface layout, split-screen stuff for more players, as well as redesigning the airlock for more physical player space.
  
• Players cannot currently join games that are in-mission. This may be fixable, but most likely you would only be able to get into the pre-mission screen and would have to wait for current mission to end (as the suggestion in this thread calls "queuing").
  
• The mission must currently end when a player leaves the mission. This may be fixable.

All of the above assumes changing the current flow of the game (parties, pre-mission screens, etc) as little as possible.

Looking at it now it seems like the best way to attack this is to try to fix the joining / leaving issues listed under Peer-2-Peer Cons, very much along the lines of the original suggestion in this thread. This entails the fewest technical risks as well as leaving most everything intact.

Speculative Crazy Hybrid Approach To Solve the Drop-in / Drop-out Issues
I would prefer, both from a risk mitigation perspective as well as considering the functionality gained, to stick to the current P2P implementation but still allow free drop-in / drop-out of the game at any time (including joining and leaving in-mission).

• Reinforcements (new players) could arrive at the airlock at any time while a mission was running.
  
• Players could join as spectators at any time.
  
• The premise would still be a 4 player limit, but again this plays nice with gui layout / split-screen / airlock space issues.
  
• We could still have replays for all matches (local or networked).

Really thinking about this it seems to me that the game might be very close technically to supporting this already, but I'm not exactly clear on how it would affect loading times and bandwidth usage. The work that needs to be done to properly support replays might just supply this functionality basically for free; I need to keep complete logs of all player input for the entire mission, and this is exactly what a player who is joining the game needs to be able to sync up and start playing or starting watching as a passive spectator.

Replays / support for drop-in will cost an increasing amount of memory, but estimations land at under 5MB for a 20 minute match. On disk this can be severely compressed, so it shouldn't be a problem to store many replays for your later viewing pleasure.

It this works then I think the major issues with multiplayer will be solved (robustness of join / leave), but we'll have to stick to 4 players. As I keep repeating however, the implications of adding more players go far beyond simple network bandwidth issues.

This post has been very reflective, but I think the hybrid approach is feeling like an interesting trade-off for me. It certainly isn't any more crazy technically than the current (second) Peer 2 Peer implementation and all the prediction / re-simulation stuff that is going on, and that is really what got this game working across international connections.

[tony_statman]

Thank you for your thoughts. I think the hybrid approach, as you suggest, might have the biggest benefit for the lowest risk, and while being able drop in as reinforcements would be excellent, I personally would be content just to be able to spectate on a public game with fewer than 4 players while I wait to be added automatically after their mission was over; and if I saw all public games were 4/4, I'd be happy to start a game, knowing that I wasn't missing out on being able to join a group.

The frustrating part right now is wanting to play, but then just staring at the server screen at games with 2/4: do I stare at the screen, hoping to click in as soon as their mission is over, without knowing how far they have to go? Or do I start my own public game, and then wait for others to join? Allowing spectating would solve that dilemma: I could either watch others while waiting, which would pass the time while waiting, or I could start a game knowing that anyone who wanted to join could join in a matter of minutes. That way, I'm not stuck at staring at "public, 2/4, in mission" :)

[nornware]

Spectate vs Reinforce is really a game design choice, and probably an interesting thing to leave as a map option for the hosting player.

I have definitely learned a lot during the development of this game in terms of user experience, and completely agree that the whole "not knowing" aspect is detrimental to the experience as a whole. In general I really want to make things more robust.

[tony_statman]

if you allow reinforcements, please just keep track of the names of the fallen; I think it might be crazy hilarious to do an "insane" map, and see how many human bodies have to be thrown at it before the mission is complete, or before all four humans are killed before a reinforcement can arrive :)

[nornware]

I actually wasn't thinking of allowing for player re-spawn, but that is of course possible.

I'm not sure that it's a priority, because tracking all the dead characters in a specific mission would be a change from how things work not (currently all dead just go into the singular list), and it would be messy to try to display stats for all the dead players in the post mission screen.

[tony_statman]

No worries; I just think it would be funny to keep track of many died trying to beat "maze, insane". Most hilarious (to me, in a morbid way) would be a screen full of names of the -- 30? 100? -- Marines who gave their life. And I wasn't suggesting showing their stats, just their names, to give a sense of the number of fallen. :) But even a counter that said "16 Marines gave their life to complete this mission" would be interesting (and actually might be a valuable metric to keep track of, to quantify how difficult certain parameters are :) )

But keeping track of number dead is a low priority, it would just be out of morbid curioisity. :)

[nornware]

:)

[tony_statman]

In a way, adding unlimited respawns for humans creates a new gameplay mode, "Unlimited Warfare" -- just keep going until the mission is complete. For added cruelty, make it so that the airlock is destroyable, and if the airlock is destroyed, no more human reinforcements; that would be one way to FORCE an eventual end to the game.

The way I imagine gameplay on "insane" would be: Marines advance, set up turrets, die ... Marines advance further, backed by turrets, make progress on downloading cores, die ... Marines start pushing further but supply lines get thin because turrets run out, ammo stores run dry ... Beasts press forward, Marines try to defend the airlock ... Beasts get into airlock. And now we see the names of the 37 fallen Marines who gave their lives trying to download data from the USS Medusa ...

[Toumal]

I'd like to add some points to your pros/cons list.

P2P cons:

x) The performance of all peers depends on the performance of the worst peer.
x) Each added peer adds exponentially growing bandwidth use for *every* peer.
x) You can't have consistency and hot join + leave capabilities

CS pros:

x) Each added client adds much less overhead compared to P2P (albeit not a linear progression either... but can be close)
x) Hotjoin is easy (Send a snapshot on connect)
x) Hotleave is easy (Just disconnect, doesn't break consistency)
x) Much simpler to work with (single point of truth, no need to distribute entity ownership, etc)

The guys at Parallax went through much the same phases you do right now when they wrote Descent. It's funny how everyone's solving the same problems, albeit sometimes in slightly different ways.

The decision is yours really. My only plea to you is to not try and implement hot joining in P2P. It's a huge mess. C/S requires more upstream bandwidth on the server, but it's definitely easier to develop.

I actually like stuff like Photon, where you can have dynamically hosted client/server for your application in the cloud. To the client it works just like peer to peer (start a game and you have a server, no need for port forwarding, no need for dedicated servers, etc.)
Of course it costs money, and if photon is ever down, there's no multiplayer.

For a small game like this, client/server can be a blessing too: You can host a small number of "official" servers for very cheap, yet you also get the more organized gaming folks involved because they like to set up and operate their own servers.

[nornware]

Toumal:

Client-Server is only easier to work with if you can fit the entire state snapshot in a single datagram. This doesn't work for SBTF.