Hi,
The previous notes brought up (again) the need to do a 3D MUD/MOO
where user's could interact with objects. I started looking into
that, below follows one possible train of thought; I try to stick
close to mechanisms provided by the web, (as opposed to sticking
close to DIS).
One does a MUD by having the web client send information back to
the web server; information such as the things a user is carrying,
the user's location, a pointer to a vrml URL that other people will
see when they look at the user.
The server keeps an up-to-date scene graph of all geometry,
locations of objects, etc. As a result of user requests, the
scene graph is updated (i.e. "edited"). A reply containg vrml
updates is sent. Other users are (somehow) notified of changes.
Mechanical Details -- Common Gateway Interface
----------------------------------------------
OK, how about some server-side mechainical details? I summarize
what's in http://hoohoo.ncsa.uiuc.edu/cgi/overview.html
The MUD operator has a program/shellscript/whatever, that they
give to thier Web server administrator, and convince them to put
into thier "cgi-bin" directory, promising no security holes,
trojan horses, etc.
The web server, when it receives an http (vrtp ???) request
for vrml data, auto-magically invokes the MUD program, piping
the http request to stdin.
This program reads from standard input a vrml-like protocol.
The amount to read can be found in the environment variable
CONTENT_LENGTH which the web server obligingly set for you.
(this is compatible with METHOD=POST in forms, although not
much else is).
It writes to standard output the following:
Content-type: graphics/vrml <carraige-return> <line-feed>
<line feed>
<some vrml reply...>
What is Sent by client to MUD
-----------------------------
Now, the hard part -- what to send, what to receive.
The viewer/player/client needs to issue the following, in vrml format:
o Thier current location and view direction. This can be handled
by sending a camera. I strongly suggest sending the focal distance
as well. This information is/can be useful for formulating a reply,
for instance -- doing server-side culling, or allowing other users
to look through your eyes.
o Thier current velocity. This is required so that other folks can
estimate a players position (e.g. via dead-reckoning) as a function
of time. The idea is that the network doesn't get consummed with
gazzillions of teeny position updates.
I also suggest a "damping exponent" and a time-stamp -- most humans
don't maintain a constant velocity forever, but stop, look, turn,
meander. The damping factor together with the time stamp say "well,
they were moving in that direction at that time, but that was a
while ago. We can only assume they stopped moving." Note that this
differes from DIS. If the damping factor is zero, then assume that
the constant velocity is being maintained forever.
o A name tag. "Hi. My name is Gwyzzyx. I am from Mars."
o An URL describing what the player/client should look like to others.
o Other, arbitrary, vrml. For instance, if the player/client has
picked up an object & is carrying it, it would transmit the vrml
describing the object and it's location.
In fact, it is very tempting to blow off the first four bullets,
and go only for the last one. However ... more below.
What the MUD Server Does with the Stuff it Receives.
-----------------------------------------------------
OK, What does the MOO server do with this vrml data that it receives?
One obvious answer is add it to the scene, in world coordinates,
to the root node. This has some pros -- its easy & obvious -- and
some cons -- what if I am swimming inside a fishtank, and someone
else moves the fishtank? Shouldn't I move with the fishtank (i.e.
shouldn't my vrml request have been added to the fishtank node)?
Another area which is not clear -- what happens if I add user's camera
to the root node? Will Inventor and/or OOGL gorp on this, or is it
benign? (That is, the scene has, say, ten cameras in it, representing
the positions & view directions of ten participants. Say this scene is
shipped out to one of the ten participants -- will this mess them up,
or will they have an opportunity to see how thing look like from the
viewpoint of other participants?)
Replace Semantics
-----------------
Above, I said "ohh, just add it (the incoming vrml data) to the scene".
Logically, though, its, "add it to the scene if I am a new player
joining the game; otherwise, replace whatever you have for me".
I don't understand either the inventor or web-oogl proposals well enough
to understand how this would work. Certainly, if one had an order-independent,
global-scoped system like OOGL claims to be, it would seem that re-defining
an already-named object would be synonymous to replacing it. Any truth to this?
For Inventor, it would seem like the following sequence would pile up at the
MUD residence:
DEF Gxyzzyz Separator { .... } # what marvin martian looked like at 7pm
USE Gxyzzyz
DEF Gxyzzyz Separator { .... } # what marvin martian looked like at 7:01 pm
USE Gxyzzyz
DEF Gxyzzyz Separator { .... } # what marvin martian looked like at 7:02 pm
USE Gxyzzyz
And so every time you went to draw this, you'd draw the space-time world-worm
for marvin (i.e. you'd draw him everywhere that he has ever been in the past).
(Right, or am I misunderstanding Inventor?) Since this is not what you want,
does this mean that one needs to invent a "replace" semantic for Inventor???
Reparent /Remove Semantics
---------------------------
Say player has joined the game at the root node, but now wants to reparent
themselves to another node. Or maybe they want to leave the game entirely.
How is this accomplished?
To remove oneself, maybe one can define oneself to be the empty node, and the
MUD server would recognize this & remove you. But how do you add yourself
to another node?
MUD Security
------------
The replace semantics also have a security issue: you don't want some kid
redefining some important part out of existance, yet you do want to allow
them to redefine themselves, and maybe some of the objects they created
along the way.
This requires objects to be tagged, at least internally, with thier owners.
(Owners can log in using forms at the beginiing of thier session.) Now,
you want this tag to be persistant -- i.e. you want it to last forever.
You also want to do periodic backups of the MUD to disk. You want those
backups to be written in pure vrml, (as it would be insane to write out
anything else). Ipso facto, that tag has to be part of vrml.
Inventor has a thing called "Info { ...} ". It was not clear if you could put
Info into a separator, and expect it to stay there, and not migrate. Gavin
asked if some fields in Info should be standardized. The above argument would
indicate yes. I'd propose, using myself as example:
Owner: linas (my unix system logon name)
Domain: innerdoor.austin.ibm.com (my host machine; if I ever leave IBM, I'll
have to change this to a more permanenet address; hopefully,
domain spoofing will be a common & established technology by then,
so that I can be, forinstance, [email protected],
no matter what my actual, physical machine might be at the moment.)
Password: * (OK, everybody's password will be * which means "use crypt and look
it up in a secure file". But having this field at least leaves open
the door to using a diffenerent password mechanism, e.g. kerberos,
which might be indicated with Password: K or PGP or whatever ).
Title:
Date:
Author:
Expiration Date:
Copyright:
Disclaimer:
I do not know what corresponds to Info {} in WEB-OOGL
The Reply Sent
--------------
The reply is clearly sent in vrml. All the same questions about replace-semantics
apply at the cleint side. Dumb MUD servers might attempt to send the entire scene
over again. Smart MUD servers would send only deltas.
The tricky part is that, of course, the player wants to see updates to thier
environment (as others move about & do things) without having to explicitly
request for them. That is, we need to avoid having vrml clients polling the
servers every few seconds: "send me the latest scene".
I'm drawing a blank, here. Somehow, MBone seems like it could be important.
I'll try to learn more about MBone in the next few days, and summarize the
results. (anyone know of a good pointer to a motherload of MBone info?)
--linas