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.
