Why did Fdev choose to go the way they have with the netcode?

Status
Thread Closed: Not open for further replies.
A giant server wouldn't work, combat is WAY to time sensitive for that. And it would require monthly subscriptions or pay to win.
A client-server model with up to 32 or 64 players where everyone can setup his own server wouldn't work because of the shared BGS server. It also doesn't make much sense if these 32 players are spread over the whole galaxy.
A client-server model with up to 32 or 64 players hosted by FDEV is something most people wouldn't pay for monthly. It's also way to costly for such a niche game. It also doesn't make much sense if these 32 players are spread over the whole galaxy.

It's either P2P or a fundamentally different game, there are lots of reasons for and against it.
 
Lack of experience/Know-how and most importnatly financial reasons.
Also Elite was never meant to have that many players, they didn't expect Eltie to be that successful and coded it accordingly.

What a load of tosh.

It's down to money, plain and simple.

Your other comments are both speculation and offensive.

I bash this game more than most people, but my opinions reflect choices made by FD, not just plain bashing for bashing sake.

Saying they have a lack of experience and know how when it comes to games development is extremely immature on your part.

Remember, the head of this company was the FIRST ever games developer to create a open ended game using RNG; and he fit it all into the same amount of memory as a basic text email takes up today.

I challenge you to do better.
 
As oppose to permanent servers? Please enlighten me as I'm unaware as to why they chose this, what I feel seems to be a substandard method. Is it just basically down to cash savings or is it just the only way that netcode could be implementaed for this game?

It's not necessarily a sub standard model. A client-server system can have it's own issues and could include more lag as there is a middleman to go through. They both have their strengths and weaknesses. I have to assume that Frontier decided that a Peer to peer system would be best for the game they are making.

Also with Client server systems, it would splinter the players onto different servers around the world which could drastically reduce the amount of players we see online. They way it is now, I can wing up with someone from the USA (I am in the UK), sure there is some lag, but at least I have that option.

There is a reason why when there is a server client system, that they have seperate servers scattered around the world.
 
Here a response from Frontier during the kickstarter : "The game will be played across many servers, augmented by peer-to-peer traffic for fast responses."

Yep, technically peer to peer is faster. But people with a very slow internet connection will cause issues for everyone within that instance. When I play LOTRO i still see rubberbanding with players with poor internet connections. Or it maybe mine. Having a Client-server system doesn't make peoples internet connections great.
 
We see two general trends in the gaming industry:

1) Subscription based games are dying out.

2) Games with networking are moving towards P2P or hybrid rather than full on C/S.

