What would really make a difference: the client-server model

[dannysquid]

Regardless of the networking system, the larger problem is that interesting storytelling doesn't go naturally with a galaxy-sized procedurally-generated multiplayer environment where everybody's stuck in a spaceship. It's just a huge design problem that isn't easily fixed. You kind of need procedural storytelling that works in multiplayer. Which is easier to imagine lying in the bath than it is to actually design and code.

FWIW, I think if/when we get "space legs" a much more interesting variety of missions will spring up and it will become less of an issue. There are only so many interesting interactions you can have when you're limited to being in a spaceship.

 

[Chris Simon]

Regardless of the networking system, the larger problem is that interesting storytelling doesn't go naturally with a galaxy-sized procedurally-generated multiplayer environment where everybody's stuck in a spaceship. It's just a huge design problem that isn't easily fixed. You kind of need procedural storytelling that works in multiplayer. Which is easier to imagine lying in the bath than it is to actually design and code.

FWIW, I think if/when we get "space legs" a much more interesting variety of missions will spring up and it will become less of an issue. There are only so many interesting interactions you can have when you're limited to being in a spaceship.

I hope you're not holding your breath.

 

[Riverside]

Do you reckon there is a chance that they'll ever consider it?

I see this suggestion come up regularly in various CLogging threads and every time I think to myself that this would be a lot of work. However I don't recall a comment from FDev actually stating it would be difficult, and it may be do-able for certain instances in highly trafficked areas to be assigned to a dedicated server rather than relying on a player to host it.

Potentially this could allow the majority of the game to continue with the peer to peer mechanism while enabling huge persistent instances for certain events or locations.

 

[Bortas]

How would that be helped in any way?

If a central server existed, it could keep disconnected ships in the instance, just like it's done in every other MMO with a client-server infrastructure.

 

[sollisb]

In any large scale development endevour;

Effort vs Risk vs Reward

The effort would be huge. They'd need to relearn and recode and redesign.

The Risk would be immense; No guarantee, to generate extra income. Elite Dangerous would die over night if it went subscription based.

The Reward is minimal at best.

Elite Dangerous right now, while I contest, is shallow, and monotonous, it is; a graphically amazing piece of work. It gets by on the extra paint packs and other stuff. There is no commercial advantage to changing something that is in the main, working. And I'll be honest, if standard game releases are bug filled messes, what would a re-engineered network look like?

 

[Brrokk]

It would indeed make a difference. It would cause great diversion of effort and development in all other areas to cease while it was sorted out, which would be a disaster.

 

[imski]

Time dilation doesn't really fit with a twitch based flight model does it?

 

[MarkAusten]

If a central server existed, it could keep disconnected ships in the instance, just like it's done in every other MMO with a client-server infrastructure.

That still would not help with the main problem of combat logging and that is intention. Did the connection fail or was the plug pulled? It's the intention of the player that make the difference and there is just no way to determine that whether the system be peer to peer or client server.

As for keeping the disconnected ships in the instance all that is going to do is cause a lot of people to complain when a legitimate connection disconnect results in their ship being destroyed in the instance when they have no control of it. Added to which you then have the problem of reconnecting to the same instance, and there will be many of them client server or not, in order to get back to their ship. Further adding to the complication is that by its very nature, the Internet is a disconnected system. You may think you are connected to the servers and to other players but I can assure you, that is all smoke and mirrors. It is also why there is a long timeout to determine whether or not the client has terminated the session or not and you cannot stand a timeout of 30 seconds, the usual delay, in such a game. It would cause havoc. Client server architecture will not solve this either.

Realistically, client server would probably cause more problems than it solves and for what is a relatively minor problem despite the vociferous posting.

 

[Schlack]

I'd like a model where Frontier provides servers which can be rented by groups of players who can then set their own policies on those.

Id like my own personal BGS too!

 

[Bortas]

That still would not help with the main problem of combat logging and that is intention. Did the connection fail or was the plug pulled?
It's the intention of the player that make the difference and there is just no way to determine that whether the system be peer to peer or client server.

Doesn't matter. If your connection is lost, your ships/character stays in the instance, until you reconnect or are killed. Works like this in virtually every MMO with PvP, and even in PvE.

As for keeping the disconnected ships in the instance all that is going to do is cause a lot of people to complain when a legitimate connection disconnect results in their ship being destroyed

Sure, it hurts, but it's just bad luck then. Players usually accept it and get over it for the sake of fair play, though. ED is an example for what happens if disconnecting has no consequences... cheaters' paradise.

 

[zinzaemon]

yep exactly what Bortas said.
Only no need to call it combat logging, just be a regular disconnect regardless of intent. PCombat logs would stop pretty quick I feel..

As for logging back in there is only one big instance so no worries.

 

[MarkAusten]

Doesn't matter. If your connection is lost, your ships/character stays in the instance, until you reconnect or are killed. Works like this in virtually every MMO with PvP, and even in PvE.



Sure, it hurts, but it's just bad luck then. Players usually accept it and get over it for the sake of fair play, though. ED is an example for what happens if disconnecting has no consequences... cheaters' paradise.

So, I repeat your own words to you. Combat logging? "Sure, it hurts, but it's just bad luck then.".

