By the time ED ends, (hopefully) your home PC will have the capacity to continue running the BGS and Galaxy, either in solo or group mode.
.
It's not the question about capacity or performance. It's about effort and responsbility.
.
If in 10 or 15 years FD doesn't operate the BGS any more, how much effort will they still invest to give us a a working implementation of the BGS? It's much easier and cheaper to disconnect it from the game and let it run on "default values".
.
In contrast, if they go ahead and give us the necessary files to set up a working BGS, it also won't be the same. In this scenario you'll end up with many people having their own BGS running, some of them manipulated for their own purposes. (Not necessarily bad purposes, mind you. A lot of them might just bend and manipulate it to match their own roleplay and story telling. )
.
So you won't have one galaxy and one BGS any more, but many different variants of the galaxy. Which isn't bad, but definitely not the same.
.
I think you fail to grasp both "easily" as well as the role of a "host" in a P2P system.
I don't know the precise details of the Elite implementation, of course, but generally speaking in a P2 game, a Host simply coordinates and arbitrates the remaining nodes. Precisely what it does varies in each implementation. For example, in more traditional games where the Host has control of the instance, the Host player can manage the other players (invite, accept, reject, boot, etc).
But the actual P2P traffic still goes from each client to each client; it doesn't all get routed through the Host as per a Client-Server system. And this means that it only takes a single "bad" node to significantly impact the instance.
.
Uh... man. I can't raise my eyebrows as far as would be appropriate. They'd hit the back of my neck...
.
Let's first cover the last part: you are right that it goes from client to client. But the clients are not "nodes". It's always direct connections from client to client. Routing issues are the very same as for other internet connections. So would what you describe actually be true, it would only be single clients which have issues.
.
Unfortunately that's not really true for ED. We know that the game actually set up "hosts" internally, although they use different nomenclature. We don't know all the details there, but according to all we know by playing around (PGs, firewall settings, etc. ) the rough outline looks like this:
- Missions still come from FDs centralized mission server. That's actually client/server and nothing else.
- All BGS information also is provided by FD. It again, when seen on the most basic level, is client/server. Mind you, there is much more about it, as it's actually a distributed structure and quite complex, but it follows the client/server logic.
- Login data and player files also come from FD. See BGS.
.
So up to now, we're still far purely in client/server land. Now we go for the P2P section:.
- The game seems to evaluate clients, their computer and their connection. When several people of the same region are in the same system, the one with the "best rating" is declared to be the "master", where the rest are "slaves" to.
- The information about which system will be "master" or "slave" again still comes from FDs infrastructure and thus is in client/server country. But it manages the P2P part of the game.
- NPCs are created and managed by the "master". Only if a "slave" looses connection, it starts managing its NPCs itself again.
- Every client still is responsible for the own ship movement position and damage management. They communicate the results among each other, but manage it individually.
.
And that's why I say that client/server really wouldn't be that much of a change on a basic level. One client already now always is the "master". Which means it already now in several (but not all) aspects already now does the job of a server. You mention features like invite, accept, reject, boot, etc. which indeed are not present. But they are features, not defining criteria for a client/server infrastructure.
.
What's really missing would be:
- Movement plausibility checks and correction on master/server side.
- All damage management done on master/server side.
- The server being disconnected from being a game client and running standalone.
- A complete rework of the distribution logic running on FDs servers.
.
It's the last one, which would be the one big thing. It would have to turn the complete logic around. Instead of distributing based on location (both in game and in RL) and then trying to match according to secondary criteria, it would have to manage server instances, assign them the in-game location and then distribute clients accordingly.
.
I mean, similar things have already happened, even without being designed into, to other P2P systems.
.
Somebody here remembers the classical honeypots in Emule and the likes? That were just nodes set up at advantageous conditions and modified to best performance. This gave them so high performance and thus so advantageous rating that they for a while operated as de-facto servers. They were run by intellectual rights owners and the collected data allowed them to du a lot of suing and cashing in.
.
For FD the effort would, as already explained, be significally higher. But generally speaking, a conversion of P2P to client/server can be done with acceptable effort, while trying to convert a client/server system to P2P usually requires a completely new implementation.
.
Of course, all of this is pure theory. All I wrote is oversimplified and none would be optimized yet. There's a boatload of extra work to be done to get it to run smooth. I am fully aware of that. While ED is a good example of a "P2P" structure, which actually could be switched to a client/server model with comparatively limited effort, it would still be a lot of effort which are better invested elsewhere. And that's before talking about costs and who would pay for it.
.