Subject: MOO network clients

From: [email-masked] (sweet william)
Date: Thu, 6 Aug 1992 09:13:39 -0700

I was interested to read Glen Daniels' suggestion about a MOO 
IRC client, and was wondering what the MOO community at large
thought about extending MOOs to talk to outside network sources:
is this a sufficient and viable interface to all the services
the internet can provide?  Will people be interested in going to
the trouble of learning MOO to use its interface to speak out
to the net?
I slant my question given this observation: it seems from the
discussion I have witnessed so far as tho there are people out
there who are toying with ideas to make MOO a 'workplace' for the 
'state of the market' users...those people who wish to use internet
services available NOW in an intuitive and 'no brainer' environment
rather than a cool experimental platform.  
Obviously, the experimentation to make MOO do this has academic value 
for those of us who think that hacking network apps. is fun :)
But is there anyone who will be using this stuff when we are done?
Does anyone care?

Later
dr "@" lambda

---

From: [email-masked] (Glen Daniels)
Date: Thu, 6 Aug 1992 11:54:23 -0700

>the trouble of learning MOO to use its interface to speak out

	Well, I don't know if MOO (or muds in general) as it stands is
the right interface to use, but I think the "shared virtual
environment" paradigm is a good one.  I would guess people will be
more willing to play with different objects in a simulated world than
to learn lots of heterogeneous command sets for various network
clients.

	I think there are some usability problems with the current
MOO/MUD interface.  One of the biggest seems to me to be the lack of
an easy way to play with objects without trial-and-error or @examine.
It would be nice if there were a simple way to get an object to tell
you "what it can do".

	I think a GUI client could really help here.  Such a client
could ask objects if they have a "@bitmap_appearance", and if so,
throw up a graphical depiction of the object.  Objects which didn't
have a graphic could have a default picture.  You could have a screen
area for your inventory, and drag 'n drop objects from the "room"
window (which, again, could either be graphical or a default picture
with a text description) into your posession, or vice-versa.  You
could have an "exits" menu which would take you from room to room (or
some exits could also be represented graphically and mouse-clickable).

	Now here's the interesting part.  By selecting an object,
you could bring up, say, a menu of verbs that object allows you to
utilize.  Then activate a method by clicking.  This, I think, would
remove a lot of complexity and clunkiness from the interface.

	Heading in this direction does not actually even require a GUI
client per se, just a shift in thinking about interfaces to muds.  The
"text adventure" style of parsing commands just isn't flexible or
friendly enough right now, and it probably won't be until some major
work is done on the natural language front.  But adding the ability to
have a more "cybernetic" interface, without the pretense of "language
parsing", might make mud-style worlds easier to use. [caveat: I'm
coming at this from the perspective of wanting to eventually make
shared-world interfaces useful for everything one might want to do
with computers]  For instance, you might add another command character
"*" which "selects" an object for you in a text-based client, and
another, "/", which executes an option on the currently selected
object, for instance:

You are in the study, a comfortable room with oak paneling.
You see a cast-iron safe here.
>l safe
A fairly ornate specimen, this safe must weigh a ton!  It looks very
secure.  A dial is set between two horses carved on the front.
The safe is closed.
>*safe
			--* cast iron safe *--
	[O]pen safe
	[C]lose safe
	[T]urn the dial <Left/Right> <1-100>
	[S]pin the dial, scrambling it
	--------------
	[H]elp
	[I]nformation about the cast iron safe
