STORE COMMUNITY ABOUT SUPPORT
login | language
简体中文 (Simplified Chinese) 繁體中文 (Traditional Chinese) 日本語 (Japanese) 한국어 (Korean) ไทย (Thai) Български (Bulgarian) Čeština (Czech) Dansk (Danish) Deutsch (German) Español - España (Spanish - Spain) Español - Latinoamérica (Spanish - Latin America) Ελληνικά (Greek) Français (French) Italiano (Italian) Magyar (Hungarian) Nederlands (Dutch) Norsk (Norwegian) Polski (Polish) Português (Portuguese - Portugal) Português - Brasil (Portuguese - Brazil) Română (Romanian) Русский (Russian) Suomi (Finnish) Svenska (Swedish) Türkçe (Turkish) Tiếng Việt (Vietnamese) Українська (Ukrainian) Report a translation problem
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.
- 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.
- 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.
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).
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.
- 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).
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.
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" :)
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.
But keeping track of number dead is a low priority, it would just be out of morbid curioisity. :)
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 ...
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
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.
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.