Subject: MUDs, etc.

From: [email-masked]
Date: Tue, 1 Sep 1992 00:05:32 -0700

Regarding the recent postings about MUDs:  I'm the first to admit my lack of
experience in the subject, but to me it seems like MUDs basically ARE chat,
with some geographical structure to them.  I've heard references to the
ability to construct objects, but no concrete examples of what objects have
actually been constructed.  If such objects are at all easy to manage, why
can't MUDs subsume other computer-assisted communications functions (e-mail,
database, etc.)?  Are there examples of systems that do this?
I hope my tone doesn't come off as hostile.  I like the idea of MUDs as an
overall architecture for computer communication.  I'd just like to know of
some applications of the idea.

---

From: [email-masked] (the piano has been drinking)
Date: Tue, 1 Sep 1992 13:23:17 -0700

> with some geographical structure to them.  

This is basically true about the _implementation_ of MUD systems. Very
basic, wrap a growable database around chat.

The thing that makes MUDs stand out IMO is their _usage_ by users, who
infuse the system and their environments with their personalities. I
don't know of any other shell environment, from /bin/sh to any X desktop
I've ever seen which so accomodates the user.

> I've heard references to the
> actually been constructed.  

Well, how about an object called "change purse", which a user uses to
carry "coin" objects. The change purse can have a physical description,
a function (to act as a container for coin objects) and certain actions
associated with it ('remove' as in "remove a nickle from the change purse").
(necessary in TinyMUCK, which doesn't have built in interfaces for handling
containers very well...)

Another example is one I am working on right now, which I call a "silly 
bomb". The silly bomb looks like a hand grenade. There is a "pin" to pull
to prime the bomb, there is a "fuse" which ticks off the seconds till the
bomb "explodes". When the fuse activates, the silly bomb goes off. What 
the silly explosion does is go through and twiddle the descriptions of
all players and objects in the room exposed to the "blast". For instance,
a person carrying a flashlight will discover they are now carrying a
banana. A person whose description of themselves says, "Blah blah is
about 6 feet tall, male, wearing blue jeans and an old long sleeve shirt
rolled up at the sleeves" will now appear to the others in the room as
"a somewhat dazed gerbil like creature with pink stripes down the length of
the body."

These are rather frivolous examples, but the intent of objects is that
anything that can exist in RL can also be modeled in VR. (although one
never reads about "silly bombs" going off in Lebanon...

> If such objects are at all easy to manage, why
> database, etc.)?  

They can. And they will.

> Are there examples of systems that do this?

Yes. I already described a MUF/TinyMU* implementation of a full blown
BBS and e-mail system inside the MUD. I would actually implement it
differently myself, and create new kinds of MU* commands specifically
meant to interface with RFC822 documents in mail or news spool files,
but such things will come to pass sooner or later.

> some applications of the idea.

Not hostile at all. Basically, we are all in the job of networking
people. MUDs are able to model 3D RL and able to provide a user
environment which some users, particularly the newbies our system (cruzio)
is trying to reach out to, seem to find less threatening and easier to
utilize than something like A> C> or $ or # or % or tcl> or whatever
else, including menus (believe it or not..).

Aside from all that, there is something else, the ability to create
and move and sing and dance and smile and look funny and be oneself, 
which really attracts folks to MUDs as communications interfaces.  
And that's what this is all about.

ccn

-- 
		"If life were easy, everybody'd want to do it."
		       -Knuckle Buckalo

	             [email-masked]

---

From: [email-masked] (the piano has been drinking)
Date: Sun, 6 Sep 1992 09:55:20 -0700

> In response (again) to Carl's ponderings...
> Regarding the recent postings about MUDs:  

More on MUDs, and specific examples of how they can be used for community
access systems for computer aided human <-> human networking...

The ability to specify actions (also called "exits", i.e. an exit 
takes you from one room to another) is the same as the ability to
create menu hierarchies. For instance, the same capability in describing 
a room as so:

The Lobby Of Club MUD
+
You are standing in the lobby of Club MUD. There is an open door to the
west leading to the Sysop's Office, a door to the south which goes into 
the Library, and a sliding glass door to the east leading out to the garden.
+

Can also create a menu interface as so:

Main Menu

(s)ysop
(l)ibrary
(g)arden

Enter your choice or (h)elp:

In looking through quite a bit of the TinyMU* strain of MUD code, it
appears that the MUD server is basically a socket and database manager.
Therefore, with a small amount of effort (if it hasn't already been
done) it would be possible to extend the @commands to provide a generic
@exec capability, or, maybe better, to create a certain kind of object
for external processes, i.e. mail or rn, and provide a way to link an
exit to it. Thus, the interface would be completely moldable using standard 
MUD commands to either a common MUD interface (what we used to call the
"Adventure Shell" at SCO, i.e. "throw file at printer") _or_ a menu interface
as shown above.

Those who have used the conferencing software called "Caucus" are 
familiar with this concept, as the Caucus software provides a message and
conferencing engine with an excellent capability to mold the user inteface
in much the same way, albeit not dynamically as a MUD does. (and not as
RFC822 networkable as one would want without the Pandora extensions...)

