Linked multiplayer servers

Mudbucket shared this feedback 4 months ago
Submitted

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.

Comments (4)

photo
1

Id imagine this would be possible for going from one private/offline world to another one.

photo
2

Yes, since server admin config is explicit, two private servers could be linked and stay private.

photo
photo
1

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.)

photo
1

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.

photo
1

You're making a lot of unwarranted assumptions about requirements, and allowing the perfect to be the enemy of the good.

I'm not suggesting Space Engineers should jump to MMO behavior. That's definitely too big of a reach right now, if it's ever possible. (Having gameplay outcomes dependent on the calculations of a non-deterministic physics engine means there will always be a heavy non-replicable simulation burden somewhere in the system. (Havok is deterministic, but only if internal simulation caches are identical between instances at each timestep.)) I'm suggesting a much looser coupling between servers than that.

I have no particular problem with you appearing as offline on all of the servers in a linked cluster except the one you're actually connected to. Yes if you're trying to meet friends you have to communicate one extra piece of location information out of band, but you're already communicating out of band location information (the time you're playing) before any rendezvous can happen, so adding one more is no burden.

Similarly, there's no need for a login server. A client logs in to each server effectively independently. Account replication happens over the same link as grid replication when a player initiates a transfer between servers. Admittedly I touched on that link only briefly in my last paragraph, but yes, that's where the major code change is: servers would maintain links between each other, and transfer account, faction, and grid data through those links. The transition would not be even remotely seamless for clients. A client would go through the logout process followed by an automatic login process on the destination server. That transition could be papered over a bit with UI on the client side, but from a client perspective, it would otherwise be identical to logging out of one server and connecting to a different, independent server today. You'd just get a copy of the grid you told the server to transfer, at the location you performed your transfer, instead of a drop ship onto a random planetary location.

No complete rewrite is required anywhere. The protocol that communicates grid and faction and player movement data remains completely unchanged. Most server handling of a connected client remains unchanged. What changes are a new block, with associated UI, a new server-to-server network connection, and some admin UI.

Will it act like a seamless MMO multi-server universe like EVE Online? No. Does it need to? Not immediately. Maybe never. Space Engineers is a big box of LEGO blocks, not a grind for isk and rank. Linking servers is mostly about allowing players to show off their creations in action in a survival setting without having to rebuild their favorite ships from scratch every time they log in somewhere else, not a grind followed by a giant political swamp.

photo
photo
2

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.

photo
1

Ah, but they're hiring. Including a senior network engineer. There's a tiny ray of hope.

photo
1

As a previous Keen employee, I give this about a 0.02% chance of happening. It's not even on Keen's radar.


I've been working on a server networking project independently, and let me tell you, it's far, FAR more work than you think. Keen would never sign off on the amount of developer time it would take for this to happen.

photo
1

I'm sure you're right about the chances of it happening.

It's certainly not far more work than I think. It's exactly as much work as I think. I've written MMO network code twice in my career. I do have to defer to your experience with Keen about their tolerance for large development efforts though. As Arthur pointed out, they don't have the developer hours available just to fix bugs or even integrate community mods (with the very welcome exception of a few things like auto-inventory). Major features are pretty much beyond their reach these days. At this point I'm just hoping they fix a few of the bugs and increase or expose the arbitrary limits on welding high block count grids.

photo