Scalability issues. A VW based on Google Earth. Part 2.

We know that Second Life and others face scalability issues. Indeed, virtual worlds barely scale: recently Eve Online announced they can now support 1000+ users playing together and this was seen as a great achievement. Imagine, msn or facebook teams announcing they can now support 1000+ users chatting simultaneously. This would be laughable, but for virtual worlds a so poor scalability level seems normal. Definitively, there is something hard here.

Let's try to understand the problem (and how Twinverse solves it):

Take, for example, 1 million avatars evolving inside a huge virtual world, say Google Earth, and imagine you are in control of avatar XYZ.

Suppose you move the right arm of your avatar.

The naive solution is to send "avatar XYZ has moved his right arm" to the whole million running instances of GE.

Then each GE instance will see if it's concerned by the event (if avatar XYZ is in sight). If so, the event will be transformed into an animation of XYZ's local representation otherwise it will be dropped.

This solution is clearly impractical and do not scale.

In region-based systems (like Second Life) the solution is the following:
There is a server for each region of the world, and avatar XYZ is connected to the region where it seats.

So "avatar XYZ has moved his right arm" is sent to the region. And since all the concerned avatars are connected to this region, the region send them all the "avatar XYZ has moved his right arm" message and all the receivers are more or less concerned.

Among other problems (the well known “too crowded region” problem), this solution is also impractical for huge virtual worlds, and for instance the earth is too vast. If your virtual world is vast, thousands (millions?) of servers are needed to cover the world -even before the first users arrive.


Twinverse solution:
Each avatar is connected to the avatars concerned by its actions. These connections are the red lines of the doughnut picture (link).

So when avatar XYZ move its arm, the "avatar XYZ has moved his right arm" is sent directly to the concerned avatars.

The point is how to keep the "Each avatar is connected to the avatars concerned by its actions", how to keep the "red network" when avatars move.

The trick: the avatars collaborate to maintain these connections.

Let's put an example:

Avatar alice is connected to avatar bob and avatar bob is connected to avatar carol. but alice is not connected to carol since they are not in sight.

Then avatar carol starts moving toward alice, and since bob is connected to carol, bob sees carol moving and tells alice and carol to connect together.

So when alice and carol come into sight they are already connected. Thanks to bob.

More precisely, there are many connections so alice and carol do not rely only on bob to make the connection, there is enough redundancy.

You can find more on that in this short document:
http://www.twinverse.com/TwinverseTechnology.pdf