Re: [mmox] User Accounts / "Object" Transfer.

[Morgaine <[e-mail]>]

On Thu, Feb 19, 2009 at 12:37 AM, Jon Watte <[e-mail]> wrote:

>
> Let's assume organization A builds a space. Let's assume organization B
> builds furniture. Now, they want to have a meeting, and see how the
> furniture works in the space. The easiest way to accomplish this is to make
> organization A users log into the organization A virtual world (like they
> always do), and organization B users log into organization B virtual world
> (like they always do), and make arrangements such that some room/area/island
> within the two organizations is shared -- whatever comes to that space from
> A, also shows up in B, and vice versa. This allows A to publish its space,
> and B to bring the furniture to that space, without either having to
> disconnect from their regular virtual world (buddy list, unified messaging,
> inter-office collaboration, etc).
>
> Unfortunately, that's non-scalable, particularly along the complexity axis.

It works fine in your example because you have only two parties wishing to
share a space and hence there is only one space to simulate, but try to
extrapolate from there to see where it leads.  If your organization A has N
users, and those N users wish to take part in N different worlds (which is
asymptotically likely if N << total number of worlds), then your
organization A must now simulate N different worlds.  For large N, this
places a colossal load on organization A, even if the individual shared
spaces are minimally populated.  To coin a common phrase by analogy, you're
undertaking to "simulate the Internet". ;-)

What's more, very few platform optimizations will be possible since the N
worlds are all different, and this also means that the scalability of each
shared space will be severely constrained as well.  And as if that were not
bad enough, the N worlds that your users visit tomorrow will not necessarily
be today's N worlds, so for (N << total number of worlds) your local cache
will need to grow almost without limit if it's to work at all.

Even if organization A's machinery were powerful enough to support N
radically different worlds through shared-space simulations though, they
still couldn't do it, because in the general case the simulation code for a
given world will not be available.  The world simulation is the "secret
sauce" of many virtual worlds, and from a business perspective it is quite
likely to be their product differentiator and they will be loathe to share
it.  But even if it were freely available, the portability of one
organization's simulation code to another organization's machinery is far
from guaranteed with today's software technology, not to mention the
management of upgrades for something this complex across organization
boundaries.

Now contrast that shared-space architecture to today's more prevalent one.
Organizations A and B(1)...B(N) design their own worlds in accordance with
their particular visions, and each world is tailored to their own optimized
hardware.  Now in the case when the N users of organization A travel to
those N different B worlds, organization A has no world simulation load for
active users at all (it just sends out data to the N worlds).  Instead, some
number of foreign users from the B worlds will arrive and need to be
supported.  However, they are supported in organization A's own world
simulation, which is highly optimized by design and hence carries none of
the complexity/scalability problems mentioned above in the shared-space
approach.  Foreign world simulations never need to be supported.

In the Internet-like metaverse model of unlimited and extremely diverse
worlds, I really don't see the shared-space approach as being at all viable,
because diversity is its enemy.  In some severely constrained corporate
settings it might be quite usable (and even efficient for standardized
worlds), but this does not seem to be a generally scalable model for an
evolving metaverse.

Morgaine.