31 Jul, 2010, Deimos wrote in the 1st comment:
Votes: 0
I'm just wondering, as MUD players, what kind of input system do you prefer - one that prompts you for clarity if there's any kind of ambiguity in your issued command, like this:

> e s
Did you mean east or eat?
> eat s
Would you like to eat a salami or a strawberry?
> eat straw
You eat a strawberry.
>

Or, do you prefer that your commands default to the first match, like this:

> e s
You go east.
> eat s
You eat a salami.
> say crap, i was saving that for a friend!
You say, 'crap, i was saving that for a friend!'
>

There are obvious advantages/disadvantages to both methods, and I personally prefer the latter method, since I find it highly annoying to have to type out commands (read: I'm lazy), but I just wanted to kind of gauge what other players were expecting out of a game.
31 Jul, 2010, bbailey wrote in the 2nd comment:
Votes: 0
Deimos said:
I'm just wondering, as MUD players, what kind of input system do you prefer - one that prompts you for clarity if there's any kind of ambiguity in your issued command, like this:


In general, I prefer input handlers that allow ambiguity, given that there is consistency in how such ambiguities are resolved. I want to be able to input "eat s" but only when I can know what "s" will resolve to before I execute the command. If I can't know how the command will be matched, I enter as unambiguous of a command as I can anyway which obviates the advantages of the system.
31 Jul, 2010, Deimos wrote in the 3rd comment:
Votes: 0
Hmm, well I've never seen a system that wasn't consistent at least down to the command level (though I've seen some that weren't cross-command consistent), but that's definitely a good point. However, the system can be completely consistent and still produce unintended actions a lot of the time. I guess that's what I'm looking to help prevent, but I haven't found a good solution yet.
31 Jul, 2010, Hades_Kane wrote in the 4th comment:
Votes: 0
The 2nd option.
31 Jul, 2010, Idealiad wrote in the 5th comment:
Votes: 0
I prefer ambiguity questions (the first option) but with precedence rules, so if I'm holding the strawberry but the salami is in my backpack, I eat the strawberry, and so on.
01 Aug, 2010, Deimos wrote in the 6th comment:
Votes: 0
Idealiad said:
I prefer ambiguity questions (the first option) but with precedence rules, so if I'm holding the strawberry but the salami is in my backpack, I eat the strawberry, and so on.

If I'm understanding you correctly, what you're saying is that if you're holding a strawberry and have a salami in your backpack and type "eat s," you would eat the strawberry, but if you were holding both, it would prompt you? In other words, as long as there's only one option in the scope currently being checked, any other options in other scopes should be ignored? Hmm… that sounds like it would work pretty well, actually.
01 Aug, 2010, Idealiad wrote in the 7th comment:
Votes: 0
Yes that's right – it comes from my playing of IF. Most IF games written in a well-developed system (Inform, Tads 3, Hugo, etc.) will display this behavior.

edit to add: well, sort of – many don't use abbreviations like 's', but that's more a default thing, you could do it if you wanted to.
01 Aug, 2010, KaVir wrote in the 8th comment:
Votes: 0
I prefer the second, but you could always make a configurable option.
01 Aug, 2010, quixadhal wrote in the 9th comment:
Votes: 0
I actually think it might be best if the behavior changed based on the type of command being issued.

"look sa" would be perfectly acceptable for just examining salmon or salamander, whichever came first in the list. You can easily do the command again if it was the wrong one.

"kill sa" is a bit more dangerous. If the salmon is level 3, and the salamander is level 99, and you're level 4… it might be unpleasant if the parser chose for you, and you didn't like that choice.

"dest sa" can be even worse, since perhaps the salamander is just a random mob corpse, but the salmon is a rare drop that's part of an epic quest chain, and now the parser just helped you nuke it and lose weeks worth of work.

"delete sa" might be disasterous if you're a builder and you just deleted that salmon quest item from the database, instead of the salamander that nobody likes.

I realize you can stick an "are you sure you want to drop the salmon?" thing on there, but honestly… when people are excited or in a hurry, they tend to reflexively hit "yes<enter>" before what was printed sinks in. And, unless you want to really annoy everyone, that means your commands have to somehow evaluate the relative importance of objects/mobs/etc when deciding to show the "are you sure?" prompt.

So, from a design point of view, I'd probably use two different ambiguity resolution routines, based on what the commands do.
01 Aug, 2010, Idealiad wrote in the 10th comment:
Votes: 0
quixadhal said:
I realize you can stick an "are you sure you want to drop the salmon?" thing on there, but honestly… when people are excited or in a hurry, they tend to reflexively hit "yes<enter>" before what was printed sinks in. And, unless you want to really annoy everyone, that means your commands have to somehow evaluate the relative importance of objects/mobs/etc when deciding to show the "are you sure?" prompt.


You can phrase the question differently; instead of going to a yes/no prompt, you can say "Do you want to drop the salmon or the salamander?". That creates a temporary 'minor mode' where you can then type 'sala' or 'salm'.
0.0/10