Linked multiplayer servers
There are several Feedback topics on this subject, though most of them are one-liners. I upvoted this one as an interesting (and much more wide-open) variation. Mine is much more defined and closed. And unlike that author, I am a software developer. :)
So, to the details. Let's allow linking multiplayer servers. Require the same mod list on two connected servers, and the same settings, especially whether Experimental Mode is enabled or not. That way ships don't arrive on a different server with missing or malfunctioning blocks. Different settings should not be allowed because of such problems.
The issue I see is one of game design. If there's a single fixed portal connecting two servers, it becomes a spawn campground, both departing and arriving. Not fun.
One might consider attaching the entire "edge" of one server's universe volume to some fixed edge of the other server. The problem with that is the size of the Space Engineers universe, which is 1,000,000,000 km across. To travel from the center of one server to the center of the adjacent server would take 500,000 jumps for a ship with a single jump drive. Even with 50 jump drives (if that even works), it would take 10,000 jumps. Someone would almost certainly do it, but not many more than one.
One possibility is a "phase shift" module that can be added to a jump drive, similarly to how refineries and assemblers have modules. To enable the shift jump, all jump drives in a ship must have the module. A shift jump moves you to the same spacial coordinates on a connected server. Like the way jump drives work now, if there's a collision detected, the shift fails. If the shift would move you into a gravity well, the shift fails. PCU limits on linked servers are required to match, so there's no possibility of exceeding a PCU limit on the destination server. Whether or not a phase shift should be allowed with a non-zero velocity is a judgement call; the current jump drive persists a ship's velocity vector across a jump, allowing players to construct a very expensive but 100% indefensible weapon (aside from Safe Zones). Phase shifting would add yet another variant of that weapon. And speaking of Safe Zones, phase shifting directly into a Safe Zone, even a friendly one, is not allowed. Zone field interferes with phase shift because <B'Elanna Torres voice>insert Star Trek gobbeldygook excuse here</B'Elanna Torres voice>.
Alternatively, phase shifting could require an entirely new phase shift block. Each phase shift engine can shift up to 1,250,000 kg to another server. Ships larger than that have to carry additional blocks. If there aren't sufficient blocks to shift the fully loaded mass of the ship, the jump fails. The restrictions and questions discussed for a phase shift module on jump drives also apply.
Finally, to enable small grid ships and cheaper large grid ships to shift to another server, a new block similar to the Safe Zone block could be introduced: a player constructable Portal Zone block which requires ZoneChips to function. It also requires a linked same faction Portal Zone on the other side. This would allow linking arbitrary locations on the two servers, at the cost of ZoneChips at each end. The Zone would be a spherical bubble in space, custom sizeable, same as Safe Zones, with the same maximum 500m radius. A ship must move entirely into the Zone to shift servers. Once a ship entirely enters a Portal Zone, shifting to the other server is mandatory and automatic. Only one ship at a time can shift from the origin Zone. If the destination Zone is still occupied by another ship, the anti-collision rules of Jump Drives apply and the shift fails. A ship loitering in the destination Portal Zone would start to take damage. Loitering too long ultimately destroys the ship, because <Montgomery Scott voice>prolonged exposure to the Portal Zone field interferes with molecular cohesion etc. etc.</Montgomery Scott voice>. (Loiter time configurable by server admins, defaulting to 120 seconds.) Unlike Safe Zones, the edge of the field would begin at the Portal Zone block, rather than the center, so the center of the zone can be used by a large ship, and so the generator is accessible to power and reload with ZoneChips and can be Safe Zoned. (Suggested block model design should include a large dish-shaped structure on the large face of the block. The block must be oriented correctly when building it. Build the block upside down and activate it and hey presto! a chunk of your station vanishes. Oops.) Giving players the unlimited ability to raid a Portal Zone block for its ZoneChips to power their Safe Zones means no one would ever build Portal Zones, so it must be possible to Safe Zone the block. Conversely, introducing Portal Zones at all allows for a certain amount of spawn camping, modulo being able to locate them and the probably active resistance of the faction running the station that hosts the Portal Zone. Rabid PvPers who always want to be able to destroy anything all the time will moan and complain about being unable to raid a Safe Zoned Portal Zone, but its existence will still give them something to shoot at. (And what's wrong with you kids? Didn't your daddy's teach you not to break your toys?)
For all variants, the same rules as Jump drives apply: Engineers not seated get left behind. For the phase shifting drive variants, if there are multiple connected servers, the players are required to choose a destination server from a list when activating the shift. For the Portal Zone variant, the builders must select a destination server in the options of the Portal Zone block. Once the destination server is selected, a list of Portals is made available, and a destination Portal must be selected. The two Portals must either be owned by the same faction or must have compatible faction settings and friendly relations. Figuring out the details of faction interactions and utility are left as an exercise for the reader, 'cause hey, I'm not getting paid for game design here.
There are some administrative wrinkles. Two admins connecting servers for the first time would need an interface to reconcile factions, either forcing name changes when names conflict or designating them as the same faction, at their discretion. Once servers are linked, creating a faction on one server must automatically propagate to the other server. Settings discussed above would need to be available.
Id imagine this would be possible for going from one private/offline world to another one.
Id imagine this would be possible for going from one private/offline world to another one.
On further reflection, only explicit server linking makes any sense. If you could jump from server to server arbitrarily, you could trivially start your own server, give yourself 100 million space credits with admin powers, then jump to any other server and be able to fund a Safe Zone for all eternity. Quite aside from using Creative mode to build arbitrarily large ships for free, then jump into a Survival server. So the only way to maintain the integrity of a game cluster is explicit linking among admins who trust each other. (Or by a single admin putting together a pocket universe.)
On further reflection, only explicit server linking makes any sense. If you could jump from server to server arbitrarily, you could trivially start your own server, give yourself 100 million space credits with admin powers, then jump to any other server and be able to fund a Safe Zone for all eternity. Quite aside from using Creative mode to build arbitrarily large ships for free, then jump into a Survival server. So the only way to maintain the integrity of a game cluster is explicit linking among admins who trust each other. (Or by a single admin putting together a pocket universe.)
This isn't possible with the current network implementation. The hole code is limited to: one server is managing n clients. In your case we have a m to n relation, instead of a 1 to n relation. This means, at that moment player A shift from Server 1 to Server 2 he is offline on Server 1. But that isn't what you want. All players needs to be online on each server. The next problem is, which server is your login server? The hole design is designed around that you connect to that specific server. But in your case you need to connect to the last server where you were. So, you need a login server that delegate you to your destination server. With other words, you need a master server.
Generally it is possible to say.. any server is a master and a slave server at the same time. So every player is connecting to it's specific master server. But in this case, the server needs to store the information that your last logout was not on "me". So the server is able to delegate you to your destination server. And don't forget to share any information between all linked servers. So you have only one big database. Or you run into a split brain issue.
This causes to a complete rewrite of the network code incl. the server software.
This isn't possible with the current network implementation. The hole code is limited to: one server is managing n clients. In your case we have a m to n relation, instead of a 1 to n relation. This means, at that moment player A shift from Server 1 to Server 2 he is offline on Server 1. But that isn't what you want. All players needs to be online on each server. The next problem is, which server is your login server? The hole design is designed around that you connect to that specific server. But in your case you need to connect to the last server where you were. So, you need a login server that delegate you to your destination server. With other words, you need a master server.
Generally it is possible to say.. any server is a master and a slave server at the same time. So every player is connecting to it's specific master server. But in this case, the server needs to store the information that your last logout was not on "me". So the server is able to delegate you to your destination server. And don't forget to share any information between all linked servers. So you have only one big database. Or you run into a split brain issue.
This causes to a complete rewrite of the network code incl. the server software.
I take it as a joke, really. Though your idea and the possible implementation guidelines are very interesting, Keen is not able to fix very basic bugs that have been reported months ago, in some cases, years ago. EXTREMELY simple QoL fixes are ignored, such as projector blocks for subgrids in survival, camera zoom freedom, inertia fixes, etc..
It's very unreasonable to think they would implement our idea, but a very interesting suggestion nonetheless.
I take it as a joke, really. Though your idea and the possible implementation guidelines are very interesting, Keen is not able to fix very basic bugs that have been reported months ago, in some cases, years ago. EXTREMELY simple QoL fixes are ignored, such as projector blocks for subgrids in survival, camera zoom freedom, inertia fixes, etc..
It's very unreasonable to think they would implement our idea, but a very interesting suggestion nonetheless.
Indie game developer here... I feel you guys are being quite negative and reluctant to actually focus on the fact that it can(has) happen(ed).. firstly, lets look at the past... Keen said no planets, we got planets... Keen said no ladders, community made ladders, vanilla game received ladders... Keen said we would never have water, the community has create a wonderful water mod... Keen said we would not have weather on planets, we now have a weather system...Keen said we cannot have varying types of planets, we now have lava planets, nebulas, black holes, etc..)... Do you see where I am getting at? People on this post want to be sooo negative and say that it is impossible... you guys are definitely not engineers... not even close... even wondering if buddy actually worked for Keen(if he did, no wonder they can’t do anything if they all had his attitude...
Second point I want to make, it has already happened. Look at the Sigma Draconis server. They had combined servers(and even have an initial login server) and have a player count of 200 with 15 different server instances. Aside from DDos attacks, their server runs very well. I am actually in the process of doing the very same thing and combining server instances to create a large mmo experience...
Indie game developer here... I feel you guys are being quite negative and reluctant to actually focus on the fact that it can(has) happen(ed).. firstly, lets look at the past... Keen said no planets, we got planets... Keen said no ladders, community made ladders, vanilla game received ladders... Keen said we would never have water, the community has create a wonderful water mod... Keen said we would not have weather on planets, we now have a weather system...Keen said we cannot have varying types of planets, we now have lava planets, nebulas, black holes, etc..)... Do you see where I am getting at? People on this post want to be sooo negative and say that it is impossible... you guys are definitely not engineers... not even close... even wondering if buddy actually worked for Keen(if he did, no wonder they can’t do anything if they all had his attitude...
Second point I want to make, it has already happened. Look at the Sigma Draconis server. They had combined servers(and even have an initial login server) and have a player count of 200 with 15 different server instances. Aside from DDos attacks, their server runs very well. I am actually in the process of doing the very same thing and combining server instances to create a large mmo experience...
Replies have been locked on this page!