I've read up a little on the concept of splitting the world into regions which in turn can each be run on a node within a cluster. However my game concept revolves less around zones but rather bubbles.

In short, a bubble is a region of space defined by a radius which dynamically expands and contracts depending on how many players are in close enough proximity.

For example if two players are over 1000KM apart and there is no one else that close to them, then those two players will be in their own bubbles. However once they come within 1000KM to each other, their bubbles connect, effectively creating a larger bubble.

In terms of the server space, one of those players is switched to the others instance. In practice it may be the case that a single server node could handle multiple bubbles, but for arguments sake we'll say that each bubble is run on a different server.


Secrecy may well be a big part of this game, so its important that when one player is close to another they aren't able to detect this by listening for connections to new instances.

My current thinking is that players would be grouped into proxy servers which in turn dynamically connect and disconnect from the bubbles therefore separating the client from this process.

The problem of course is latency. There is already latency in the communication itself, and I am concerned that this additional step of tunneling data like this may unnecessarily make it worse.

I would also love to find material to read on this type of instancing.

  • \$\begingroup\$ I would recommend that you don't merge bubbles at the edges...merge the bubbles when the player objects enter each other's bubbles....There is no real point in capturing whether collisions overlap, only actionable objects. \$\endgroup\$
    – Escoce
    Feb 2 at 5:17

1 Answer 1


If your gateway servers players are connecting to are in the same data center as your simulation servers, then the added latency would be much smaller than a hop through the Internet and might not be a problem at all.

But you could also look at it another way. Instead of hiding the server change from the players, instead let them see it, but empty it of its meaning.

In order to support the bubble merging mechanic you have in mind, it already has to be the case that migrating players to a different server instance is a safe, and reasonably cheap/efficient operation (if it's not, your plan needs changes before it can scale).

So, it it's cheap and efficient to do, you can afford to do it more than you need to. Introduce a chance of migration to a randomly-chosen instance on a similar or slightly greater frequency as you expect player bubble mergers.

This only doubles your migration workload (maybe less, since these migrations can be pure state swaps with no merging), but it's enough to mean that a player who detects a migration can't tell whether they got close to a new player, or if it was just a random migration.

Also, because players now don't have a stable instance they're routinely connecting to, I can't use the IP of the server instance to identify a group of players I've previously encountered who I might have just re-encountered. Their bubble will likely be on a different instance by the time I bump into them a second time.

So the amount I can deduce from watching my connection IP is now much lower, and full of noise that would frustrate attempts to sneak useful information out of it.

  • \$\begingroup\$ Thanks, your first answer alleviates my concern greatly, and your second answer is on point not only in that it could be randomized, but there likely would be real alternative reasons for switching. \$\endgroup\$
    – Flosculus
    Aug 13, 2020 at 11:34

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .