>(are you Justin, or are you mark waks ???)
Both; Justin's the Net handle, and it's what I use for most purposes.
Not many people call me Mark, over the Net or in person. (It's a matter
of disambiguation, largely -- there are a *lot* of Marks in this world,
but relatively few Justins.)
>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.
> [...]
Not *quite*. For a better idea of my concept, look at Brian's description
of the work that Ubique is doing:
>They have written a specialized version of
>Mosaic, which has two extra windows added. In one window, you can talk
>(type) to anyone else who is concurrently "inhabiting" that page a la IRC or
>a chat system. In the other window is an iconic representation of all the
>users on that page - you can set your icon to be anything you want. This
>extra information is being sent over a persistant connection to a specialized
>Ubique server sitting on the same machine as whatever page you're visiting.
This is somewhat analogous to what I'm describing. (Indeed, I'm
intrigued to see that someone *is* doing this for Mosaic -- I was
wondering if anyone would try it out.) The key difference is that
I see no particular reason to have the server specialized, or to
have it at the same site. Data is data, and I'm hypothesizing that
*any* MUD "server" should be able to cope with the data from *any*
VR room.
Linas mentions, early in his message, the fact that the Web uses a sort
of "client/broker/server" architecture; my suggestion is make heavy use
of this. The real intelligence would lie in the user's client, which
would be synthesizing information from the Web and from the "MUD", and
sending what information is necessary back to the MUD. This might involve
talking to two sites at once, but so what? That's easy on the Internet.
One useful way of looking at this: the Web (in its VRML incarnation)
provides the *static* database underlying our "world". The "MUD" is
in charge of dealing with *dynamic* data -- the elements of the world
that have changed from this baseline, within a particular context.
(And there may be an indefinite number of these "contexts".)
Let's look at a scenario:
I sit down at my machine, and fire up my VRMUD client. It goes to my
"office" (my home page), fetching that from our local system, and
simultaneously connects to my VRMUD of choice, which for sake of
argument we'll say is run over on world.std.com. (This VRMUD is run by
my friend Eliz, and most of my friends are on it regularly.) The room
is fetched, and the VRMUD connection is established. My client tells
the server where I am in the room; the server tells it that there
isn't anything else different here. (That is, its database contains
nothing interesting about this room.)
I wander out into the "hallway" that I've built, and step out of that
into a lounge that's been set up over at MIT. As I do so, my client
continues to send updates on my position back to the server, which
continues to say that there's nothing interesting going on here.
As I step into the lounge, my client sends that information to the
server. The server checks that room and finds that others on this MUD
(say, my friends Rick and Gideon) are already in this room. It sends
back a set of tranformations to the room: Chair 1 has been moved and
turned slightly, and Gideon (whose "image" is sent) is sitting in it;
similarly, Rick is in Chair 2; and there is a board game spread out on
the table. My client takes this information, uses it to transform the
scene graph in some fashion, and displays this synthesized
information.
I pull back Chair 3, and sit down. As I do so, my client sends these
transforms to the server, which in turn records them and passes them
on to Rick and Gideon.
And so on. The server maintains a record of what has *changed* from
the baselines in its version of the "world" of the Web, but doesn't
keep any information it doesn't need. (For sake of keeping the DB size
down, it probably automatically "cleans up" rooms and objects that
haven't been touched in a while -- that is, it reverts them back to
their untransformed state -- unless some user has tagged the
transforms as long-term.) It requires a *very* intelligent client,
but I don't think that's an unreasonable thing to require, these days.
It's really a question of orientation. Some MUDs today are built
around the concept that the "world" is the important part -- the fun
comes from exploring that particular world. I think that the creation
of a robust, distributed cyberspace is going to weaken that a lot --
there will be a lot of pressure to make all of these "worlds" part of
a single "universe". What a MUD provides that the Web does *not* is a
social mechanism, a way for people to congregate socially on the
Net. This model for MUDs implicitly recognizes that as the priority --
the "MUD" isn't defined as a collection of rooms, but instead as a
collection of people in the universe of the Web.
Linas mentions the alternate model, where each site is essentially
a "MUD" for its own rooms, and we define a protocol for handing
people off from one "place" to another. I don't like this as much,
mainly because I don't think it's as practical. A lot of sites
aren't going to want to put up MUD-like interactions -- at best,
they're going to require an order of magnitude more bandwidth
than simply putting a few rooms up. The result would be that you
could wander some places in the Web with company, but many would
just drop you into a single-user mode. It's likely to feel rather
unnatural.
Also, the details of working out how to pass *objects* from one place
to another are quite tricky. Say I pick up a hammer in a room at site
A, and carry it into site B. Can we handle that? Does the hammer
permanently leave site A? (I know that *I* would be pretty leery of
putting rooms on a Web where I can't be confident of my objects
staying there.) It's straightforward in my VRMUD version -- the hammer
*does* change rooms, but only in that MUD's view of the world. Anyone
on a different MUD, or not using one, doesn't see that transformation.
Brian mentions some worries about scalability. I think it's clear
that one site isn't going to serve the entire Web; indeed, it's
unlikely that a hundred sites could. One would have to make sure
that the VRMUD server code was straightforward, and freely
distributable, much as some MUDs are today. We have to trust the
economy of the Net -- if it's popular but limited, more people
will put up their own MUDs. (One MUD wouldn't be able to serve
the entire Net today, either, but the hundreds that are out there
do pretty well.)
BTW, don't take any of this as an assertion that this scheme is
easy to implement. There are some real problems to address. But
I don't think it's any *harder* than the 1-to-1 mapping version,
where each site runs a "MUD" for its own rooms, and I think that
there are powerful advantages to it.
Note particularly that this requires absolutely nothing of the people
putting up the rooms -- any rooms added to the Web *automatically*
become part of this "Mega-MUD". It treats the "MUDs" as an entirely
separate layer, sitting on *top* of the VRWeb. This is a *very* powerful
advantage, and is analogous to how many of the more successful Net
"products" have worked. If you can make use of what's already out
there, but add significant value to it, the Net will beat a path to
your door...
-- Justin
Trying to promote a bit of paradigm-
shifting here...
Random Quote du Jour:
"As a person who works in a store, I really can't condone slaughtering and
eating salesfolk as a valid way of improving service."
-- JDN