[MUD-Dev] RP=MUSH/PG=MUD

[Nathan Yospe]

On Sat, 21 Jun 1997, Caliban Tiresias Darklock wrote:

:On Fri, 20 Jun 1997 19:13:08 PST8PDT, "Jon A. Lambert"
:<jlsysinc at ix.netcom.com> wrote:
:
:>I think good user interfaces are very important.  I am working on GUI 
:>interfaces for players, builders and administration.  This is still a 
:>text mud server wrapped in a GUI and not a graphics mud in the sense 
:>of something like Diablo or Quake.
:
:This is my own personal view on the matter of building interfaces, and
:my reasoning. 
:
:Direct editing of a text file loaded directly by the MUD is a bad idea.
:People make too many mistakes. The actual MUD configuration file should
:be machine written if possible, to avoid problems. I do see some great
:advantages to having the configuration human-readable and human-editable
:if necessary, but I think it's a problem to require the builder to edit
:this file directly every time.

Agreed. Make it editable, readable, and sensical... but DON'T make it
normal to do it that way.

:Offline building is a good *option*, but should not be used in
:preference to online building. In most cases where I have worked on a
:MUD, online building was a must -- people I was working and consulting
:with were elsewhere in the country, and I needed to be able to
:communicate with them. It's also desirable for changes to a room or area
:to happen immediately. Perhaps a load/save concept would be useful, for
:areas that need significant rework of interrelated portions.

Having areas editable temporarily, permanently, or with a 'commit this
change to memory' option are also possibilities. Even more, reserve these
capabilities for admins, but allow anyone to create an area, with a sort
of virtual character for in person editing touchups, a sort of micromud
where they are admin, for the case of area editing abilities. (I inherit a
new locational tree and place the IO into that tree, so it IS effectively
a seperate mud.)

:GUI interfaces are not generally a good idea for a text-based MUD.
:There's too much text entry required, and the mouse/keyboard switching
:is ultimately a pain and a slowdown. If a particular command in the MUD
:building interface is easily automated by a button, it is also either
:easy to type or should be simplified in the MUD design. 

I do use an arrow-key interface.... similar to Lynx or Gopher interfaces.
For example:

  Field         Currently
   Keyword       thing, generic+object, example
-> Name          "<a/an=1> example of an object"
   Description   "It is just your basic generic object."

Where hitting the right arrow sends you into a more detailed listing, if
there is such for that field, and return enters and editor, and up and
down shift fields, and left takes you up in scope one level. Hitting C-n
adds a new field, after prompting for type. A new type can be created
here in the internal language.

:There *are* places where a GUI can be useful, for example a series of
:checkboxes that graphically illustrate the locations of exits -- these
:checkboxes could be turned on or off, and then a single button could
:make and destroy exits as appropriate through something like this:

:	For each checkbox,
:		Is the exit checked?
:			Yes: Is there an exit there?
:				Yes: Leave it alone.
:				No: Make an exit.
:			No: Is there an exit there?
:				Yes: Destroy the exit.
:				No: Continue.

:However, this could be just as easily done with a command like

:	setexits <<n|s|e|w|u|d|ne|nw|se|sw>[=name]>[...]

Little hard without rooms or directional exits, no? Few of us, IIRC, have
either of those things.

:It's intuitive, simple, and easy to do. However, the designer would have
:to resist the temptation to make this command the ONLY command
:available; while this is, of course, easier than 

:	newexit e
:	newexit w
:	newexit s

:or some similar interface, if a single exit is desired it would be much
:easier to type 

:	newexit u

:instead of 'setexits w e s u' -- and of course, there's the associated
:problem of typos. 'setexits w e d u' is an easy typo to make, and now
:forces the builder to redesign the south exit as well as removing the
:down exit. Likewise, there's an associated difficulty in people who want
:to do EVERYTHING in one command line; resulting in commands like

:	setexits s=A long tunnel/5321|This long tunnel leads off 
:		into the darkness.| n=A dimly lit room/4231|The dimly
:		lit room appears to be uninhabited.|

:What I would consider the perfect interface for building is a command
:interface online, with the ability to bring portions offline for more
:long-term extensive editing, and some provision for loading the MUD
:config directly in the event that the MUD cannot load the config for
:some reason. A GUI designer could be great if properly implemented, but
:I see a lot of potential for mistakes in it -- is it possible that you
:could provide us with a few screen shots? 

Personally, I would have found all of your examples, as a builder,
intolerable. And it doesn't leave a lot of room for programmability. Not
saying a GUI would come out better, though I have been thinking of a GUI
interface for building in my client... just, with an IDE built in.

   __    _   __  _   _   ,  ,  , ,  
  /_  / / ) /_  /_) / ) /| /| / /\            First Light of a Nova Dawn
 /   / / \ /_  /_) / \ /-|/ |/ /_/            Final Night of a World Gone
Nathan F. Yospe - University of Hawaii Dept of Physics - yospe at hawaii.edu