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

[Maddy]

Previously, Caliban Tiresias Darklock wrote....
> On Tuesday, September 23, 1997 4:45 AM, Chris Gray 
> [SMTP:cg at ami-cg.GraySage.Edmonton.AB.CA] wrote:
> > [Caliban:]

[Snip]

> > Are there actual reverse meanings like that around?
> > It surprises me that someone would count from the bottom of the list.
> 
> Given a list of 40-some items, the top of the list has scrolled off the 
> screen and you can't rely on someone having scrollback; therefore, the user 
> can't actually be expected to have the ability to count from the top of the 
> list, and is forced to either use scrollback (if he has it, which decreases 
> compatibility) or count from the bottom. It's actually a really simple 
> solution to what could be a complex issue, although it certainly could have 
> been done better. I was pretty impressed by it when I first came across it. 
> :)

Well if (for example) you type look and lists 40 swords (all identical) one
on each line it would be stupid.  What would be better is if it turned "you
can see a sword" (40 times) to "You can see 40 swords".  This does of course
cause all kinds of problems with the "get 2nd sword" situation, but if all
the swords are identical then it doesn't matter.  If you know for a fact
that sword #35 is cursed then it'll be listed as a cursed sword, seperate
from the rest.

> > Is
> > the "standard" solution to disallow ambiguous references, or to just
> > pick one item, according to whatever rules the system has? You don't
> > have to have a very complex world, or many builders, before ambiguities
> > arise.
> 
> Generally there's either something that fits the description, or you get an 
> error. If you get the third sword, but there are only two swords because 
> someone picked up the third one, you get an error. If you're getting the 
> second sword, but someone already took it, the third sword has now become 
> the second sword so you get the wrong sword. *shrug* Can't really be helped 
> with numbering; it's hard to tell whether the person is really trying to do 
> what he's doing, or has made an error in timing. Lag affects this in an 
> unacceptable fashion, IMO.

Well if Bubba picks up the sword, there are still three swords visible to
Boffo just as he presses enter.  But there is no real way the ordering could
be maintained, so it won't try and take the sword from Bubba.  I guess you
could always store the ordering for each player - but that could get messy.

> > Another excellent example. Your point is taken. Having said that, I am
> > now in a quandary as to what *should* be done! My current implementation
> > allows the use of the syntax like     "get rock #3"    and I will find
> > the 3rd rock in the room's contents, as counting down in the list of
> > items in the room. It seems to me that a system has to have *some*
> > way of handling this, else the player cannot do some things. Users have
> > suggested an additional form (from NLP!), where "get a rock" would
> > specifically allow the system to chose which one to get. I could also
> > allow a per-player toggle, allowing "get rock" to do the same. Is this
> > putting in too much complexity, and making the user interface needlessly
> > difficult?
> 
> Not at all... it's when you start adding things like scanning and parsing 
> the rock descriptions to allow 'get the biggest blue rock' that the 
> implementation is *starting* to get out of hand, but only just barely. 
> Generally this results in more problems, like for most Americans if there 
> are five rocks of different sizes and you want the rock that comes fourth 
> in the order from smallest to largest, you can refer to this rock as either 
> the 'fourth largest' (the fourth rock counting toward the largest rock) or 
> the 'second largest' (not the largest, but the second largest). Most 
> British players would probably feel more comfortable with 'next largest', 
> which could cause confusion for the NLP module if he has just picked up 
> another rock, or even the 'largest rock but one' -- not *actually* the 
> largest, but with only one larger. (I'm not sure this is *common* British 
> English, but I've heard it said now and again.) A wiseass might say 'get 
> penultimate rock'. ;)

I'd refer to the rock as the second largest, personally.  I can't really
imagine it being refered to the fourth largest either.  Refering relatively
to previous objects should work if you keep track of last X you were playing
with.  You pick up a rock, then "it","rock","the rock" all refer to it, so
"next largest rock" would refer to rock that is next size down.

> I avoid NLP for these sorts of reasons. If you are using NLP in any form, 
> remember that you can NOT handle everything and you shouldn't try. I 
> usually see NLP as trying to look like it's comprehensive when it actually 
> isn't. Perhaps the best way to explain a well-written and well-scoped NLP 
> interface, arguably, is that the interface is about as intelligent as a 
> child of five and has about the same vocabulary and level of understanding. 
> Given that description, most players would probably find interacting with 
> the parser pretty simple... just speak clearly and use common terms. But as 
> you'll see later, a five year old can understand some things that give NLP 
> implementations raging fits...

[Snip]

> > I guess that's my problem with what you are saying, in general. You are
> > saying that NLP (I'm not real sure what you mean by that, but for the
> > sake of continuing this discussion, I'm assuming you mean the small
> > extensions to input syntax that allow the user to use slightly more
> > correct English syntax in commands) causes lots of problems, which I
> > certainly agree with. But it can also solve lots of problems, and if
> > it is done away with, other solutions must be found. Is there a net
> > gain after doing that?
> 
> My understanding of NLP is that NLP comprehends, breaks down, and 
> interprets complex and compound sentences according to a series of rules. 
> NLP, in my mind, does not mean typing
> 
> >go toward the north
> >check the big wooden door for traps

I think this one is probably the only one out of your examples that is
complex enough to warrant being in the NLP list below.

> >open it
> >draw my magic sword
> >wield it
> >enter the treasure room
> >look around
> 
> but rather means typing
> 
> >go north and check the big wooden door for traps
> >open it, then draw and wield my magic sword
> >walk into the treasure room and look around
> 
> While the Infocom games tended to do well at that sort of thing, they had 
> very limited vocabularies and static worlds. There's a potential concept 
> which might be used, although it would probably create some oddness... 
> given an NLP engine, on startup the game could catalog every word used in 
> the game based on a large dictionary, and then just add information to the 
> index as objects were modified. When someone said 'get <whatever>', the 
> game could look up <whatever> in its list of words, and get a list of 
> object references. If <whatever> is a complex phrase, the additional words 
> in the phrase could be used to filter through the results with more 
> specificity, and then checked against the intended 'verb' to see what sort 
> of filter should be applied for that. Like 'get' might require something to 
> be in the player's line of sight, first checking what's in the room. You 
> can do all sorts of nifty things with NLP, but it tends to break down in 
> odd, inexplicable places that are even more frustrating. For example, you 
> might have a situation where you're in a room with two doors (comments in 
> parentheses are not part of the command line):