FD are simply a bit ahead of the current trend. This means also they are on the front end in the industry of having to make P2P work for a (well, i wanted to say twitch based, but don't want to get into that semantic argument) FPS type game (please don't argue the definition, i already apparently can't call it a twitch game, leave me a definition that i can use!).

We can only speculate how much cash FD would have neeed to go full C/S for ED and whether they could have covered it with cosmetic sales. But i think it would be likely that the current model would not have satisfied the costs, and they might have had to focus less on gameplay features and more on customization... which would have led to the inevitable complaints that the game has even slower releases and the devs are focused on selling cosmetics.

If they had gone subscription based, I think the game would have been . I've never subscribed to a game and never will. I have enough monthly bills to pay, i'm not paying monthly for games on top. I have a PS4, but no PSN subscription, i can live without the "community" benefits of games. Any game that requires PSN, i simply don't buy.

So, overall, despite issues with P2P, i think they went the right direction, and in doing so, have future proofed themselves as well.

I wouldn't call it ahead of trend. P2P has been in use for quite a while now. It might be still a bit unusual for PvP.
 
Yep, technically peer to peer is faster. But people with a very slow internet connection will cause issues for everyone within that instance. When I play LOTRO i still see rubberbanding with players with poor internet connections. Or it maybe mine. Having a Client-server system doesn't make peoples internet connections great.


Quoted for truth.
 
A client-server model with up to 32 or 64 players hosted by FDEV is something most people wouldn't pay for monthly. It's also way to costly for such a niche game. It also doesn't make much sense if these 32 players are spread over the whole galaxy.
.
Hehe, no. Unless you are claiming that the game is so low on population that single users logging on and off already have a significant impact, this is technically not true.
.
What i mean is: let's assume that the game is only changed in one aspect: instead of a users PC being the "server", this task will now be done covered by actual servers. (I know that the players PC is not called server here, but technically whenever several players are in one instance, the PC of one player is the master and controls what's going on there. So it does the most basic job of a game server. ) So the game would still be on the same instance size limitations. As long as the game slices itself like this CPU and Memory useage would scale in a linear fashion to the number of active players. And when you look at network traffic, you'll find that sure it goes up exponentially when a single instance gets more and more players, but as the instances are capped and spread out, the big picture would show a linear increase.
.
On the other hand, if you actually would change the infrastructure to significally bigger instances (more than the game could currently handle, so it's a theoreical thing), you would find that the useage of CPU, Memory and network scale faster than the userbase. So actually if this is such a niche game as you claim, it'd be at the very low end of operational costs.
.
The actual expencive part in this case are: humans. An administrator or developers gets his monthly salary, no matter how few or many people play.
.
.
That all being said, i also think that the game would profit a lot from a central server infrastructure, and it's even not impossible to do. Switching from a centralized structure to P2P is a lot of work, but switching from P2P to a centralized structure is comparatively easy. Having actual servers would allow to eliminate a number of issues and would provide the option to add some mechanics to smoothen out gameplay. The primary example are methods to hide latency issues, aka lag. While you technically can't prevent lag to happen, there's a number of solutions around to make it less visible. But all of them require a central authority with its own clock.
.
In a P2P setup one players machine has authority. This disallows the useage of those methods. (And that's before even considering how much power you hand to the owner of the PC just mastering an instance. By design P2P is open to memory manipulation cheats, for example. There's one theoretical cure around: encrypt everything you put into memory. On the practical side, i doubt any game currently does that, as the game then would be more busy encrypting and decrypting than to actually do anything else.
.
That all being said, i know we won't get a switch. There are other games out there, which are buy2play or even f2p, making their money with cosmetics and maintaining a server infrastructure which allows more players than this games instance sizes. But by using P2P a few bucks are saved and i doubt that FD will ever change that.
.
 
Server based games don't necessarily result in subscriptions. Guild Wars for example runs (still) without one and they had to support a far larger player base. The cost was covered by selling new standalone expansions and if I recall correctly they added a shop years later. Elite had one from the start and it sells pretty good, seeing all the swag in Open. ;-)

Not necessarily, no. But I think Frontier have actually said that for ED it would have resulted in subscriptions.

Unless I'm getting forum lore mixed up with official statements, which could very well be the case.
 
Apologies for going slightly off topic but I wanted to ask a technical question about combat logging relating to P2P without the thread deteriorating into a slanging fest, and this threa seems like an appropriate one.

I'll keep this as brief as possible:

I get that when using a client2server model, if someone disconnects the central server can (if chosen) persist their presence, because it knows at all times who is connected and all their stats etc.
I've heard that using P2P precludes such an approach but don't fully understand why.

For each instance, each client connected to the instance needs to know a minimum amount of information about the other ships in that instance i.e. who the ships/cmdrs are, their trajectories, weapons firing etc. Then there is additional information such as ship health where there is a choice over whether individual clients keep track or whether that information is also shared. If full combat-relevant information was always shared across all clients, then in the case that one of the clients disconnected, there is enough information to persist their ship if chosen (and then a choice on what to do with it i.e. model it as an NPC, leave it static or other). In fact, if the full information for each ship was always shared with at least one other client, then unless that client also disconnected at the same time, there would be enough information to persist the ship.

There would be a choice over which client needs to persist the ship, but this is analogous to choosing which client models the NPCs.

So what is the reason that ships cannot be persisted in P2P? Is it that sharing that data is too much to transfer between clients? Or am I missing some other technical limitation?
 
.
Hehe, no. Unless you are claiming that the game is so low on population that single users logging on and off already have a significant impact, this is technically not true.
.
What i mean is: let's assume that the game is only changed in one aspect: instead of a users PC being the "server", this task will now be done covered by actual servers. (I know that the players PC is not called server here, but technically whenever several players are in one instance, the PC of one player is the master and controls what's going on there. So it does the most basic job of a game server. ) So the game would still be on the same instance size limitations. As long as the game slices itself like this CPU and Memory useage would scale in a linear fashion to the number of active players. And when you look at network traffic, you'll find that sure it goes up exponentially when a single instance gets more and more players, but as the instances are capped and spread out, the big picture would show a linear increase.
This could solve the porblem of 32 players being spread in the entire galaxy, it doesn't solve the other issues. But it's still very questionable if such a system would work better than the current P2P/Server hybrid technology. There are lots of technicial difficulties to overcome if you want to switch servers seamlessly, and I am not sure if it has been done yet. This problem doesn't exist with the current P2P/Server hybrid technology because you can simply be your own host as soon as you switch instances.
.
On the other hand, if you actually would change the infrastructure to significally bigger instances (more than the game could currently handle, so it's a theoreical thing), you would find that the useage of CPU, Memory and network scale faster than the userbase. So actually if this is such a niche game as you claim, it'd be at the very low end of operational costs.
Not at all. Peak numbers sometimes go up to 13.000 on steam, + lets say 7.000 without steam, + lets say 10.000 on xbox/ps4. That's 1000 servers, should be quite costly... But it's still a niche game compared to CoD or WoW.
.
The actual expencive part in this case are: humans. An administrator or developers gets his monthly salary, no matter how few or many people play.
They already have servers and admins...

That all being said, i also think that the game would profit a lot from a central server infrastructure, and it's even not impossible to do. Switching from a centralized structure to P2P is a lot of work, but switching from P2P to a centralized structure is comparatively easy. Having actual servers would allow to eliminate a number of issues and would provide the option to add some mechanics to smoothen out gameplay. The primary example are methods to hide latency issues, aka lag. While you technically can't prevent lag to happen, there's a number of solutions around to make it less visible. But all of them require a central authority with its own clock.
No, not really.

In a P2P setup one players machine has authority. This disallows the useage of those methods. (And that's before even considering how much power you hand to the owner of the PC just mastering an instance. By design P2P is open to memory manipulation cheats, for example. There's one theoretical cure around: encrypt everything you put into memory. On the practical side, i doubt any game currently does that, as the game then would be more busy encrypting and decrypting than to actually do anything else.
There are cheats for almost every server based game.
 
Having actual servers would allow to eliminate a number of issues and would provide the option to add some mechanics to smoothen out gameplay. The primary example are methods to hide latency issues, aka lag. While you technically can't prevent lag to happen, there's a number of solutions around to make it less visible. But all of them require a central authority with its own clock.

Elite already does smoothen out gameplay to hide ever present delays.
It's how something like this happens.
It would be a stutter fest otherwise.

And that is just one p2p viable approach that happens to work best for Elite.

Fighting games commonly re roll their entire game state upon delayed updates diverging from already played predictions.
For Elite that would result in object teleportation (including things like ship trails) and taking hits you never saw happening, which would be rather irritating.
(also it requires deterministic physics, which I believe Elite doesn't have)

A server wouldn't change anything about what can be done to mask lag.
 
Last edited:
Ok, I don't know the answer but, there are a few history lessons.

When CCP first started on Eve they wanted a full scale MMO Elite. The idea was to actually fly the ships. But the idea was also one enormous server where everyone could be connected to everyone else. Due to technical difficulties the first person flying was ditched. Point and click was where it was at.

A game I used to play, Jumpgate had one server and semi Newtonian flight model. It never had more than 500 players at one time and still suffered lag a plenty. Their proposed sequel, Jumpgate Evolution was to feature instances and shards. They realised that a massive server just wasn't going to cut it. Bear in mind that like its predecessor the game was due to be subscription based.

So onto Elite. I don't doubt that cost is a major factor but one giant server would be asking them to solve a problem no one had solved before with a twitch based 6DOF model.

It's not perfect and I still long for a space pilot based game I can interact with everyone else but I simply don't believe the technical infrastructure is in place yet.

I'll keep waiting.

I'll just say that this is a good summary. The point being is that a client server model would be much more expensive in the long run for DFev and possibly make the game nonviable. There would have different kind of connection problems with all the clients hitting the various servers at once and we'd still have all the usual lagging and rubber banding depending on who was in a system with you. The amount of data which needs to fly between client and server is quite a lot more than you're standard MMO and there's a reason why the big games like Battlefront only allow a certain amount of players on their maps.
 
Apologies for going slightly off topic but I wanted to ask a technical question about combat logging relating to P2P without the thread deteriorating into a slanging fest, and this threa seems like an appropriate one.

I'll keep this as brief as possible:

I get that when using a client2server model, if someone disconnects the central server can (if chosen) persist their presence, because it knows at all times who is connected and all their stats etc.
I've heard that using P2P precludes such an approach but don't fully understand why.

For each instance, each client connected to the instance needs to know a minimum amount of information about the other ships in that instance i.e. who the ships/cmdrs are, their trajectories, weapons firing etc. Then there is additional information such as ship health where there is a choice over whether individual clients keep track or whether that information is also shared. If full combat-relevant information was always shared across all clients, then in the case that one of the clients disconnected, there is enough information to persist their ship if chosen (and then a choice on what to do with it i.e. model it as an NPC, leave it static or other). In fact, if the full information for each ship was always shared with at least one other client, then unless that client also disconnected at the same time, there would be enough information to persist the ship.

There would be a choice over which client needs to persist the ship, but this is analogous to choosing which client models the NPCs.

So what is the reason that ships cannot be persisted in P2P? Is it that sharing that data is too much to transfer between clients? Or am I missing some other technical limitation?

The problem is that, to use Frontier's term, no "infallible arbiter" exists to decide when your local client should be able to seize control of another player's ship and subsequently allow you to destroy it.

Thanks to p2p, it would inevitably remain possible to combat log and/or become possible to force an AI takeover of an opponent's ship.
 
If you really want to find out how the decision was made, have a stroll through the Design Discussion stuff. It would have been the result of all those involved debating the issue.

Server architecture was never a part of the DDF. While the subject was discussed, the decision to use P2P was already taken.
 
Why did Fdev choose to go the way they have with the netcode?

Probably to give people something to discuss on the forums... I think that's why they add some of the other irritating bugs too. :D

I like it when netcode gets refactored to allow serialised 64bit variables across a server meshed localised physics grid. If you're not following me, you obviously don't understand games development. :)

Or the alternative... That you are talking rubbish. ;)
 
Status
Thread Closed: Not open for further replies.
Back
Top Bottom