[MUD-Dev] Seamlessly Distributed Online Environments

Crosbie Fitch crosbie at cyberspaceengineers.org
Wed Sep 17 00:09:35 CEST 2003


From: J C Lawrence

>   If you don't include some for of PKI you have no way of
>   explicitly retrieving a specific file on the first request.
>   Even worse, as you can't trust the data the remote node is
>   sending, you have to recompute the signatures and re-request on
>   failure, making requesting a specific file a potentially
>   infinite operation (as you also have no valid promise that it
>   even exists to be requested).

You're right, though I don't know why you're labouring this point. I
really don't think there is a requirement to retrieve a specific
file on the first or any request. There is an expectation of a
tendency to receive one or more files having the same name, but
different meta data, and different content data.

There is a only requirement to retrieve a file with a specific
name. It doesn't matter if the file contains garbage. This is weeded
out.

Have a look at how p2p file sharing systems work. It's trivial.

> Now add a shared world system with exploration mechanics and it
> breaks as there are no guarantees of shared experience without
> making point to point transfers instead of P2P or suffering
> potentially infinite retrieval times.

You add it if you want to. I'm not surprised it'd break down.

However, if it's not multiplayer (in the large), because each user
is alone in the world, then there's no need for shared
experience. Each user is unaware of all the other exploring
users. UNTIL they decide to 'drop down' and join a Quake map
generated from a particular part of the world, and have a guaranteed
shared experience with a couple of dozen others.

>> If players are involved in validating the files, the bad files
>> will tend to get weeded out (including those with bad meta data).

> I'll cut this short: You haven't thought this one through.  The
> math is not hard.

Hmmm. Yup. I think I've thought it through. Nothing you've said so
far seems to amount to a patent demonstration of
infeasibility. Well, it may convince others...

Anyway. What 'math'?

> Some tendencies head that way, not all, and there are no
> guarantees that the population will be well normed.

Who needs guarantees?

You want guarantees, you use the client/server paradigm.

>> The meta data provides the distinguishing information (valid or
>> not).

> Also unverifiable prior to receipt.

Yeah. That's why I said 'valid or not'.

If it's bad information, it's bad. Reject it.

If you download a bad/misnamed MP3, delete it. It's not rocket science.

> You can add trust mechanics to attempt to vet nodes which lie, but
> that's an asymptotic affair which selects heavily against
> new/unknown content over entrenched favourites, especially if you
> also can't trust nodes to perform their own veracity calculations.

Yes, but I doubt this would be required in the early
'proof-of-concept' stages. Just as file sharing seems to be doing
fairly well without trust mechanics.

>> If the player subsequently discovers that "I've seen this before,
>> this ain't new!", or "No way is this Bill Smith's style", or "Who
>> put bloody coke cans on all the ice floes?" then the player will
>> do their dutiful bit of altruism and revert to the previous file
>> (or a better one). It'll just be a keystroke or two.

> How can they, reliably?

Who needs reliable?

It's thermodynamics. If the amount of value I get out (despite the
noise/garbage) outweighs the effort I put in then it's worthwhile. I
don't need reliable, I just need 'good enough'.

>> If more than a few percent of file sharers were the enemies
>> they're made out to be then file sharing would have collapsed
>> immediately. RIAA simply cannot afford enough stooges (computers
>> or people) to pollute the MP3 file space faster than it's cleased
>> by the users.

> In an MP3 world that hardly matters, in a game world of direct
> interactive participation vs store and forward timed delayed
> enjoyment it does matter.  As a player when I walk my character
> three steps forward from Castle Krak I not only want to end up at
> the same place each time, but I want all my friends and their
> friends to also end up at the same place (assuming no warped world
> game mechanic).

This happens when you've 'dropped down' to a Quake map. Whilst
you're in solo god exploration mode the whole universe is in flux
(albeit unpredictable wholesale step changes to various parts). Have
you ever seen the movie Dark City?
(www.imdb.com/title/tt0118929/plotsummary). Perhaps it would be
disconcerting to one day wander through a mountain range, and the
next day discover that someone had built Casino City there? But hey,
it's free. You get to do what the hell you want to as well, and
world scenery is selected on a meritocratic basis. Yes, some users
may not see Casino City because they've black-listed that particular
artist, but consistency is not necessarily an a priori requirement
of a virtual world.

> This thread started with your advocating a P2P transports for a
> shared world server.

Yes, I just thought I'd drop a couple of lines suggesting a p2p
system such as Gnutella instead of a central database.

It was when you then proceeded to challenge that modest suggestion
with a treatise on how it would create more problems than solutions,
that I felt that perhaps I should elaborate as to how I envisaged it
being feasibly utilised (if only to save you from creating straw men
to shoot down).

Philip Loguinov, the thread starter, expressed an interest in being
able to display an arbitrary 3D environment, and for users to be
able to wander about a city and 'seamlessly' travel between
buildings that may be hosted on different machines.

He didn't mention a requirement for 'shared experience' or PvP
interaction, so I don't feel I've stepped outside the thread
remit. Indeed, he expressed an interest in whether 'anyone was
already working on something like this'.

>> Nope. This is social cybernetics. The identity aspects are not as
>> important if identity failure can be repaired. Ask RIAA.

> RIA is not dealing with both latent and simultaneous shared
> experience mechanics.

It's dealing with the mechanics of users simultaneously and latently
sharing MP3 experiences (and in the process infringing
copyright). It has attempted to pollute the MP3 filespace and failed
to do so sufficiently to impact the system's usability.
_______________________________________________
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