Yup - my NLP does have a large dictionary of words (and their types) - it
knows that Green can be an adjective or a noun.  I've not made any plans on
how I'm going to update the dictionary yet, it's persistant so I've been
adding words external from the mud at the moment.

I handle complex names ("the sword","green apple") by forming a group of
it's adjectives and noun and then that is passed to a routine which returns
back a list of appropriate objects.

> >look around the room (bah, simple strip of irrelevance, easy)
> You are in a room with a big wooden door on either side. There is a large 
> sword painted on the wall.
> >get the sword (simple sentence, but correct English; just strip article)
> The sword is painted on the wall, and cannot be picked up.
> >open the wooden door (confusion: more than one match)
> There are two wooden doors here. Which would you like to open?
> >the left one (Smooth... simple to remember, easy to use)
> You open the wooden door on the left.
> >look through ('...the door'. Nice, easy completion.)

Right well, althought players can do this, they can see through the door by
default.

> You see a magical sword lying on the floor in the other room.
> >get the sword (since the sword on the wall is not gettable, it looks 
> nearby before answering)

This is assuming that because you saw the magical sword last, that it's "the
sword".  Hmmm not a bad assumption I guess - I've not really thought about
that kind of thing.

> You go into the room on the left, and pick up the magical sword.
> This room is empty. An open wooden door leads into another room.

I'm not so sure about the player going into the room first, I'll have to
think about it.  The problem with it is say you might have the following.

   >look.
   You are standing in the minefield, on the other side is a tree.
   >climb tree.
   You head towards the tree.
   *KABOOM* You hit a landmine.

> >open the other door (here, the parser begins to screw up... what other 
> door?)
> There is only one door to open.
> >open it (simplistic indirection: 'it' == 'the other door')
> There is only one door to open.
> >look through (hey, this works)
> You see a room with a big wooden door opposite you.
> >open it ('it' == 'the door')
> The door is already open.
> >open big wooden door (both doors are big wooden doors)
> The door is already open

Well since you can see through doors automatically, the game lists both
doors as doors you can see.  If you make the assumption that if you do
something to an object that is not nearby, that you walk to it, then it
should walk towards the door and then open it.

> >#$!%@
> I beg your pardon?

I think my parser (if you actually use the uncensored words) says "You don't
know how to #$!%@".  But that is a default response for an unrecognised
verb.

> This sort of thing breaks the NLP in multiple odd situations. 
> Unfortunately, you'll never test the parser through all of these 
> situations; for example, someone might want to be able to type 'go back to 
> the temple of moondragon' and expect that the MUD will map out a path for 
> him. He would probably expect it not to walk him into combat, too.

I don't think the parser is actually "broken" in the above example, it's
just that the open command doesn't have the ability to open a door that
isn't in the same room.  Since I handle all this kind of thing generically,
I'm hoping it won't fall over - but never the less I'll probably certainly
use this as a test case.

> > To clarify what I'm getting at, here is a trivialized example: Boffo has
> > just defeated a dragon, and is faced with its hoard. There are seventeen
> > swords, including three two-handed swords. How does Boffo pick one up,
> > or examine it? Can anyone think of a better solution than any of the
> > ones previously listed (or mine)?
> 
> I'm tempted to say that the three swords should have semi-randomised 
> descriptions, but I'm hesitant to recommend that because it can create 
> weird descriptions:
> 
> (Static portion)
> 	You look upon the mighty sword Excalibur, gleaming brightly
> 	in its unblemished and razor-keen magical splendor.
> (Random portion, crossreferenced: 'sword')
> 	There is a small amount of rust at the base of the blade and
> 	the tip appears slightly dull.
> (Unblemished and razor-keen, my butt...)

But that isn't just any old sword tho - it's Excalibur and hence a one of a
kind object.  It would be referenced seperately from just any old sword
anyway.

Maddy