Seamless transfer of objects between replicators.

Hi. I originally posted my initial question on Discord, and @brit thankfully has answered to that.

He mentioned that ‘most large scale MMOs will regionalize based on game geography, so instead of 4 worlds all running the same full game, you could split your game by geography in 4 quadrants, each with it’s own world. You could then transfer players between them seemlessly as they run around.’

What I understood is, on travelling from zone A(a zone associated with replicator A) to zone B, I should have my coherencebridge to establish a connection to B while discarding one to A. Is this correct?

1 Like

Thanks for posting here, bohyunjung. In general, yes:

  • create a world in the dashboard for each region you’d like
  • use the coherence SDK to list all of the Worlds (replication servers)
  • use your own game logic and geography to determine at what positions in your game you should transition to the different worlds and start a new connection to that World’s RS.

I’ve put a call out for any more specific advice from the team on this setup that may help you out.

1 Like

Hey, Brit is exactly right and this is something I’ve experimented with myself.

To expand on the approach Brit and you are discussing, here are some suggestions:

  • each zone is considered a world from the point of view of setting up a replication server and connecting to it from the client via a bridge.
  • each zone geographically can have a distinct border between them, but use some overlap trigger mechanism so you can be in more than one logical zone at a time.
  • in Unity I made each zone its own scene so you could load just the scene(s) your entity is walking though and so each scene contains its own distinct bridge.
  • each zone you’re in (logically) creates a connection to that zone’s RS which means as a client you might have more than one simultaneous bridge connected at a time and as you leave / enter zones you make / break connections to the RS via the zone’s bridge.

This setup will allow you to have a clean logical separation of geometry and simulation so that only clients in the same zone(s) send updates to each other. Then, when you transfer between zones you’re not really transferring anything you’re just deciding which zones are active so when you leave one zone the other is the active zone naturally. The challenge though, is that with a basic character setup that has a CoherenceSync object that you’ll end up with potentially multiple duplicates of an entity in two overlapping zones when observed by another client also in those zones. Also, the client will send updates to both worlds but the observing client might see the updates at slightly different times, so the two observed copies of the entity will be out of sync.

One trick to address this is to separate entity sync state with entity render state. If you split a character into the synced state prefab and a renderable prefab then each client can reconcile each duplicate of any character and blend the states into an official state that is applied to a single renderable instance of a character.

So in a simple one world, one scene set up you have an entity “A” from authority client “Ca” and an observing client “Co”.

Client Co is observing (—>) entity A, and client Ca is sending updates (==>) to entityA:

Ca ==> A <--- Co

If you separate the state from the renderable you have a synced state of entity “As” and the renderable state of entity “Ar”. The renderable state draws (—) from the sync state to update position / animation / ect.:

Ca ==> As --- Ar <--- Co

This means that even the local client is only manipulating the local As and there’s a local render state that is doing the same thing to draw the information from As to update Ar.

So, if both Ca and Co are in two zones simultaneously, because you want to do a smooth-looking transition from zone 1 to zone 2 and there’s an observer in the same zone boundary overlap, then you need to use the same setup but somehow negotiate what the official state of the observed renderable is from each client. This can be done by just using the As in the particular scene or a blend of the As’s.

In this setup there’s a “Ca1” and a “Ca2” for the two clients (same machine but overlapping zones) and one Co (but this works for two Cos the same way)

Ca1 ==> As1 --- Ar <--- Co
       Ca2 ==> As2

Where Ar might draw from both As1 and As2 and blend together to decide its state.

This may seem weird or counter-intuitive but because the inputs from the client are going to the two As entities (one for each zone the client is in) and because the world geometry is the same everything looks correct in the end to the observers regardless of which As the Ar is using.


Here’s an example of what I mean. Four clients:

  • two zones, red and green, created in different scenes and each connecting to their own world RS.
  • the zones are running simulators that move the little pink pawns around in their own space.
  • top left is the active client I move around between the two zones. You can tell when the client is in the zone when the pawns appear. And can tell when the client leaves the zone because the pawns disappear.
  • top right is another client that is standing in the zone cross over and is connected to both zones. The transition of the primary client between zones is smooth.
  • bottom left is a client solely in the green zone and can only see the primary client when it comes into the green zone.
  • bottom right is a client solely in the red zone.

From the perspective of the bottom clients, there is only one sync representative of the primary client (top left).

From the perspective of the top right client, there are two syncs since the top right client is also connected to two zones and has two bridges, both bridges replicate a copy of the client, but the renderable is only updated based on one of them at a time.


Many thanks to Brit and Cary!

I really like the ‘overlapping zone & state negotiation’ idea that Cary has introduced. It accomplishes the seamless transition of the objects that you ‘bring along’ for the observers in the overlapping zone and even for the local player.

Kudos to the actual demo video. That was super helpful.


This topic was automatically closed after 30 days. New replies are no longer allowed.