[MUD-Dev] Clients

[Adam Wiggins]

[Caliban Tiresias Darklock:]
> My major problem with the interface on MUDs is that the command you're
> looking for is pretty much impossible to find a lot of the time unless you
> know the vocabulary the developers used. If you come from a D&D background,
> you might try 'help ac' and expect to learn something about armor values,
> or you might try 'help armor' or 'help armor class' or 'help defense' and
> in the meantime you're on a MUD designed by Palladium jockeys who list all
> that under 'structural damage capacity', 'sdc', and 'damage'. Not like

As I've mentioned here before, I very much like to toss in *all* of these
(or, at least, as many as I can think of) into the help files.  Many
of them are simple redirections to the proper help file, or in fact
just aliases for said file.  For example, 'help wield' gives you
"There's no wield here, just hold the weapon you plan to fight with.
See help 'hands' for more info," or "D&D-style AC and thac0 do not exist
here.  Try help combat, offense, defence, armor, and damage."

Such things take hardly any time to create, and can greatly aid someone
feeling at home, or at least like they're not completely off track.
I've also considered logging all failed help request commands in order
that I might better identify what people get confused about.

> you'd know, since they've carefully concealed all your actual stats from
> you in order to make things a little more realistic, and when you look at
> your statistics you get 'You are healthy as a horse. You are carrying a
> sword which does moderate slashing damage. Your chain mail is moderately
> protective and slightly magical.' or something like that. This is something
> I hear bandied about an awful lot on the list, and I don't see it as
> realism. I see it as needless abstraction and complication of the user
> interface, which effectively locks out new users unless they have a friend
> who can teach them how to look things up and what to type.

Depends - if you want to powergame, sure.  If you're writing a game
that depends on exact numbers (anything D&D derived will probably
fall into this category), it's just frustrating to try to hide numbers
from the users this way.  If you've got a 'realstic' system, then what
is the matter with the above?  Weaing more armor makes you slower and
more resistant to damage.  Wearing less has the opposite effect.
I think that this concept is hard to follow only for old GoPers who
are so set in their ways that they can't imagine that there are such
things as 'magic' numbers (ie, 18/76 being a strength breakpoint for
damroll).  Now, I enjoy GoP plenty, so I'm not trying to knock it.
Just saying that your stat display has to match your style of game,
and the above example is perfectly valid - IF the game has been written
to work that way.

> In a related story, some wiseass once demonstrated that the only necessary
> operators in the C programming language were incrementation,
> decrementation, and equality. He wrote a huge series of functions that
> demonstrated how you could simulate everything else with these two
> operators. He had things like:
> 
> int add(int num1,int num2) { while(1) { ++num1; --num2; if(num2==0) return
> num1; } }
> 
> The acrobatics got much, much worse. I'm not sure whether he was brilliant
> or a complete moron. Probably a little of both. ;)

Fun mental acrobatics, but this seems rather regressive to me.
I can prove that any existing program can be simulated in a huge
number of logic gates, but - so?

> >The command line is an obscure and austere interface, useless without
> >education (training), and forethough (needed to assemble the command prior
> >to entry).  It is also powerful and capable of fluently stating processes
> >which are difficult if not impossible to state in a general purpose
> >graphical environ.  Are GUI's necessarily better?  
> 
> Ever try to draw from the command line? ;)
> 
> The answer: It All Depends. What are you doing and under what circumstances
> are you doing it? Database access can be done from a GUI much better than a
> text interface if you're using a small database and just collecting items,
> like for a shopping cart. On the other hand, data entry from a GUI is often
> tedious. Large jobs that require repeated activity sometimes work great in
> a GUI (moving all the files in directory X to directory Y), and sometimes
> really suck in a GUI (moving all the files about Bob's business activity
> into a specific directory). Sometimes a GUI is great. Sometimes it sucks.

Many programs today are reliant on a certain interface to make them
work.  It's not that they wouldn't work very well without that interface,
it's that they wouldn't work at all.  3D character animation would be, I
think, so difficult as to be approaching impossible without a mouse.
Programming a major application without a keyboard is the same thing in
reverse.

MUDs need a command line interface, because that's how they were
designed to work from day one.  Anything else will seem pasted on.
If you step back and approach it from a slightly different angle with
a new (at least, to MUDs) design, then you can make it work, and work well.

>[snip - stuff about bad design in freeware Quake editor]

What always boggles me about this is that the author has to actually
use this program to test it.  I know that when I'm testing something
with annoying features like this, I couldn't stand *not* to change it.
Of course, there's the thing that sometimes the author uses their own
program in an entirely different way than many of the users do.

> "Sword is not readied. Would you like to ready it now?", "Yes", "Are you
> sure?"... and meanwhile the ogre is making hasty pudding out of your
> entrails. On the other hand, if you can do something slick like
> double-click on the word 'ogre' on your screen to select it, and then you
> automatically get a menu that includes the option 'attack', the CLI user
> ends up at a serious disadvantage. You can do things in a good way, or a
> bad way, no matter which interface you choose. Theoretically, a command is
> a command, but different people work different ways. I almost always use a
> combination of keyboard and mouse to control my system. Depends on the
> activity. Most other people do the same -- but in a little bit of a
> different way.

It also depends on your personal skills.  My dexterity is so poor that
I constantly miss the Wharf icons on my X desktop (and they are 64x64 pixels
on a 1280x1024 screen).  I can type "/usr/X11/include/X11/pixmaps/24biticons"
approximately ten times faster than I can click through a file dialog with
a mouse.  On the other hand, my girlfriend can click through said dialog
nearly as fast as I can type it, can click on 4x4 icons quickly and accurately
with ease, but it takes her long periods of time to type out long filenames
or commands, especially when she's letting her nails grow.  I was amazed to
find someone that found the mouse so much better (as in, faster and more
accurate, rather than just easier) an interface to a computer than a keyboard.
She was amazed to find someone who could type thirty character filenames
more quickly than she could scroll through a dialog and double-click them.
This is more than just 'what we're used to' - I've been using mice for
more than a decade, and I still suck.  She's been using querty keyboards
for much longer than that, yet she still has to stop and figure out
which number key she has to shift to get a given symbol (!@#$% etc).
Genetics coming into play in choice of interface?  Who knows...