I am well into development for the prototype I am working on. The general idea is
4 player coop
“Round” based like Tarkov
Safe area that works as a lobby and crafting hub (only place players can join their friend’s games)
While in the “world” players can server travel together to other “zones” (Listen Server). You can visualize this as traveling between tarkov maps, or borderlands maps.
All of that is hunky dory working great but here comes my massive problem.
Map size…
The main map in the game is supposed to be the same size as Erengel in PUBG (8km x 8km) and I was planning on using world composition and the whole “Multiplayer Origin Rebasing” thing to fix the floating point issue until I sorta read the fine print.
So, World Composition does not work for a listen server? Why the heck not lol? How would a listen server based game handle large worlds then?
Also, you can’t use Multiplayer Origin Rebasing with dedicated servers? Or you can but they don’t work for listen servers…I keep reading conflicting information (or maybe I am just tired), and the UE4 documentation on the subject doesn’t elaborate enough for me to “get it” in my current state of mind.
I have spent two days absorbing forum posts and even PUBG developer anecdotes trying to figure out what to do, and I am only more confused. It doesn’t help that most of the posts are from 2015-2016. Did something come out that made this issue go away in 2020?
Based on my research I have four options it seems:
Switch to dedicated servers (how can I justify costs running 4 player server instances? Is there a hosting service that can spin up “Shards” or something dynamically?)
Wait for UE5 and hope Epic fixes the problem somehow
Abandon a great, rather simple, idea.
I am not talented enough, nor brave enough, to screw around with source code much. I did see this plugin https://www.unrealengine.com/marketp…89b4a6d19aeea0 but it seems to also only work for dedicated servers (and Single player). Really would like some prospective from other developers here as I am completely burnt out thinking about this. Kinda bummed too.
You can use origin rebasing on a client only. The Server instance, regardless or whether it’s a listen or dedicated server, cannot be rebased. The server always has to work in zero-origin space. It makes sense when you think about it - the Server is replicating the same information to all clients, and those clients can’t use that information properly unless they know what space the server is working in. It also sort of defeats the point if the Server and Client origins are far apart from each other.
One thing that’s really worth pointing out and making clear - WOR was never designed with Multiplayer in mind. Support for it was introduced because of a Pull Request that Epic merged in, and haven’t touched since. The whole system wasn’t thought out very well to be honest, it was introduced around the time of the Kite Demo IIRC, and while it can help with some minor precisions issues on Client machines, it’s useless for Servers. I hear through the grapevine that Epic internally don’t use it on Fortnite and such anyway (no official word though AFAIK), so take from that what you will.
It’s also not as simple as enabling a project-setting, you have to account for the differences in origin anytime the Server and Clients communicate. For basic network functionality like replicated movement this is already dealt with by the engines own types, but you need to factor it in anytime you send or receive locations and transforms to the Server. It’s also expensive to rebase, since every actor and component transform has to be updated during an origin shift, so it can cause hitches in a busy level.
We’re using it in Hell Let Loose (for clients, ofc), and while a neccesary evil it’s been a thorn in our side. There is still an upper cap on level size, because the Server can’t be rebased - and when the Server and Clients are dealing with different levels of precision you also lose a lot of determinism in systems like character movement for example which can actually result in higher network use.
ALL this being said - some folks say that they have somehow managed to fuddle it and shift the origin server-side, but honestly I’m not sure what that achieves on a server when clients can be as far from the origin as they like anyway, and until those solutions have been tested at scale - I’d take the results with a pinch of salt.