Target Disambiguation (World Interaction)

[DavidRieman]

Eventually we landed a solid base design for target disambiguation, as detailed in the World Interaction User Story. This thread can serve as a place to discuss further refinements/clarifications. To kick things off, here are some relevant clips from previous forums archives, for context.

This thread contains restored content from prior forums; see #134 for details.

[May 2009]

"It would be pretty interesting to build a robust enough parser that keeps track of the previous command and tries to string the commands together if the current command fails."

Hmmm, after thinking about this for a while, I think it's doable. Basically, we would need a couple things added to the command system. The first would be just a buffer to store a failed command. The second would be a flag to store whether we have a failed command or not. So the logic would look something like this:

• Issue command
• Command fails
• Set failed command flag to true
• Store failed command text in buffer
• If this is a valid command, but with invalid parameter then send a prompt for further input from player
• Player issues correct parameters
• Command executes successfully
• Failed command buffer gets cleared
• Failed command flag gets cleared

Or something like that. I don't think that the actual code would be hard, but I think that the logic could get tricky.

Yes, generally, for technical simplicity, the only times you tend to see such a dramatic change in what the commandline expects to receive is during login/character-creation sequences, maybe during pagination, or things like in-game message writing or room building (editing descriptions) or so on where that spans multiple lines of input. I'm not sure the benefits outweight the dev costs, especially considering the number of edge cases and weirdness we are likely to encounter. Take for instance, a user has "a large blue potion" and a "large bag", now they're thinking of that large potion that they want to refer to with keyword 'large' and put it into a bag:

> "put large bag" - What do we do here?

Put the large bag in what? - Uh oh, the user doesn't even know how to cancel.

> no

You put the large bag in the small nook.

Or do we detect the possible conflict of the "large" keyword even though there is one object with both keywords "large" and "bag"? That particular example may be a little far fetched... I dunno, but my gut feeling is that the tip of the iceberg is here, being just a few of the problems that occur with just one command's single possible sentence structure. IMO we shouldn't try to fix such ambiguous input by altering it with more input, but instead have our error texts help the user discover and utilize correct and/or context-appropriate syntaxes. Shy of having an expert in AI-computer-interpreted-linquistics or whatever you want to call a relevant research field to spend some real thought and time on the matter, keep-it-simple design might be better to strive for here?

Well if we could find a NLP guy, he could do it all.
As long as we keep the Parser abstracted enough, I'm fine with keep-it-simple but having a great Command Parser definitely sets a game a part and breaks down entry barriers.

Here's a couple additional complicated situations:

> put asdf garbledygook
Put what?
> thingy
Put in what?
> in bag

(Note the user may or may not slap the "in" there as it may feel natural. Also note that we can have two or more problems in one command.)

> give adsf to Bob
Give what to Bob?
Bob leaves the room to the west.
> ???

(Note the user may be confused here, lets say they type 'w' here to follow west but Bob hit a dead end and came right back at a bad moment.)

> w
Bob arrives from the west.
You give your Rare Wicked Ubersword of Doom to Bob.
> sob 

To be clear though, I am agreed that done right this would be very awesome, but yeah I think it's something we should just plan on being able to come back to later.

Agreed.

OH Snap. I love the waybackmachine. We once talked about converting the INFOCOM Parser into WM. I wonder if that is still good idea?

The Parser is one of the best out there, and would be amazing to use if we could adapt it for a Mud system.

As long as we keep the Parser abstracted enough, I'm fine with keep-it-simple but having a great Command Parser definitely sets a game a part and breaks down entry barriers.

Hehe, I played around with NLP for awhile, oddly enough, my understanding of English is too poor to get to that level of the language.

One thing about pure NLP is that, it's still a rather poor process of dealing with the infinite possibilities of a human language. Don't even go into recursion and the NLP trees unless you want your head to explode.

However, this wouldn't be pure NLP. A MUD has very defined contextual possibilities for set sentences... So, that'd remove a lot of the headaches in regards to natural language processing.

My only issue with command processors is that they tend to be pretty CPU intensive and we have to do everything on the server. It would be great if we could offload this type of stuff to the client, but without building a bespoke one I doubt we will be able to do that.

(On the Bob bounce back scenario...)

Lengthy, just trying solutions out. Typing out-loud. :)

> put asdf garbledygook

I have no idea what item you're talking about... try again.

(The command exited here, back to normal.)

> inv
a large potion
a large chest
> put large
Not sure if you're talking about a large potion or a large chest. Try again...
> put potion
Put large potion in what? (type nevermind to change your mind)
> large chest
You have put a large potion into a large chest. Congrats!
> give adsf to Bob
Give what to Bob?
Bob leaves the room to the west.
You can no longer give Bob anything, he left!
> (normal command prompt)

> give potion to Bob
Player wants to give you a potion. Accept? (Y/N)
> Y

> give asdf to Bob
What's an asdf?
> give potion to Bob
Player wants to give you a potion. Accept? (Y/N)
Player left the room and has cancelled the trade.

> give potion to Bob
Bob has just left the room.
Cancelling trade.

So, I think a lot of these scenarios can be handled relatively easily on the Action level with the current event system. The trading scenarios, where someone leaves, can be interupted with a player leave event.
The item ambiguity issues with multi-part commands have the same solution as they did earlier in the thread... ask for clarification, break out of the action with text, or offer options in order to continue.

So, the code after this was intended for a Take action:
take all / take potion.
I'm certainly not sticking with this code, it was a five minute vomiting of code... which, yes, I do belive would have a code smell.

