I figured this required it's own topic for dicussion because frankly I find it to be super awesome interesting and could lead to all kinds of neat clan or friends things that could be done. This also ties in nicely with the "2 Players 1 Army" type, or as clarified by Neutrino; You could join a game to help a friend in need! xD Mike
Holy damnit christmas. Imagine how epic that could get at a massive lan party like the one that guy from Ctrl+Alt+Del runs.
While it seems a given, it hasn't been explicitely stated. I assume that this would include resource pools?
Will the midgame rejoin be fairly instant? I ask this because my experience with rejoin comes from Zero-K which is synchronous so the joiner has to re-simulate the entire battle. They can do this reasonably quickly (depending on your hardware) but on average it takes about 4 minutes to rejoin a game which is half an hour long. How does this work in 1v1 and player dropping? As in will players be able to drop and rejoin without losing? What if they never rejoin?
Sounds cool! But I guess if someone drops out, that spot will be reserved for him for a period of time right? I mean, it would be very frustrating if you dropped out, tried to reconnect and some guy has taken your spot..
PA isn't synchronous, it's client based, so there might be a slight "loading" time to establish the connect and making sure it has all the right info and such but I wouldn't assume it'd take too long. Well in a 1v1 unless there was some kind of waiting period to see if the player reconnected I'd think it just be if they disconnected they 'lose', but depends if you're talking about ranked 1v1 or custom 1v1. I'd assume Custom could be more flexible. Mike
I'm just worried this over-excitement adding new bullet point features day in and out might be too audacious for the budget?
Well think of it this way, they aren't so much 100% new features as much as different facets of PA's client-based Online thingy. Mike
OrangeKnight is right. Multiplayer save, joining a game in progress, reconnecting to an existing game, etc are all facets of the client/server implementation of the game. Documenting all of these features allows the dev team to understand what we want in advance, and to choose the right abstract implementation that will enable entire groups of features. Another example is unit sharing, unit giving and having multiple players control the same "player". They are all specific implementations of unit sharing, and can be implemented easily once the high-level feature is done.
This is also stuff that is "behind the scenes" and not outright content that we'd see as much as use, so it helps build the foundation of the game. I would much rather the foundation, the backbone, of the game be in place and solid before I worry about running out of content. I've said that about other games as well, but those other games were also locked down and weren't capable of being modded...where this one the intent from the get-go to allow the community to come and help build up content. All that said, this is very powerful feature, and the more I hear about where they want to go the more excited I get about what we can do. This reminds me of the server structure for Freelancer. Though that game was open-ended, and the server more persistent than a single RTS game...the ideas that come into mind for long-term persistent super-systems on a home-built super-computer could create some really interesting long-term. Almost like a mini-MMO, but with much more direction and guidance.
Please note he said "YES" to the FEASIBILITY of the feature. But I think they should put it in. Client-server architecture gives you soooo many options. I had exactly these considerations 15 years ago in my over-ambitious amateur RTS project (that never flew, for obvious reasons). Nowadays, with servers being little more than a click in a web interface to add more instances, and crowd funding, and rendering power on desktops out the wazoo... these truly are the golden days.
Pretty much this. Part of the reason we went client/server is that a lot of this stuff just "falls out" of the equation. Believe it or not unit sharing was implemented in some other engines I've worked on but never got exposed in the UI.
How are they going to work this into game balance? Maybe an in-game voting system, "player X wants to join team 1. Yes or No." Or would it have to allow a player to join in on each side all at once? This would be extremely cool if it worked out properly, but I just don't see how it would be implemented .
