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

[Adam Wiggins]

> >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.

It's been my experience that human-editable text files are a good idea
for EVERYTHING.  Even though it's a lot easier to do the old
fwrite(&data..) or os << data, being able to edit the files offline can
save you a ton of trouble in many cases - being able to hand edit the files 
is great, and you avoid problems like byte ordering when moving between
platforms.  We use generalized parsing routines which have both the advantage
of being just as easy to use as a binary output routine, and making all
the file formats completely standardized.  At first I thought this would
be too restricting but I found that the only thing which didn't fit the
parser was the script language, and even that could have been worked in
if I had put more thought into the design beforehand.

> 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.

Oh yes.  There's also another, non-technical side-effect to this.
The first mud I ever built on had a seperate builder port with another
version of the mud running for the various builders to log on and fool
with their areas.  This actually proved to be a strong incentive to
work on your area - you log on, say hi to friends, go do a bit of work
on your area...if you have a question, you just ask whoever's around,
even if it's just an aesthetic that you need a second opinion on.
A bit more enjoyable than loading up your favorite text editor and
going to work.

> 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. 

Yup.  Plus I feel that a GUI detracts from the mud's feel as a whole.
Plain text has no feel, so it's pretty much like reading a book.
A GUI, even one with a look that matches the mud's motif, makes me feel
more like I'm working on a spreadsheet or something.

> 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]>[...]

The one advantage to the GUI thing is that you can present a large amount
of information with defaults already filled in, and the user can just change
the one or two items they are interested in and then click 'Ok', as opposed
to a text list of stuff with appropriate commands for changing them.
The GUI form can also be divided into little boxes and so forth, or otherwise
laid out on the screen in a form that makes the information more digestable.
I think in the long run, however, the command format is actually quicker -
you know what you want to change, and what the command is, so you can
practically build areas with your eyes closed.  (Assuming, of course,
that you can type with your eyes closed.)

> 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

I cause many more problems via missed mouse-clicks (hitting the wrong
button or menu choice) than I do typos.  But then again, my mouse skills
really blow.

> 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? 

I tend to think that the builder interface needs to match the game.
I wrote the editor for my project at work.  It is entirely mouse-driven
(although there is a console below where you can type commands, and where
the system sends you status messages) - most 'editing' occurs by actually
dragging around the objects to the place you want them, or selecting
objects from a palette off to the side and placing them down.  Since the
game is visual, the editor must be visual.  It would be insane to try
to create a game like that by typing commands like "place interior.wall at
12075, 3059, 16", then loading up the map to see exactly where everything
fell.  By the same token, writing a text-based mud with a mouse seems
a bit counter-intuative, although not quite as badly.  This might also
depend on how absolute your mud layout is.  'Normal' muds with
their very vague sense of direction, 'wrap-around' exits, rooms with
varrying sizes and shapes, etc etc - wouldn't work at all being display
as a visual map.  On the other hand, if there were such a map, perhaps
it would cause builders to lay things out a little more sensibly, in
such a way that less room overlap and strange mazes of nonsensical
exits become less common (a good thing IMO).