How will multiplayer servers be handled?

I'm still not sure to grasp how all this will work.

I guess that uber will provide some servers for hosting games in their lobby. But that will require some insane bandwidth and CPU power, that's not free and I doubt that a relatively small project like PA has the shoulders to support this for long.

So the second option is third party server, but it's the same : Cost a lot for hosting a correct amount of games.

So the third solution is making one guy as the server for each game. I can't imagine that it can be otherwise.

From a client point of view, not really a problem : you only send the commands, that's not a lot of bandwidth.

But from a server point of view.. Sending the sim differential to each client for every tick ? That's an insane amount of bandwidth for a 4vs4, isn't it ?
Let's say 0.1Mbps for a player, .7Mbps for the whole game, almost nobody in my country can do that
Remember how 4v4 is difficult in supreme commander bandwidth-wise ? You are only sending the *commands* you are doing to every other player. Not the position of every unit, every projectile, and their stat.

And PA is aiming for more, not a lot of people will be able to support that.

Also, what decide who is the server ? some pre-test ? It's directly the guy hosting ? What if nobody/that guy has the necessary requirement ? I fear that a lot of game can be ruined easily like this.

And, another concern : what if the host decide to leave the game (because, why not ?) ?
In 1v1, what can avoid the host, if he is losing, to just close the game ?

I'm really worry about the short term viability of the multiplayer of PA. Please reassure me

Supcom1, with its thousands of units only really hit 0.05 Mbit per player. I can't imagine bandwidth being a problem.

How is it done in SMNC?

don't know the supcom model, but judging from neutrinos posts on their client server model (large part of the simulation server side -> more information transfer than usual with halfway distributed simulation), the network seems to be the stronger bottleneck than CPU/RAM, at least if you want to host a server locally.

Because you only send your command to all players.

So in this case, not only the server have to send ALL players commands to all players, but also the state of the simulation (position, heath, projectiles,....).

Taking Supcom as example is a bit extreme as it's not think as a client/server protocol, but take a skirmish vs AI game, save it, look at the size of the resulting file. That's the amount of datas that would the server need to send to all players for that game duration.

In the case of SMNC (or any FPS), it's only the position & stats of, at worst, 64 players, and the ballistic is often computed by each client.

If the clients are doing no simulations and it's the position/configuration/build queue of loads of units once per frame, then yes I can see it being pretty bandwidth intensive. Will be interested to see how many players per game will be feasible.

That's what I've understood from their livecast, but I don't think it's doable entirely. Maybe SOME of the computation will be done by the server, but all of it, I don't see that happening.

Still, I would like to have some enlightenment about all this

I've described this in more detail elsewhere but yes the server does all of the work other than the rendering.

In a typical synchronous games each client replicates all of the work that a server would do in our case.

I wonder how much optimizations Uber (propably you, neutrino?!) can come up with here. Only sending changes in the worldstate to the clients should be obvious, but neutrino wrote something about the whole game-sim being designed as a kind of function, where you can just insert a timevalue and you get the gamestate at that time. So you could also jump around in a replay if it works out perfectly.
I would love to read Uber's findings about the implementation of this idea, since it sounds like it is pretty awesome but hard to do.

in other terms, the scaling from a small 1vs1 to a huge n vs. n game depends almost entirely on the strength of the server and its connection to the network, since the clients itself should have to render almost the same information independent from the overall size of the game (there is an upper limit to the number of units and other stuff you can squeeze on one screen at a time)

How it plays out in practical tests has to be seen, but the theory behind the model I like.
In a LAN setting with almost always a diverse mix of how "current" the players hardware is, the synchronous model made the slowest of the PCs the bottleneck with synch/connection problems, because it couldn't keep up. On the other hand, often enough a free pc would be at hand to run a dedicated server.

But what if the "server" leave the game (and close the server ?) or simply have a connection problem ?

then your game is gone
but that's the same with any kind of game which has a server of some sort (even if it is run as part of the game client from one of the players)

save games and replays were discussed before, they would a possible way to restart at the last stored checkpoint.

Yes, but we are talking of, most probably, server==host==player. I can see problems only that.
Unless you are playing only with friends, you can be sure that the host will leave as soon as it start losing to avoid the loss (in 1v1 or teamgame, doesn't matter). That's how people are.

On FAF, on peak time, about 50 concurrents games are running, with 400 players in these.
I can NEVER imagine paying for enough servers for holding that. And we are talking of "only" 500-600 users online.

The case of server==player I would sort in under LAN play, otherwise you would have to put safeguards in to ensure "you leave=>you loose".
It depends a bit on how many official or private public servers there will be and how the demand looks like, something not easy to do here and now.

PS: in a 1vs1 players would probably avoid being the host for the possible drain on their system resources (except for the chance of a kill switch ).

Well that will probably result in the same problem you have with all servers that go down: All clients lose the connection and that's it. End of the game.

Sure if a player is the host and he leaves he kills the game for everyone. But I cant see a problem with that. That's working in other games, too. People are not that bad. Either they host and stay or they are client and leave.

The issue I see is in a 2v2 (or ffa or whatever) where the host dies first. Is he stuck watching until the game is over? He can't play another game until everyone else is done? Wouldn't this be a big detriment to being the host?

The answer to a lot of this is "it depends". I honestly don't have time to write a huge tome about it right now but we have a ton of experience running servers now and an infrastructure to do it. If we had to run all of the servers this wouldn't necessarily be an issue for us.

The reason for allowing 3rd parties to run servers is because they've asked for this feature. The average user isn't going to have the kind of upstream bandwidth you need to run a LARGE game. However, running on a LAN is a whole different story so we need to support flexibility here.

So we have:
- Public servers that Uber runs
- private servers that can publish into the public list or stay private
- other types of servers for tournaments, galactic war and potentially clans

In the case of the "average" player you won't be hosting a server unless you are just playing single player or playing on a LAN. Those of you with extra machines and bandwidth can run public servers with custom mods and rule sets etc.

Also keep in mind you can easily rent or buy co-located servers down to the hour if you want to. Those typically have 100MB internet connections (it's what we use).

And yes, one server box can technically run multiple games.

Thank you, that answers my question perfectly

How many players will a server be able to host? And will it be jump in? Like most FPS games?

When it comes to jump in, would it be possible to have some sort of premade "planet" that you have. That kinda just flies in and takes position into sun orbit. Sorta like a savegame, but you dont have to start fresh in an already ongoing game.

Big multi-player games will need to be able to save the state of the game. :?

Then have the players be able to re-sync into the saved game later.

So, doesn't it make sense that all multi-player games will need to be on a separate server application only? :idea:
That will partly solve the problem with hosts cutting out of the game, because the server will just keep running.



//Hoping for cross platform play! :shock:

Pretty much this. If you want to host big battles the easiest way to go is renting or buying a professional server.
Renting a server doesn't cost you an arm and a leg. I don't know the circumstances in the US but in europe rented servers are cheap. Split the montly cost between your friends/team/clan and the costs for each individual gets really low. 5$ a month to play huge, awesome and lagfree battles shouldn't hurt that much.
If you're going for a dedicated host (plain machine, free to install what you like) you can even host other things as well if you like. No reason to stick to PA if you're tired of it.
Want to play Garry's Mod? Go for it! Need Teamspeak/Mumble...? You get the point.

I got a server myself for 40€/Month (clanserver, paid by me) the freedom to host everything you want, when you want makes it worth.