[MUD-Dev] Usability and interface and who the hell is suppo

[Travis Casey]

Caliban Tiresias Darklock <caliban at darklock.com> wrote:
>On Fri, 19 Sep 1997 20:50:14 PST8PDT, "Travis Casey"
><efindel at polaris.net> wrote:
>
>>"Everyone" and "the group?"  Is this the same Caliban who said in another
>>post, "I really detest statements of vast generalisation?"  Do you only
>>detest them when you're not the one making them?
>
>When I presented general solutions, I received a clear and overwhelming
>majority of posts which considered the thread irrelevant. A very many of
>them were specifically combative and insulting. Such an overwhelming
>majority may be statistically considered to be representative of the
>active group members.
>
>I am not making a vast generalisation. I am drawing a conclusion based
>on past experience, which is a clear application of accepted scientific
>method. The needless complication of the language to say 'everyone who
>replied to my previous threads regarding modular mud design' and 'those
>members of the group who have replied to my posts in the past' is just
>plain annoying.

Many people who say "all blacks are lazy" will also tell you that they're
generalizing from past experience, if you press them.  Why do you consider
what they're doing wrong, but what you're doing right?

Remember that the sample you see may not be representative -- I don't have
any statistics on this list, but it's quite possible that there are more
lurkers than regular posters -- and even many of the regular posters won't
post on every thread.  When you say "everyone" when you actually mean
"everyone who replied to my thread," you are needlessly antagonizing those
of us who didn't reply to your thread.

Personally, I find it useful to be careful in what I say -- it encourages
actually thinking through what you're saying in detail, and reduces the
noise to signal ratio greatly.

>>IMHO, input mechanisms for a mud should be made as broad as possible --
>>that is, they should accept a wide variety of input, try to do something
>>reasonable with it, and if they can't, give informative error messages.
>
>The best watchwords, in my opinion: Be liberal in what you accept and
>conservative in what you produce.

Exactly.  I'd forgotten that characterization of the method.  :-)

>>Some aspects of NLP can play a role in this, but I'd personally use it to
>>augment the standard mud command system, not to completely replace it.
>>(That is, rather than trying to create a full NLP interface, I'd like to
>>set up a system which can understand that "the second ball", "2nd ball",
>>"ball 2" and "ball.2" are all references to the same thing.  The LP-
>>and Diku-isms may be grammatically incorrect, but I believe supporting
>>them is useful.)
>
>I'd agree entirely, but somewhere along the line you start hitting the
>problem of what exactly the second ball *is*.

[discussion of different things that "second X" could mean trimmed]

Very true.  In order to make use of orderings, the mud needs to ensure
that orderings are stable (i.e., "the second ball" in the room stays
"the second ball" until and unless an event in the game world occurs
which would change the ordering) and to document for the players what
the ordering means.  Personally, I feel that "'the second X' is the
second X that you see in the list of items when you look around" is
the most reasonable definition for most muds (i.e., that it's the
definition that players are most likely to use without thinking about
it.)

Another possible solution is to prompt the player for more information.
For example:

  >get the blue gem

  There are two blue gems here.  Do you want to get:
    1.  the small sapphire
    2.  the aquamarine

  Please enter the number of the blue gem you want:

Alternatively, you can simply treat this as an error and give a message:

  >get the blue gem

  There are two blue gems here.  Please be more specific.

With articles, you might want to do different actions depending on whether
the player used "a/an" or "the" -- "the" implies that the player has a
specific item in mind, so you might want to use one of the above techniques
for "the" and simply have the mud pick one of the matching items at random
for "a".  Of course, such behavior should be documented.

Of course, making assumptions such as this makes the game less friendly for
beginning players, since they won't know what assumptions are being made for
them.  One possible solution is to assume as little as possible in general,
but allow players to set what, if any, assumptions are made for them.

Another solution is what I'd call "progressive automatic documentation" --
when the player first performs an action in which a certain assumption is
used, output some documentation about the assumption.  However, this can be
very
distracting, especially if such assumptions occur in combat or other time-
intensive situations!

Perhaps the idea of a "tip of the day" could be borrowed from some
applications -- a tip given to the player when he/she logs in about
something
which can make the mud easier to use, possibly with instructions about how
to find out more useful stuff.  Such systems usually only show each tip to
each user once.

>This is a huge and complex problem, and is a perfect example of exactly
>where I feel NLP falls down. NLP is not objective, and soaks a
>tremendous amount of effort into solving questions like this instead of
>into other more interesting functions of the game design. For this
>reason, I consider it a Bad Thing. There are certainly solutions, but
>the solutions either kill NLP or introduce significantly more complexity
>to the user command set and/or the design of the parser. NLP is like
>saying your game is going to support everything. No game can support
>everything, so your goal is intrinsically unrealistic. And to provide
>the *illusion* that your game supports everything is eventually
>frustrating to the player, as he discovers that certain perfectly
>reasonable commands utterly confuse your parser. And if you have too
>many special cases, you're doing it wrong.

That's why I only wish to use partial NLP -- because I feel that NLP
techniques can be useful in figuring out what players are trying to do,
but I don't feel that NLP is a perfect solution.  I prefer the standard
command-based interface for its exact meanings, but a robust parser should
be able to handle such things as the presence or absence of articles, and
common variations in syntax such as "give joe the sword" vs. "give the sword
to joe".
--
       |\      _,,,---,,_        Travis S. Casey  <efindel at io.com>
 ZZzz  /,`.-'`'    -.  ;-;;,_   No one agrees with me.  Not even me.
      |,4-  ) )-,_..;\ (  `'-'        rec.games.design FAQ:
     '---''(_/--'  `-'\_)      http://www.io.com/~efindel/design.html