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

[Nathan Yospe]

On Tue, 23 Sep 1997, 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:]

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

Guys, I think he's being ironic at us. Let's get him. <hefts battleaxe>

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

Interesting. This is a new one to me. Of course, the other solution is to
have a command that will list matches by number, as a last ditch way out. I
do this, even with an NLP.

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

If you want to be specific, then damnit, BE SPECIFIC! That's the whole point
of an NLP, for me. It allows a lot of specification when desired, and can be
played with simple little parses like a diku when not. (IE, "ge bl ro", as
opposed to "get the wet blue-green rock at the base of the statue of a
horse")

:> 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'm going to test this.

Lets see:
get the fourth largest rock

It grabbed the second smallest rock. No surprise.

get the fourth smallest rock

It got the desired rock

get the second largest rock

ditto

get the next largest rock

"You haven't focussed on any rocks recently. You pick up the large gray 
rock."

(It got the largest rock)

get the largest rock but one

"Do you mean to get the largest rock, and only the largest rock?"

(The NLP has not yet adjusted to ambiguities. Over time, it will learn
several player specific ambiguities - this is why it is client hosted - and
should come to recognize what the above command means.)

get the penultimate rock

Hey! It actually parsed that correctly!

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

My NLP is built around a neural net, with a number of algebraic language
elements taken from a series of rather interesting articles in the Computer
Language Journal... it seems pretty robust, so far.

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

Personal preference. I'm certainly going to provide the option.

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

Yeah, seems reasonable enough...

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

So far, you've missed a lot of elements. Having memory-nets and habit
learning neural nets makes for a much more powerful NLP. Also, most verbs
actually grab a host of verb possibilities, interpret and weigh probability
on each, and finally decide on one, or possibly ask for clarification between
two.

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

It would certainly remember the recently acquired door on the other side.
The point here is, the memory nets are calibrated to be just a _tiny_ bit
longer than a user's short term memory... so anything a user might use as
a reference out of STM, should be in the mem-net as well. There are
exceptions, but not reasonable ones. If a player tries to remember a candle
for ten minutes, then says "light it", the parser will respond "do you mean
the candle?" (If the candle is on the plaers person), or possibly "do you
mean the candle, the torch, or the lamp?" "my hair" "You apply a match to
your head. The hairspray catches fire immediately. The pain, the pain!"

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

*shrug* You're using a linear, memoryless NLP. I have no further comments at
this time.

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

That's an unreasonable assumption. Certainly, if the temple was right
there... but otherwise "Where is the temple of moondragon?"

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

My solution involved removing the static portion, after much deliberation.
Let the client side memnet store any sentimental values. The client handles
all the text anyway... if someone names their sword, fine. Why should anyone
else's sword have a name? Much less "You look upon the mighty sword
Excalibur"... how trite. If its Excalibur, MAKE it magically razor-keen,
don't just TELL us about it!
--

"You? We can't take you," said the Dean, glaring at the Librarian.
"You don't know a thing about guerilla warfare." - Reaper Man,
Nathan F. Yospe  Registered Looney                   by Terry Pratchett
yospe at hawaii.edu   http://www2.hawaii.edu/~yospe           Meow