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

[Caliban Tiresias Darklock]

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. 

A vast generalisation is something more along the lines of 'mud
designers don't care about user interfaces', which is completely untrue
and is definitely not something I'd be likely to say. I do feel that the
vast majority of them are paying far too little attention to it, and
that when I say 'hey why don't we think about this' I get far too much
'no that isn't true you suck' in response. Every time I offer an
example, I get told that there are lots of other ways to do it. Well,
DUH. It was an example.

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

>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*. Some systems count from
the top of the list, some count from the bottom. In order to resolve
this, you have to introduce an incompatibility or an inconsistency. You
also end up tying the interface to the underlying server. One possible
solution is to make the syntax of game X conform to the expectations a
player at game X would have, but then you have differing operation of
commands. If you select one operational method and stick with it, you
become incompatible with the syntax you borrowed from game X in order to
be compatible with game Y (or with no game at all), which pretty much
kills the idea of making it easier for a game X player to use your game.
If it's not going to work like game X, why allow the same syntax?

The following is an example, and while there are certainly a lot of
other examples this one happens to be the one I have chosen. I hate
having to put these stupid disclaimers in, but people seem to require
them.

I find the arbitrary numbering of items to be confusing; 'get the second
ball' means what? Get the second ball that arrived? Get the second ball
from the left? From the right? From the top? In the real world, if I
were to set down three balls next to another ball by placing one on each
end and then one between the two on your left, what exactly would the
second ball be? The second ball to arrive is the first one I put down.
The second ball I set down is the one on the other end. The second ball
from left to right is the last one I put down. And the second ball from
right to left is the one that was already there. It's inherently
ambiguous. The way most games handle this is to consider them in the
order they were placed, and have no real representation of exactly where
in the game world they are. But they handle this in varying fashions:
stack, queue, internal object reference, how do you tell? 

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.

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 You see me now, a veteran of a thousand psychic wars. I've been 
 living on the edge so long, where the winds of limbo roar. And 
 I'm young enough to get involved, too old to see, all the scars 
 are on the inside; I'm not sure that there's anything left of me
               -- Blue Oyster Cult, "Veteran of the Psychic Wars"
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+