Using proxy servers to tunnel data between clients and world servers

Question

Background

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.

Problem

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.

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.