> From: justin@dsd.camb.inmet.com (Mark Waks)
> Subject: Re: VRML MUD's & Interaction
>
> Linas posts a long examination of some of the issues involved in running
> a "cyberspace" MUD. I'd like to make one easily-overlooked point: there's
> nothing saying that the MUD and the pages have to be the same site.
Yes. Good point. I was assuming that the MUD would be at one site,
the pages spread out wherever, and that only those pages / container nodes
at the MUD site were editable. It seemed simpler to follow that train
of thought first. But in terms of "where we want to be", it is limited.
The beauty of www is that it isn't client-server, but is client-broker-client,
where the author and reader are the "clients", and the www mechanism is
the "broker". As you hop from one URL to another, you hop from one
www server to another. This needs to be preserved.
> So, an alternate concept to chew on. VRML pages are just like HTML pages,
> spread all over the Net, defining a "space". MUDs are programs that you
> plug into on some systems, which behave much like current MUDs, except
> that they track which URL you're in, what your motion is, and so on.
> Your browser is responsible for synthesizing this: taking the page that
> you're in, and combining that with the information (probably also VRML)
> being sent from the MUD which describes the other people and "things" that
> are present in that room. The MUD doesn't *edit* the page at all, it just
> adds to it. (And maybe makes some temporary transforms -- for instance,
> if I grab a chair and sit down in it, I probably move the chair, and the
> MUD tracks that, and reflects it for all the other people currently in
> the same room with me. But a non-MUD-user (or someone in a different MUD)
> would just see the chair in its normal position. The chair hasn't changed,
> but the MUD has applied a transform visible only to the people using that
> particular MUD.)
Hmm. There are some concepts there that are new to me. If I translate
what you are saying:
-- there is a static, empty place: http://hoohoo.mud.net/kitchen.vrml
-- there are multiple copies of this place, which all look alike
("parallel universes"), and are populated with different people.
-- When you attempt to enter http://hoohoo.mud.net/kitchen.vrml,
you will be
a) asked which copy you want to enter ("I want to enter the one
where Joe Palooza is hanging out in.")
b) you are automatically put in the first one that isn't full
c) whatever -- up to the owner of hoohoo.mud.net to figure out.
-- When you actually enter one of the muds, you will be in
http://hoohoo.mud.net/kitchen.vrml/i(6), if for instance, you
are in the sixth instance.
-- Whenever one of the copies empties out, the copy ceases to exist.
If there was a chair that was moved -- well -- that ceases to
exist too. If you left a bauble behind, or your purse -- well,
that's gone too. Hope you kept a copy for yourself.
> I'll point out, BTW, why this mode of operation is important. If we're
> *really* about creating cyberspace, then we're talking about melding
> the Web with MUD ways of looking at things. That implies that your MUD
> doesn't have walls -- you should be able to explore *all* of this new
> Web in a MUD-like way. (At least, this is a goal I'd like to shoot for.)
Well, certainly, you can fill the (master) room with bric-a-brac
that are URL's to distant machines. You don't have to do anything
special to do that. (There is a problem of "editing" a chunck of
bric-a-brac, but thats not a multi-moo problem.)
And if you leave one room and go to another,
you would be (for instance) leaving the mud server at hoohoo.mud.net,
and enter the one at foolhardy.enterprises.net, which would be running
on physically different machines. I don't see why this couldn't be
visually seamless (if your pruning/culling software was up to it,
and you had the cycles to draw all those polygons.) And off-hand,
I don't see that you have to do anything special to enable this,
assuming you've solved the mono-moo problem.
> Problem is, some pages are *very* popular. What happens to, say, the
> music-archive room when there are 10,000 people in it? If we have
> firmly linked the room to the MUD 1-to-1, it's going to be unusable.
> But if a MUD essentially just defines *who* you're talking with, you
> could have dozens of separate MUDs. Each could get to the music archive
> room, but you'd only encounter the people in *both* that MUD and that
> room, rather than everyone using that room at once.
Well, now, that's a harder problem.
(1) The room couldn't contain 10000 virtual people because you couldn't
see anything because of the overcrowding. Unless they were the
size of fleas. (Ha, can you imagine 10000 fleas yelling at you if
you accidnetally walked in full-sized? "Hey you, siddown")
(2) Soo -- two possibliities:
(a) Create 1000 "parallel universes", each with no more than 10
participants. Somehow, you want to have these copies not all
run on the same machine. For this to happen automatically, you need
a mudserver-to-mudserver protocol where one mudserver says to the other:
"here is my empty-room (master) URL. Please copy it. I will tell
client Gzwyzzyx to go to you (by sending him the URL of your copy)."
(b) Allow 10000 flea-sized people in one room. Since they are flea-sized,
you can't see them, so position updates and shape changes do not need
to be broadcast. If you give the room sound-proofing, (i.e. don't
allow them to add sound-URL's to the room), then you don't have to
broadcast that either. So what the heck are 10000 people doing in
one room, if they can't be seen, and can't talk? Watching/listening
to a rock concert. And that can be handled by MBone VRML transmissions.
All that without overloading the server. (other than the question,
"Can MBone handle 10,000 listeners?")
> Essentially, by breaking things up this way, we allow the entire Web
> to be used as one seamless "MUD", while not collapsing under the weight
> of the millions of users on it,
I think we can do this. Now that I've thought this through a little,
I think the hard parts lie in the single-mud case. Once you have that,
I think it won't be hard to do the above. If you ignore the overcrowding
problem, then I think you don't have to do anything extra to get seamless
multi-muds once you have a single mud set up.
(There is a problem with login-log-out as you move from MUD to MUD,
assuming that MUD owners want you to log in before they let you in.
But it's possible that this could be solved under-the-covers, with a
hidden exchange between the client program, and the mud-server, which
the user would never be aware of. In the earliest implementations,
of course, this would not be under the covers, but I don't see
this is so bad.)
> because each "MUD" is really a collection
> of users wandering this world. It has its disadvantages, but I think that
> they are significantly outweighed by the advantages.
Hmmm. Naively, I assume that this "collection of users" (rat-pack)
would all leave one mud at more-or-less the same time, but individually,
and go to some other destination more-or-less the same time, individually.
Now maybe there is some stunt where all of them could jump into one
conatainer, and that container would move, but that's kind of weird to
contemplate (at this stage of the game).
>
> -- Justin
--linas