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

Caliban Tiresias Darklock caliban at darklock.com
Tue Sep 23 13:48:08 CEST 1997


On Tuesday, September 23, 1997 4:45 AM, Chris Gray 
[SMTP:cg at ami-cg.GraySage.Edmonton.AB.CA] wrote:
> [Caliban:]
>
> :When I presented general solutions, I received a clear and overwhelming
> :majority of posts which considered the thread irrelevant.
>
> Perhaps you needed some examples? (Sorry, I couldn't resist!)

Heh. I probably did, because people kept asking for them, but when I tried 
to give some I kept getting the same old 'oh, my game has no such concept, 
so this subject is irrelevant'. I hate that. I think the only thing we can 
actually rely on in most games is that people can log on and expect to see 
things and pick things up; even directional commands like north and south 
aren't universal, and of course a lot of people are completely off in their 
own little world with respect to what a 'character' is. I don't even 
understand half of these concepts people are bandying about, because they 
seem so completely foreign to my idea of what a MUD is and entails. That's 
sort of why they're on this list; it's not a MUD *designer* list, but a MUD 
*developer* list -- which means there are going to be radical changes in 
the way some people are looking at things, because that's a major part of 
what development is in the first place. Some of the people on this list are 
so ungodly brilliant and imaginative that I wonder what the hell I'm doing 
here. And I'm not mentioning names, for fear of omitting someone that I 
ought have mentioned, either with or without reason. ;>

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

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

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

> I agree with most of what you are saying here, but it seems to me the
> problems are ones which have to be solved in a given system, whether
> through natural-language-like means or others. It's worth noting that
> many of these problems disappear if you use can choose items with a
> pointer in a graphical display.

I think I've already mentioned my terrible dislike of switching between 
mouse and keyboard. ;)

> 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
>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):

>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.)
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)
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.
>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
>#$!%@
I beg your pardon?

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.

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

I don't actually have a perfect solution (or even an acceptable imperfect 
one, IMO). ;)



More information about the mud-dev-archive mailing list