It handles a special 'all' case, and handles multiple items being valid from the user input side (just errors out, for now).

The item.FullName.Contains(wantedItem) section gives the benefit that the server catches multiple valid objects, and the user can just put in a couple letters of an item.

I think a lot of the built-in .net functionality makes some of the stuff we've been talking about more feasible than originally expected.

Ugh, I want to save this post - but, not submit right now until I can get some sort of point across, but it's 5am and I spent awhile formatting below. :(

IRoom room = sender.Entity.Location;
string wantedItem = command.ActionInput.Tail;
ArrayList validItems = new ArrayList();
bool allItems = wantedItem == "all";

foreach (IItem item in room.Items)
{
  if (allItems)
  {
    validItems.Add(item);
    continue;
  }
  if (item.FullName.Contains(wantedItem))
  {
    validItems.Add(item);
  }
}

if(validItems.Count == 0)
{
  sender.Write("You are unable to find a "+command.ActionInput.Tail);
}

if (validItems.Count == 1)
{
  IItem item = (IItem)validItems[0];
  item.RemoveFromContainer();
  item.AddToContainer(sender.Entity.Inventory);
}

if (validItems.Count > 1 && !allItems)
{
  sender.Write("(");
  foreach(IItem item in validItems)
  {
    sender.Write(item.FullName + " ");
  }
  sender.Write(")");
  sender.Write("There are multiple items that match your description, describe what you want in more detail.");
  return;
}

if (allItems)
{
  for (int i = 0; i < room.Items.Count; i++)
  {
    (validItems[i] as IItem).RemoveFromContainer();
    (validItems[i] as IItem).AddToContainer(sender.Entity.Inventory);
  }
}

Multiple line commands? Really?

I have a bit of experience with creating interfaces like a MUD's command line, and I personally don't see a problem with dictating that every command must be single line. If the command is wrong, nonsensical, or not allowed by that player, send them the standard 'Huh?' response and give them a prompt again. We can make exceptions for pagination, etc, but really we should not allow commands to use multiple lines because it increases complexity both on the server side - server state - and for the users who will be hitting control-c or worse to stop commands they don't want happening.

Oh, and as far as command parsing goes, why not just use a syntax tree defined by the first word used in the sentence? Each command has its own branch, and aliases - we should support them - would be easy to add. The modern unix and windows command lines already do it, so its a proven method.

I think that the User Experience is not studied carefully enough where MUDs are concerned. For those of us with the nostalgia and the historic experience with playing MUDs and using command-line interfaces like DOS, sure, there are literally thousands of MUDs which are 'accessible' to us - but for a MUD to be attractive to a new user in the face of ever-increasing quantities and qualities of even free-to-play graphical MMOs and such out there, serious thoughts should be given to breaking the barriers of entry.

Here's a dramaticized recreation of one the most frustrating recollections in my MUD history; something IMO we should provide better mechanisms to help avoid:

Suppose you have a wicked sword, 6 weird swords, a rusty sword, a hat, a stick, ..., a switchblade, a plain sword, ..., ubersword of doom, ...

> drop plain
You don't have that.
> exa sw
You see a wicked sword.
> exa 2.sw
You see a weird sword.
> exa 3.sw
You see a weird sword.
> exa 4.sw
You see a rusty sword.
> exa 5.sw
You see a weird sword.
...
> exa 10.sw
You see a plain sword.
> drop 10.sword
You drop ubersword of doom.
Joe Schmoe picks up ubersword of doom.

Tell me that whole block of nonsense isn't a frustrating usability disaster...

That said, we shouldn't make the codebase disproportionately more complicated than the gains of the supported usability scenario. Complexity vs benefit should be carefully balanced. The ideas expressed in this post are so far just ideas, none have been started in implementation, and shouldn't be until much further design/discussion/agreement. Potential solutions range in complexity, such as temporary IDs to assist with disambiguation, to multiiple-pass command processors being able to restructure the overall command as you clarify...
ATM I would personally lean Against having multi-line parameters for restructuring commands on the fly. However, the occasional well-placed, well-designed Y/N prompt (which if implemented correctly, does NOT block the next command you had queued up since it'll forward on anything except Y/N or whatnot) could improve usability quite a bit, and might occasionally be worth the complexity of deferred-completion.

As is, one big intent for the command system is extensibility. Commands won't necessarily all be known/defined at compile time, as MEF may bring in additional commands at startup-time based on what extension DLLs you have present. Additinoal commands may be 'context-sensitive' such as, for example, when you're in the same room as a room-bound 'blackjack card table' object which gives you the special commands to 'hit', 'stay', etc, which would take precedence over global commands of the same name. (In this example, the blackjack table could be housed entirely in its own DLL and added to the game mainly through MEF, though an object instance would still have to thereafter be added by an admin or builder).

I don't understand what you're saying about the command processing tree... Windows does what?

Ok I made myself unclear. Sorry.
I understand the issue of "what of all these items that look alike or have the same type should I act on" puzzle; I just don't think its a big enough problem to add so much complexity that users may get further confused by it. I also feel, that as a MUD, we should be assessable to the largest player base you may not know about: The blind. Keeping things simple helps with both of these big issues.

Having multiple line commands adds additional complexity that can scare users away. Having commands start with a keyword and then be parsed based on the grammar allowed for that key word is simple, keeps complexity down, and gives a consistent interface. Its not just because I'm old, I like this because its initiative and it works.

Oh and to be clear: I'm not against propagation, but lets keep input for doing things simple, please?

---

[ed 2021] We eventually designed World Interaction User Story which IMO solves most of the discussed issues from these threads.