Get over it, it's a small problem. The problem with combat logging is that a small vocal minority of people just can't get over it and let it go.

Client server architecture won't solve the problem it will just turn it into a different, bigger problem. That's not a solution.

 

[nosleepdemon]

The cons to p2p architecture are legion for anything that requires authority, such as video games, where decisions made by the engine must be agreed upon by all participants. One thing p2p offers over client server is in the cost to operate department, this is probably the primary reason for FD's choice of this type of networking model. There's also the issue of simulating a game with 6 degrees of freedom with multiple actors over astronomical distances, again p2p would help in this circumstance where the number of concurrent users is huge, but the number of users each other user can potentially see is relatively small. I've not known games that use p2p to have a persistent world, but that's just from my experience. The big issue with that, imo, is rather philosophical: if a tree falls in a forest and nobody is there to hear it, does it make a sound? In p2p, where do the npcs go when nobody is there to witness them? With a server thrown in there it's easier - you drop that npc into some sort of sinulation state where they are not durectly modelled in the game world, but still exist with some sort of reduced function. But how do you do that with p2p? You are dealing with not only handing the real time simulation of a particular npc over to whatever player is nearest to them if someone else quits, but then you are also handing that npc over to some, presumably very light, persistence application on the server. Either that, or you keep track of their state in a database and if that npc spawns again, they keep their last known configuration plus a few changes applied to them depending on time elapsed since their last spawn. E.g. Allowing them to repair, rearm etc. Again, that is huuuugely complicated.

 

[sb413197]

If this game were all in open that would be a necessity. But most players are solo, making it a huge undertaking and continuing expense, for relatively little payout.

 

[MarkAusten]

The cons to p2p architecture are legion for anything that requires authority, such as video games, where decisions made by the engine must be agreed upon by all participants. One thing p2p offers over client server is in the cost to operate department, this is probably the primary reason for FD's choice of this type of networking model. There's also the issue of simulating a game with 6 degrees of freedom with multiple actors over astronomical distances, again p2p would help in this circumstance where the number of concurrent users is huge, but the number of users each other user can potentially see is relatively small. I've not known games that use p2p to have a persistent world, but that's just from my experience. The big issue with that, imo, is rather philosophical: if a tree falls in a forest and nobody is there to hear it, does it make a sound? In p2p, where do the npcs go when nobody is there to witness them? With a server thrown in there it's easier - you drop that npc into some sort of sinulation state where they are not durectly modelled in the game world, but still exist with some sort of reduced function. But how do you do that with p2p? You are dealing with not only handing the real time simulation of a particular npc over to whatever player is nearest to them if someone else quits, but then you are also handing that npc over to some, presumably very light, persistence application on the server. Either that, or you keep track of their state in a database and if that npc spawns again, they keep their last known configuration plus a few changes applied to them depending on time elapsed since their last spawn. E.g. Allowing them to repair, rearm etc. Again, that is huuuugely complicated.

There is a great deal of client server architecture in Elite just not the bit that involves other players. Sessions between players are carried out using peer to peer networking but otherwise the interactions with the game are client server. FDev gave a presentation on this that is available in the Internet somewhere. I don't have the link, perhaps someone would be kind enough to post it. It is very interesting although you do need a fair bit (read: a lot) of IT technical knowledge and understanding to be able to understand the presentation. It is, however, very interesting.

There is also the advantage of peer to peer networking in Elite that uses a very complex algorithm in the matchmaking servers to try and match the players in any one instance so that, for example, they all have the same latency. This is not something that is possible using the client server model especially if there is only one instance.

 

[nosleepdemon]

There is a great deal of client server architecture in Elite just not the bit that involves other players. Sessions between players are carried out using peer to peer networking but otherwise the interactions with the game are client server. FDev gave a presentation on this that is available in the Internet somewhere. I don't have the link, perhaps someone would be kind enough to post it. It is very interesting although you do need a fair bit (read: a lot) of IT technical knowledge and understanding to be able to understand the presentation. It is, however, very interesting.

There is also the advantage of peer to peer networking in Elite that uses a very complex algorithm in the matchmaking servers to try and match the players in any one instance so that, for example, they all have the same latency. This is not something that is possible using the client server model especially if there is only one instance.

Oh brilliant, I will see if I can find it. I do recall DB saying they had put a lot of work into the networking aspect of the game.

 

[Crank Larson]

Doesn't matter. If your connection is lost, your ships/character stays in the instance, until you reconnect or are killed. Works like this in virtually every MMO with PvP, and even in PvE.

This doesn't require a client/server model. In an instance, one of the machines is essentially designated the server anyway. The E: D architecture does not prevent these things being implemented, other decisions do.

 

[govny]

and the water is wet.
client-server model cost a lot of money to mantain. Maybe you could tell us how FD would cover the cost of such an infrastructure.

 

[Arthur Shappey]

Subscription is the only really viable way. But they've already taken the license fee off of all of us - so a bit late.

 

[Janichsan]

Hang on are you actually suggesting they use the profit from another successful game to support spending more money on ED to go client server? It wasn't long ago I was reading a thread complaining because money being made on ED was being spent on developing other titles. Each title needs to stand as a successful product in itself.

Even if this is pretty off-topic for this thread: I'm not sure if you are being facetious or not, but this is not how run a successful business.