Connecting sockets to external processes is sort of a kludge, because the
MUD can't really be said to subsume the extra services. For instance,
I as sysop would not be able to "follow" someone into mail and "watch"
them as they "show" me some problem they are having with the mail engine
or interface, "conversing" with them or "coaching" them as we cooperate
in solving the problem. Since our system is actively trying to bring more
"clueless newbies" onto the Internet, and I as an individual have to 
work a day job and help raise a child, this kind of approach to "outreach"
is very valuable. I can "meet" the user, "converse" with them, "show" them
how to do things, then "look over their shoulder" as they get the hang of
it, without leaving the kitchen at home where I am looking over my 5 month
old. In our MUD, I am able to do this. So far, I've had some folks stumble
into my "office" during "office hours" and have been able to "coach" them
in ways far superiour to the normal e-mail or even voice over phone 
communication (remembering that most folks only have one phone line at
home, so can't modem in and have a voice conversation at the same time).

All the "" above is meant to signify where real world abstractions are 
modeled by the MUD.

So, just more blather about using MUDs as platforms for community access
systems. I really do think they are the neatest thing since cheap RAM,
of which they seem to require a lot...

ccn

---

From: Frank Hecker <[email-masked]>
Date: Mon, 7 Sep 1992 12:30:23 -0700

[email-masked] (the piano has been drinking) writes:
> You are standing in the lobby of Club MUD...
> 
> can also create a menu interface as so:
> 
> Main Menu
> 
> (s)ysop
> (l)ibrary
> (g)arden
> 

This is an excellent point, and deserves further expansion.  Suppose
we start with a conventional menu-oriented public access system like
the FreePort software used in the Cleveland Freenet.  We then emulate
this menu structure in a MUD as described above.  (In fact, Cleveland
Freenet already attempts to provide a surface impression that it is
based on a geographic structure, so this is not as big a jump as it
might be.)

What have we gained thereby in terms of new functions?  At a minimum,
the ability of users to detect the presence of others when they are in
the same area (e.g., in the "library" system) and the ability of users
to converse with each other in a natural way, thus allowing a basic
chat capability between users whose presence in the common area would
indicate they might have something to talk about.

Going further, you could create new areas/menus using the MUD
facilities, although actually creating new functions would require
both MUD programming and a way of accessing the "outside world" as
discussed below.

> "Adventure Shell" at SCO, i.e. "throw file at printer") _or_ a menu interface

I am a little confused by exactly what you are proposing here.  It is
true that a simple @exec capability would allow a non-MUD _non-
interactive_ command to be seen as a MUD command; e.g., "throw file at
printer" might map to "pr file | lp" for a UNIX system.  However as
you note below, this would not solve the more general problem of
providing a full MUD interface to an interactive program such as mail
or rn; you could enter into the program in a MUD-like way, but once
into it you would be thrown back into the native command structure,
and moreover would lose the MUD chat capability.

> in solving the problem.

There is at least a theoretical way to do what you want to do here.
What you would do is have the interactive program run in an external
process, and then create an intermediate program which "talks" to the
interactive program as if it were a "real" interactive user.  (Public
domain code to do this in a general way is available in the expect
software created by Don Libes of NIST.  This is similar to the Remote
Terminal Emulators many computer vendors use for benchmarks.)

This intermediate program would accept MUD commands and translate them
into the appropriate commands for the interactive program, so that the
user would never see the underlying command set; it would also
translate output into MUD terms.  In effect it would put a MUD object
layer over the program, with MUD chat and related capabilities still
available.

Of course, whether this scheme is actually practical in real life is
an open question.  The mapping may prove to be so difficult that it
may be easier to provide a true MUD-based implementation of the
function. 

> Since our system is actively trying to bring more

Exactly.  I would add that in theory one user could help another
rather than a sysop helping a user.  However, since this depends on
the one user being able to note another user's actions and whereabouts
in the system, there are significant privacy issues that arise.  One
compromise would be to only allow sysops to "eavesdrop" in this way,
and only at the user's invitation.  Another would be to allow
unrestricted interaction in social areas and limited or no interaction
in other areas.

Frank

-- 
Frank Hecker
[email-masked]

---

From: [email-masked] (the piano has been drinking)
Date: Mon, 7 Sep 1992 13:35:46 -0700

> may be easier to provide a true MUD-based implementation of the

I think I found a way to do this.
There are several MUD source code depositories on the Internet, and
I just got back from a jack with some code for MUD robots. One of the
ideas I had was for a robot I call the "weather god" which would connect
to a MUD as a player with wizard/god privs, and just keep watch of the 
time. At certain specific times, it would then race through the MUD 
database changing the descriptions of things relative to the "weather",
i.e. position of sun or moon, is it raining, etc.

An extension of this would be a "mail god" or "news god" which would
monitor user MUD commands in the "post office" or at the "news stand",
and go out to the correct mail and spool files and programs in the way 
you describe above. 

Thus, the robot would supply the MUD like interface to both the MUD
server and the user it would be interacting with, and have a backend
which manages the mail and news files.

Since the user is in a "room" during the entire transaction, they
can chat with others during the entire time, as they are composing
and addressing or reading and browsing news and mail.

Eh?

ccn

---

From: Frank Hecker <[email-masked]>
Date: Tue, 8 Sep 1992 18:46:27 -0700

> i.e. position of sun or moon, is it raining, etc.

Neat idea, and of course extensible to monitoring any type of event
outside the world of the MUD, given the appropriate external
interface, and then causing things to happen in the MUD as a
consequence.

> which manages the mail and news files.

I can see where a "mail god" or "news god" could autonomously monitor
incoming mail or news and make it available within the MUD as it
arrived, analogous to what the "weather god" does.  Do you see this
same agent as handling user requests in the MUD itself?  Or would it
make more sense to have a different type of object doing this?

> and addressing or reading and browsing news and mail.

Yes, this is an advantage.  I would extend this though: is it still
too restrictive to require someone to go to a special room to read or
send mail?  Would it be preferable to implement a portable object
(i.e., which people could "carry" around the MUD) which could be used
to compose, send, and receive messages?

You're right; fun stuff this is, thinking about how to make best use
of this new medium.

Frank

-- 
Frank Hecker
[email-masked]