[MUD-Dev] Clients

[Travis Casey]

On Monday, 16 February 98, Caliban wrote:

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

I'd say that if that happens, the people designing the mud weren't
thinking.  You should allow players to reference things in the same
terms that you describe them to the players -- that's simple common
sense.  The players aren't mind readers, there's no reason why they
should be able to divine what statistics you use internally in your
mud.  To require them to type "help sdc" when nothing they ever see
actually mentions sdc would be sheer idiocy.

Personally, I favor abstracting what the players can see, but not in
the way that you're describing.  IMHO, there's nothing wrong with
describing things to the players with numbers -- but there's no reason
why those have to be the same numbers that the game uses internally.
They should be numbers that are chosen for the player's ease of use
and understanding.

For example, attribute scores could be shown to the players on a 0 to
10 based scale, where 0 is no ability, 5 is human average, and 10 is
the best that any human can be without magical or technological
augmentation.  Most people are reasonably familiar with such a scale,
and it's easy to tell at a glance whether you're average, above
average, or really great in an ability.

Internally, though, the mud may use a linear scale, with 1000 being
human average.  This isn't a problem for the mud internally, since
computers are very good at handling large numbers -- but humans aren't
nearly so good at it.

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

Umm... I think I know the kind of thing you're talking about, but
you're off a bit.  The necessary operators are incrementation,
decrementation, and what assembly language programmers would know as
JNZ -- jump if not zero.  You can implement any mathematical algorithm
with just these three operators -- the language they create can
implement anything that a Turing machine can implement.  Thus, this
language, Turing machines, and, if I remember right, two-stack push
down automatons are the three possible "machines" are all equivalent
machines, and are all used in computability theory, since they are
each convenient for deriving different results.

> Ideally, you should have a GUI and a CLI -- see AutoCAD -- from which
> pretty much anything can be done. If it's a terrible pain to do something
> in one interface or the other, then you should examine the reasons. If it
> can't be helped, it can't be helped... but you should at least make an
> effort.

I agree wholeheartedly with this -- a good interface should provide
multiple methods for doing the same task, and should allow the user to
mix methods as much as possible (e.g., selecting an object with the
mouse and then typing a command to perform on that object).
--
       |\      _,,,---,,_        Travis S. Casey  <efindel at io.com>
 ZZzz  /,`.-'`'    -.  ;-;;,_   No one agrees with me.  Not even me.
      |,4-  ) )-,_..;\ (  `'-'   visit the rec.games.design FAQ:
     '---''(_/--'  `-'\_)       http://www.io.com/~efindel/design.html