Multiple worlds?

Hi, I’m trying to think through how best to implement a client-server networking solution in Unreal.

Ideally, I’d like to have a server world instance and a client world instance running on the same machine. That way I can test with simulated lag and the like. However, from what I can tell, the World component of the engine is a singleton?

I basically want to have 2 exact copies of the game world, that exist on separate layers so they can’t interfere with each-other, and have them communicate via pseudo networking code. Further, the “server” instance should be stripped of all graphical elements, and only keep the data required for collision and game logic.

I could also just have two game worlds separated by some amount of space, I suppose. But that solution seems a bit hacky.

What is the best way to go about achieving something to this effect using the existing Unreal Engine design paradigms?

Note The key difference is that the client and server worlds will be slightly out of sync due to latency. I need an easy way to reconcile these discrepancies.

How much in sync does it need to be? They’re different worlds so there is always that what you call it, space–time slippage… haha jk. Anyways how much latency do you expect on a local machine? A simple boolean is all you need to separate items in one world from another, it sounds way too complex than it needs to. If you’re trying to communicate with two completely separate games then you’ll need to read/write dynamic variables on each game to file or through tcp or something. If it’s the same game with 2 different functionalities of the game map then it’s probably best to manage everything from a single game instance, especially since they’re two exact copies with the slightly different logic, you’re going to slow down your server unnecessarily. As far as keeping game elements separate, there are lots of ways: spawning elements only on specific clients machines, masking materials on specific clients, also like you said to reposition game elements, then there’s also creating a separate map, probably also streaming different level elements for specific players.

Thanks for the reply! Let me try to explain things better.

There are 2 problems I’m having.

Part 1:

The easiest way to visualize the first one, is that I would like to be able to emulate a dedicated server in a single game instance (Mostly for testing, and possibly the case when one person hosts both a server and a client).

If I used a single “world”, then I can’t really simulate lag properly. The system I’m setting up is explained better in part 2.

(I agree that depending on load, it might make a lot more sense to just have the “server” and “host client” be the same instance. But, I’d like the option to set things up this way regardless.)

Part 2:

I’m trying to set up an event driven game engine, so basically both “worlds” will be running the same events. The issue, is that the exact timing of the events varies.

For example, imagine the case of a single player controlled character (on Client A). This player moves. The network flow is as follows:

Client A sends move command to server -> Move command is processed and propagated to all clients -> Client A receives command and moves character

Okay, that’s fine. But, in this case the move command has to do a full roundtrip before it is seen by Client A, making input feel very sluggish. Here’s what I want to do:

First, Client A has two instances of the world. One instance is “synced” to the server. The second is a graphical instance, which gets player input events before the server sees them, and then uses the synced version to interpolate any arising discrepancies over time.

In this set up, the flow looks like this:

Client A sends move command to server -> Move command is processed and propagated to all clients -> Client A receives command and moves character on SYNCED instance
Client A sends move command to graphical interface -> Character starts to move instantly on their client -> Synced instance and graphical instance are now out of sync. -> Apply interpolation/etc to fix the variance

So, objects need to have a “synced” position/parameters, and a “graphical” position/parameters (technically this is only NEEDED for player controlled objects).

The key here, is that I want to keep as much as the basic unreal engine usable as possible. I’m afraid that any hacky approach is going to break a lot of the base awesomeness of the engine.

P.S.
It would be acceptable to instead of having completely distinct worlds, only double up the player controlled objects. But, even still, I would need those objects not to interact with each-other (interaction as defined by the unreal engine itself, not my arbitrary interactions). I feel that both these issues are very similar. Basically, what is the best way to segment the physics and nav system (and other underlying components of the engine)?

Years have passed and I have arrived to this problem as well. I guess no solution yet? I mean aside from making the “worlds” float above each other in server gamespace or something? Would be nice to be able to have world instances but so far I see no built-in way. And since even if I hide actors from one player they are still there on the server at least. Maybe if I held them in a “special” room under the world, non rendered for the listenserver but handling things properly for clients… then I would need to trust the clients with hit detection and stuff completely.

Well, it’s not like I wouldn’t need to trust them like that at all so I guess that might work.

I’ve got almost 0 experience with the C++ UE4 programming, as I’m just starting with C++ scripting, but I think I should state the obvious: if you need to run two worlds on the same machine why not just use two different processes? You can do that with almost zero work, AFAIK. Your test/simulation will never react to lag like real client/server model, if it doesn’t actually use the real network stack. At least on Linux, there is probably already some kind of “configurable proxy” you can add between the two processes, that will allow you to simulate lag and lost packets. Your client “connects” to the proxy, and the proxy forwards (or not!) the packets with some specified, possibly variable, delays to the server, and back. IMO, that gives you the best testing conditions.