[MUD-Dev] Seamlessly Distributed Online Environments

Crosbie Fitch crosbie at cyberspaceengineers.org
Thu Sep 11 20:25:01 CEST 2003


From: J C Lawrence

> That doesn't solve any of the core problems.  You are relying on
> emergent user popularity metrics to implement what you assume will
> be an emergent approximation to a globally unique namespace, while
> ignoring the fact that you've implemented no way for a new object
> sharing the identity of an older and necessarily more popular
> object, to overtake the older object's popularity as you also have
> no way to explicitly specify an exact version and implementation
> of an object.

The name of a 'shared file' is equivalent to (encodes) the fractal
address of a region of 3D space.

Anyone can produce a file to define a particular region. No one can
delete that file except its creator, though people can choose to
view it, copy/adopt it, and share it.

Obviously, there will be several files vying to be considered as the
'preferable' definition of the respective portion of space. Some
good, some nefarious. Some old, some new. Some sparse, some dense.

A user can adopt whatever policy they fancy, e.g. I'll prefer the
version that is most popular among other nodes in my vicinity. OR
I'll prefer the latest dated version that is signed by an artist in
my 'list of favourite artists'. Or the 'Wiki' policy, i.e. I'll use
the latest version whether it's graffiti or not, and revert on an
'as necessary basis'. Or, I'll always prefer my own versions, but
will take the most readily available otherwise.  Or any combination
of the aforementioned or anything else you can think of.

What we now have are people (very sophisticated computers) able to
refine policies for selecting preferred content from a variety of
alternatives.

> The catch her is that once you have a way to explicitly and
> exactly identify particular versions and implementations of
> objects, you then have a global namespace which is _attempting_ to
> be unique.  The problem is that guaranteeing that uniqueness is
> non-trivial.

I don't think I've understood you here... :(

How can you have a global namespace that isn't unique? If it's
global then surely it's its own universe and by definition unique?
Though I'm only taking a stab at the semantics here, cos I never
knew I was attempting to create a 'globally unique namspace'.

> Now, much as Hans mulls, if you don't care about logical
> consistency and relation among your objects, and the retrieved
> items are equivalent to NWN's compleatly standalone and discrete
> worlds things get easier, but they don't solve.

> Consider the simple case of you and your friend Bubba both
> standing in the same game world segment and busily hcatting
> in-game.

Wow. For a moment there I was beginning to think 'I really need to
brush up on terminology'. 'hcatting' sounds cool and sophisticated
in a techie sort of way, e.g. "Fl3x0r and I were .htacc'ing the
other day..."

> You both (near-)simultaneously transition a boundary into a new
> world segment.  How do you guarantee that you both get the
> self-same new world segment?  What guarantees that you both
> retrieve the same version of the same object for the new world
> segment?  He might get one version, you may get another.  How does
> that work for communal play?  How about if you then ask Boffo to
> join you in this new world segment -- how do you ensure that he
> gets the same one you do?

Oooh. I can see I should've mentioned this...

Solar Systeme Segundo is viewed/explored/modified in the large from
a single user perspective (as a god).

It's a bit like invisible ants (each unaware of the other) creating
an ant colony. To a single ant, apart from their own activities, the
rest of the construction happens as if by magic, by unseen
hands. The user need not necessarily even be manifest as an avatar
in the world. It depends I guess on whether you wish to explore or
modify.

In other words, the massive 3D world generally appears like a
disease wiped out all life on the planet and left only the lifeless
landscape and uninhabited cities.

However!

Any section of the world can be (transparently - if we're lucky)
exported as a 'level' for play in Quake/Unreal/Halflife, etc. And
any one section of the world may have umpteen 16 or 32 player games
occurring simultaneously. Think of SSS as a better 'map'
browser. Indeed, there's no reason why live statistics of these
games can't be overlaid in the god-mode viewer.

Moreover, because this colossal 3D world is public domain, there's
nothing stopping it from being imported wholsale (or in part) into
any MMOG engine (that can cope with it).

The point about SSS is that it's a FIRST STEP. It's a pretty trivial
coding task (in the big scheme of things), certainly compared to the
coding required for the kind of system necessary for a fully
interactive P2P MMOG.  But, hey. Let's walk first.

> Do you overlay the protocol with invitation mechanics so that
> collisions are usually accidental but nodes can explicitly request
> ObjectFoo from PlayerBar, thus guaranteeing that they get the same
> object that PlayerBar has?  Instant DoS recipe and pity the poor
> guy on dialup.

Nope. Though it's an idea for a file selection policy, e.g. I prefer
files that are popular with my buddies (in my buddy list).

> If you add PKI or another strong identity system into the mix it
> can be done as that in turn defines a globally unique namespace
> (the identities) and thus allows definition and specification of
> globally unique dependent objects.

Hmmm. I think this ventures into interactive P2P MMOG
territory. Need more space in my Outlook editing window for
that... :)
_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev



More information about the mud-dev-archive mailing list