[at this point, I can still type regular commands, but any '/' will
refer to the safe, which is now selected.  Also note that there are
other methods I can apply to the safe (look, take) which are not in
the menu; could work this way or not.  There are a lot of ways to do this]
>/I
cast iron safe (#1332) is owned by DrFunky (#324)
Aliases: safe and cast iron safe
[etc...]
>/T left 100
You spin the dial to the left, stopping at 100.
You hear the unmistakeable click of a tumbler sliding home.
[You get the idea...]

	The "menu of verbs" idea actually is only the simplest form of
a more general idea of "Object Controls".  In general, objects allow
themselves to be manipulated in a variety of ways - these could be
expressed by concepts such as method-menus, analog controls (dials,
sliders), digital controls, buttons, etc... (sounds like a
window-management system, doesn't it?).  Focusing on an object in a
GUI client could bring up its control set (a dial for the safe might
appear, and a handle for opening/closing it), which your client might
allow you to "tack" to your screen somewhere, so you can use it easily
while changing your focus....

	Just some ideas I've been playing with.  Does this seem like a
reasonable direction to be heading in?  I haven't really spent enough
time exploring yet to be sure....

			--Gub (Glen Daniels, [email-masked])
	"The future exists first in Will, then in Imagination, then Reality."

---

From: [email-masked] (Frank Crowell)
Date: Thu, 6 Aug 1992 13:04:02 -0700

Clients-- the often forgotten partners to the MU*. 

There are some graphical clients out there; and Habitat made
heavy use of a graphical client.  But if MU*s are the ugly brothers
to Virtual World/Virtual Realities researchers, clients seem to be the ugly
brothers to MU*s.  

If someone is really interested in experimenting in this area, consider
taking a programmable client (not tinyfugue) and put some hooks into
your favorite GUI. Then build a few rooms and some objects.
Actually a lot of things can be done without any changes on the server
side; but it would require some pattern matching.

Sometime ago I got a flyer from either Compuserve or Genie proclaiming
the FE (Front End, as they are known there) as the hottest way to
interface into multiuser games. FEs work out reasonable well in
a known universe and can actually reduce the traffic between 
server & client. 

-- 
Frank Crowell [email-masked]
[This Space for Rent]

---

From: Judy Anderson <[email-masked]>
Date: Thu, 6 Aug 1992 13:15:00 -0700

I don't know if it's been advertised here yet, but waffle on LambdaMOO
has built some MOO code support for color coding messages for those
without good client support.  I think you have to be using some PC
running DOS or something, and you change your character map locally so
that tilde (~) gets turned into escape (which MOO won't print), and you
get pages in red, whispers in yellow, etc.  I don't know the details
(not being a PC user and preferring emacs-based interfaces) but I think
waffle has written doc.  Is waffle on this list?  Care to advertise?
This is a little far afield from the original topic, I admit.

						yduJ

---

From: [email-masked] (Frank Crowell)
Date: Thu, 6 Aug 1992 14:02:59 -0700

Actually yduJ really presents what is holding up
any extensions that require better clients: writing to the common (lowest)
interface.  The other day, I was on some mud, and someone asked
me if i could see the rainbow.  I didn't know what he was talking
about.  Apparently there was some text changing colors; possibly
a cute idea; I'll never know, since my terminal is monochrome (amber on black).
Another example, PMF (clients) allows certain pre-packaged sounds;
I don't know what those sounds are since I don't have sparcstation.

Now I suppose I could have changed to my color system with the 
soundblaster, but I still wouldn't be able to hear the PMF sounds.

Common interface: writing to the common interface may not be as
silly as it seems. Practically every terminal maker, computer system
maker provides vt100/220 emulation. In the 80s many of us wasted
our life away playing rogue. Didn't you just hate 'R' at about
level 8? There are a lot of things that could be played with
just using the escape sequences. 

Standard and Enhanced interface: a better way is to write to standard
interface and require that the clients do their best. Then I would
add the Enhanced level and require that the enhanced clients
conform to this level. This is routinely done in the computer
graphics world.

---

From: Doug Orleans <[email-masked]>
Date: Thu, 6 Aug 1992 23:39:30 -0700

> the trouble of learning MOO to use its interface to speak out

I just wanted to point out that FMPL was designed for almost exactly this
purpose-- to provide a high-level interface for writing networking programs.
While it may not be any easier to use than MOO, it is certainly more
versatile in terms of what you can do with network connections, both
incoming and outgoing.  Instead of just being a mud with an
open_network_connection primitive hacked in, it is a full-featured network
programming language.

FMPL is available via anonymous ftp from xcf.berkeley.edu:src/local/fmpl.
There is also a mailing list for discussion: send mail to
[email-masked] to subscribe.

-- DougO, aka WhiteRabbit