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

[Chris Gray]

[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!)

:them were specifically combative and insulting. Such an overwhelming
:majority may be statistically considered to be representative of the
:active group members.

That's not my recollection at all. Oh well, clearly different people
interpret a given set of words in different ways.


And now onto useful discussion...

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

Excellent point. Are there actual reverse meanings like that around?
It surprises me that someone would count from the bottom of the list. 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.

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

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?

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

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

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

This is a pretty low-level detail to be talking about, but at least
its a start!

--
Chris Gray   cg at ami-cg.GraySage.Edmonton.AB.CA