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

[Maddy]

Previously, Travis Casey wrote....
> Caliban Tiresias Darklock <caliban at darklock.com> wrote:
> >On Fri, 19 Sep 1997 20:50:14 PST8PDT, "Travis Casey"
> ><efindel at polaris.net> wrote:

[Snip]

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

Or for the "the" case, you could keep track of what the last gem was that
the player was interested in, same as you'd do with it.

   >examine the small saphire gem.
   It's lovely.
   >get the gem.
   You pick up the small saphire gem.

The only two problems I'd forsee, one is where you might have the
possibility of having two "the gem"s.

   >example gem in rucksack.
   It sparkles in the light.
   >example gem on table.
   It's lovely.
   >drop the gem.
   You're not carrying the gem on the table.

Now the above is perfectly valid, the last gem refered to was the one on the
table, but surely since the drop command is only concerened about objects in
your possesion it should have used the one you're carrying.

The other is you don't always want to be queried about ambiguity.

   >look
   There are 10 orcs charging towards you, ready to tear you to pieces.
   >hit orc.
   Which orc do you mean?  There are 10 orcs, please choose one.
   An orc hits you. [repeated 10times].
   You die.

I guess I'll probably end up having 3 lists, one for objects you're
carrying, one for objects in the room and one for objects in surrounding
rooms.  And then most commands will assume you're refering to a specific
object, but for those like hit where you're not, it'll assume "a" unless
you've already got a specific "thing" in mind.

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

The problem with not making assumptions is that you're slowly the players
down, if they're gotta put the saphire gem into the slot and they've got a
small amount of time to do it, they're going to get pissed off if the game
doesn't make some obvious assumptions 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!

If you mean what I think you mean, then most text adventure games do
something along those lines too.

   >go south.
   [First opening the south door]
   You go south the door.

I guess it depends on how much you waffle on - short one or two line
messages isn't too much IMHO.

Maddy