23 Jul, 2009, Kintar wrote in the 1st comment:
Votes: 0
I've been toying around with my own codebase for a while now, just trying various things and getting a feel for the scope of the problem. I'm finally getting around to trying to improve the parser to something that is more flexible, and seem to be running around in circles. Let me describe what I was doing, and what I'm trying to do, and see if anyone has past experience that they're willing to share that might help nudge me along in the right direction.

Right now, the parser uses a very basic expression-based command table and substring-based object binder that works something like this:
  • Use first word of input string to locate command in the dictionary

  • Split remaining input string based on the command's defined pattern (i.e., "take * from *")

  • Split each part of the resulting strings into tokens around whitespace. (so "take blue rock from chest" becomes "blue rock","chest", which becomes ["blue","rock"]["chest"])

  • Search the environment for items whose name fields contain all of the words in a group. Example: The previous input line might match the "blue shiny rock" and the "blue rock statue" inside the "forgotten pirate's chest"


Obviously, that was a quick and dirty hack for getting something I could play around with. Now that I've come back to the parser, I've been exploring some more complex parsing options. I'd like to end up with a parser that can successfully bind expressions like:
"hit the king with the third rock"
"take five monkies from the cage"
"put the sword of ice into my backpack"
"dance with the monkey from madagascar"

I've gotten very close by using a vocabulary that auto-generates from my entities' name and adjective fields to parse the input lines into a tree structure that holds information about the part of speech that each token in the input stream maps to. My problem is that I keep running down rabbit holes when I try and resolve ambiguity introduced by allowing prepositions to modify the nouns as well as the verbs. "the king with a beard", for example, causes massive issues with a command like "hit <living> with <weapon>". If the player types "hit the king with a beard with my sword", should we hit "the king" with "a beard with my sword", or should we hit "the king with a beard" with "my sword"?

So, finally to my question: Has anyone here played with NLP-style parsers in their own work, and if so, where do you draw the line on the breadth of the grammar that's accepted by your parser? Should I discard the idea of allowing arbitrary prepositional phrases in the input, and restrict the grammar to only allowing prepositions to be part of a command definition, or is there a middle ground that is generally accepted? Or am I completely missing the boat somewhere along the line and just don't see it?

Any ideas or commentary would be appreciated. Thanks!

(EDIT: Added example of why "king with a beard" poses a parsing problem for me.)
24 Jul, 2009, Idealiad wrote in the 2nd comment:
Votes: 0
I don't have great experience writing parsers, but I'm just curious if in your system you use disambiguation questions to the player so that they can refine their input, or if you're shooting for everything to be resolved by the parser?

My only suggestion is to look at the parsers for IF languages, such as Inform and Tads 3. They by far have the most sophisticated parser implementations for NLP in games. For muds though, I would suggest looking at the original MUD (or it might be MUD2, whichever is more developed).
24 Jul, 2009, David Haley wrote in the 3rd comment:
Votes: 0
I posted my thoughts/initial prototype to Nick Gammon's forums some time ago; here is the post.

If you read the accompanying documentation, you'll see that I certainly don't allow arbitrary English (which is completely unnecessary given the limited scope) but I do allow somewhat "complex" sentence structure, in that you can attach clauses to other clauses. Work still needs to be done, as I noted, for instance in understanding the difference between "from" and "to" when it comes to generating the logical form. For example, it should not generate several logical forms for the sentence "give the sword in the bag to Fred"; I think that fairly unambiguously should mean give <the sword <in the bag>> <to Fred>. But, since it has no knowledge of the semantics of prepositions, it can't figure that out.

In general, I think it is useful to write a grammar that is limited but feels natural. You cannot match normal English using a simple top-down parser, however you could write such a parser that matched very many sentences that people are likely to type into your command prompt. Basically, you have domain knowledge of the kind of things people are likely to want to do, and so you should exploit that when designing the grammar.
24 Jul, 2009, Kintar wrote in the 4th comment:
Votes: 0
Thanks for the responses!

Idealiad: I've grabbed the source for Tads 3, but haven't had time to dig into it yet. About a week ago I read an article series by Richard Bartlett about the way MUD2 parses commands. He's gone a bit overboard for my needs, though, and was very vague on certain details, like prepositional clauses attached to noun groups.

David Haley: Thanks! Your CLIP Parser is almost exactly what my first pass at a new parser turned out, so it's good to know the basics are sound. ;)

Unless someone else has extra input, I'm probably going to go with a tactic that limits the prepositions to a certain well-defined subset of English, and limits which ones can be used in connection with verbs, and which can be used in connection with nouns, and tweak it until it feels right. As much as I'd like to be able to parse something like "hit the oldest king of Paravel with a beard with the monkey wearing the dented amulet of Ra", I think that's a tad overzealous. :rolleyes: I'll be happy with a grammar that understands "of" as a prepositional phrase that joins on another adjective ("old king of Paravel" = n: "king", adj: "paravel, old"), and that "with" and "at" (and similar) are used to join noun phrases together for a verb.

Again, thanks for the feedback, guys. I've been working on this on my own, and was starting to think I'd lost perspective. Looks like I was right. :biggrin:
24 Jul, 2009, David Haley wrote in the 5th comment:
Votes: 0
Please keep us posted on your progress: I'm very curious to hear more. :smile: I'm reaching the point where I'll need smart command parsing as well, so I might have something more to post as well at some point.
24 Jul, 2009, Silenus wrote in the 6th comment:
Votes: 0
The LPC world has some examples of command parsers which vary in sophistication and generality. Maybe these might help you w.r.t. designing something. The FluffOS/MudOS distribution comes with a contrib parser package (the ZorkMud parser ported into the driver), DW lib comes with one written in LPC which arguably has more options and I think Tublib also has a parser built in. DGD comes with a tool parse_string() which allows you to sketch out a context free grammar and returns the various ambiguous parses(Ihesitate at this point to call this GLR because after skimming over the source I am not sure if it is).

To get fuller parsing of English probably requires more sophisticated grammar formalism like unification grammars but this may or may not be overkill depending on what you are doing.
24 Jul, 2009, Kintar wrote in the 7th comment:
Votes: 0
Thanks again for all the input, everyone. I had an epiphany last night, triggered by an unrelated comment from my wife. (Thanks, hon! :biggrin:)

The mud codebase I'm working on is component-based, so it's very simple to tell the class of a given object. The parse is greatly simplified if we resolve which of the available set of items is valid for the command before we attempt to parse the input line. Something like this; Say you're in a room with Spock and his evil twin from the antimatter universe. You want to hit the evil twin with a chair, but the only way to tell the difference is that damn goatee. (And no, I'm not writing a Star Trek MUD, it was just the first example that came to mind. *LOL*)

> hit spock with goatee with chair

First, we look up the trigger word in our command dictionary. We find that the definition for "hit" is "hit <damageable> with <weapon>". The first thing we do is collect all damageable items and all weapon items that are available to the thing that is performing the action. Say we get the following objects back:

damageable: [spock1, spock2, playerKintar, breakableDoor52]
weapon: [phaser42, scalpel12, chair9]

Next we look at the input to the verb. Much in the same way MudOS does their NL parser, there is a literal separator ("with") in the command definition, so we know we have to group our item references around the literal. If we make the parser smart enough to know that literals might appear in noun phrases, too, we can see that there are two situations we have to account for:

hit (spock) with (goatee with chair)
and
hit (spock with goatee) with (chair)

We now use a dictionary-based AST parser to parse each noun phrase in the first option. We end up with:

object: [n: spock]
indObj: [n: goatee [prep: with [chair]]]

We check for available Spocks in our collection of damageable items and know we've got at least one. Next we check for goatees in our list of weapons and find that there aren't any. The parser now backtracks and tries other groupings for the nouns:

object: [n: spock [prep: with [goatee]]]
indObj: [n: chair]

We try to find a Spock again, and get two. Now, however, we've got a prepositional modifier on the noun, so we use the object's predefined modifiers and find that one of them matches the prepositional clause "with goatee". That's our selected Object. We now look through our possible list of weapons for a chair, and find exactly one. Bingo! Binding succeeded, so we call our command handler with spock2 as the object and chair9 as the indirect object.

I think this will work for 99% of situations, if the core mud object has the proper data structures to hold descriptive clauses. What do you guys think?
24 Jul, 2009, Kintar wrote in the 8th comment:
Votes: 0
By the way, this parsing strategy will also work for command definitions that don't have a literal separator, as long as we keep a good dictionary of parts of speech based on the items in our mud. Our grammar can look like: (I'm using ANTLR's implementation of BNF grammar because I'm familiar with it. ? means match zero or once, * = zero or more, no modifier means match exactly once, | is an OR statement, parentheses group rules together like mathematical expressions.)

command   :    verb verbLiteral? freeText?
| verb freeText (verbLiteral freeText)?


This will solve commands like "take box", "take box from bag", "take box bag", and "take off armor". We can then pass the "freeText" blocks, if any, to a separate noun parser that uses the set of potential matches to derive its vocabulary. The grammar for that would look like:

noun  :  article? (adjective (conjunction adjective)*)? noun (nounPrep nounDescriptor (conjunction nounDescriptor)*)?


I think this will work! =)
24 Jul, 2009, shasarak wrote in the 9th comment:
Votes: 0
This sounds very interesting!

My one comment is that if you want this to be clever, you will need to include some knowledge about the player character's environment within the parsing routine.

It's not difficult to come up with an instruction that is genuinely ambiguous. For example: "put the key in the hat on the treestump". Are we saying "take the key that is currently in the hat out of the hat and put it on the treestump instead"? Or are we saying "there is an empty hat on a treestump here; place the key in that hat"? There's no way that any parser that only looks at the words typed can resolve that ambiguity - even a human reading those words out of context has no way of telling which was meant, because the English language itself isn't that precise. The only way you can distinguish between them is to know something about the context in which the command was issued.

In the room where the player currently is, is there an empty hat sitting on a treestump? And is there a key present elsewhere in the room or in the player's inventory? If so then the player clearly meant "put the key into the hat".

If there isn't a hat on a treestump, but there is a hat somewhere else with a key in it, and there is a treestump present, then clearly the player meant "take the key out of the hat and put it on the stump".

So, ideally the first stage of the parser should actually come up with multiple possible interpretations, and the second stage of the parsing process should then examine which of those possibilities actually makes sense within the context that the command is typed.

EDIT: Bah, took way too long to type this and was anticipated by the two previous posts. Oh well. :(
24 Jul, 2009, flumpy wrote in the 10th comment:
Votes: 0
@Kintar

I started out in exactly the opposite way to you. I initially started using something called "antlr" which does what your tree implementation seems to do. After all, any "language" from programming to natural language follows some rules. The trouble is, the more complicated your phrase the more complex the tree needs to be.

I quickly realised I was actually over-complicating things, and I should work back to a more simple regex based model. I realised too that I wanted to achieve what you started out with. My main reasoning was this: there are many exceptional phrase structures that can occur in natural language, and I could be there forever trying to guess what the user meant if I didnt ask them explicitly. Either that or I might end up having to generate very many spurious tree structures with far too many branches for an average user to remember.

For example, in one of the examples you gave about the bearded man, I would either have to ask which "with" meant "using" or have the user remember a spurious rule that if they have a sentence with "with" in it, they need to specify "using" instead. On its own this is not too bad, but with all the other rules it could become too much.

I suggest that you would have to keep in mind your user here. Like any other user interface, a player can become bogged down with choice, or annoyed that they cannot do simple things easily. If you are constantly asking them for prompts, or trying to get them to remember rules, they will quickly get bored.

Not that you shouldnt try to do this for fun of course ;)
24 Jul, 2009, Kintar wrote in the 11th comment:
Votes: 0
@flumpy

A very good point; That's actually the issue I was posting about in the message that started this thread. I'm pretty sure that the two-stage parse will resolve that issue most of the time, however. In the bearded man example:

>hit king with beard with axe

Let's assume you've got the following rules for the verb "hit":

hit <thing>
hit <woundable> with|using <weapon>

Attempting the first rule, we end up with the following parse tree for "king with beard with axe":
noun: king [
prep: with [
descriptor: beard ]
prep: with [
descriptor: axe ]
]


The parser will discard this as an invalid structure, since the grammar says you're not allowed to specify two prepositional phrases on the same noun. It will then move on to the next rule, which yields the following possible noun groups:

"king", "beard with axe"
"king with beard", "axe"

Parsing the first group yields:
noun1: king

noun2: beard [
prep: with [
descriptor: axe ]
]


This will fail to bind, because there are no beards in the room that have the phrase "with axe" assigned to them. It then tries to bind the second form:
noun1: king [
prep: with [
descriptor: beard ]
]

noun2: axe


This will bind, since there is a king with a beard, and an axe.

The only case where this would be ambiguous is if the description of the king contained an axe, and the player is using an axe. This means we have to introduce one slightly abstruse grammar rule about prepositional phrases on nouns. The proper form would be something liek "hit king with beard and axe with axe", but I think that's fairly likely to be the way the player would enter the command anyway. … Well, assuming the builders are annoying enough to put the player in a situation where that many noun descriptors are required! Typically, "hit king with axe" should be enough. =)

( EDIT: My kings keep having "bears" instead of "beards". :P )
24 Jul, 2009, flumpy wrote in the 12th comment:
Votes: 0
Kintar said:
Thanks again for all the input, everyone. I had an epiphany last night, triggered by an unrelated comment from my wife. (Thanks, hon! :biggrin:)

The mud codebase I'm working on is component-based, so it's very simple to tell the class of a given object. The parse is greatly simplified if we resolve which of the available set of items is valid for the command before we attempt to parse the input line. Something like this; Say you're in a room with Spock and his evil twin from the antimatter universe. You want to hit the evil twin with a chair, but the only way to tell the difference is that damn goatee. (And no, I'm not writing a Star Trek MUD, it was just the first example that came to mind. *LOL*)

> hit spock with goatee with chair

First, we look up the trigger word in our command dictionary. We find that the definition for "hit" is "hit <damageable> with <weapon>". The first thing we do is collect all damageable items and all weapon items that are available to the thing that is performing the action. Say we get the following objects back:

damageable: [spock1, spock2, playerKintar, breakableDoor52]
weapon: [phaser42, scalpel12, chair9]

Next we look at the input to the verb. Much in the same way MudOS does their NL parser, there is a literal separator ("with") in the command definition, so we know we have to group our item references around the literal. If we make the parser smart enough to know that literals might appear in noun phrases, too, we can see that there are two situations we have to account for:

hit (spock) with (goatee with chair)
and
hit (spock with goatee) with (chair)

We now use a dictionary-based AST parser to parse each noun phrase in the first option. We end up with:

object: [n: spock]
indObj: [n: goatee [prep: with [chair]]]

We check for available Spocks in our collection of damageable items and know we've got at least one. Next we check for goatees in our list of weapons and find that there aren't any. The parser now backtracks and tries other groupings for the nouns:

object: [n: spock [prep: with [goatee]]]
indObj: [n: chair]

We try to find a Spock again, and get two. Now, however, we've got a prepositional modifier on the noun, so we use the object's predefined modifiers and find that one of them matches the prepositional clause "with goatee". That's our selected Object. We now look through our possible list of weapons for a chair, and find exactly one. Bingo! Binding succeeded, so we call our command handler with spock2 as the object and chair9 as the indirect object.

I think this will work for 99% of situations, if the core mud object has the proper data structures to hold descriptive clauses. What do you guys think?


Hah I didn't read this thread fully before I replied :D

This sounds like a very good way to do things. However, how would you make sure the spock you select has a goaty? Or that indeed the chair has not (silly i know)? *EDIT ok you answered my question in the previous post :)*

These kind of hints would not want to be provided by the user, so if you can devise some way to do this I would be very interested in seeing your AST :D

*EDIT 2: This is making me want to go back and revisit my ANTLR implimentation again. I'm getting all excited thinking about it. Man I'm such a geek… My main problem was with generating all those trees, and figuring out the grammars. You seem like you know more about the subject than me, I was just dabbling, so if you can get something half decent I'd be /very/ interested to see.*
24 Jul, 2009, shasarak wrote in the 13th comment:
Votes: 0
Kintar, if one issues the command "hit goblin with knife", how does your proposed system decide whether the player means "use the knife I'm holding to hit the goblin" or "punch the goblin who is holding a knife"? I don't think you can assume that if the word "with" appears at least once that there must be a mention of the weapon.

It's also worth mentioning that there can be three possible interpretations of an example grammatically similar to your spock/goatee example, not two. Consider "hit goblin with dagger with ebony blade". That could mean "punch the goblin who is holding an ebony-bladed dagger", "use my ebony-bladed sword to hit the goblin who is holding a dagger" or "use my ebony-bladed dagger to hit the goblin".

In the spock/goatee example, a human would be able to tell fairly easily which one is meant, partly from the grammar and partly from the semantics. A human knows that you cannot use a goatee as a weapon, and knows that a goatee cannot be armed with a chair - maybe your parser should be given knowledge like this?

With the best will in the world, you will eventually come across ambiguous situations (e.g. "hit goblin with knife" issued when both the player and the goblin are wielding knives) so you have to be willing for the parser to give up and ask for clarification too. :)

EDIT: crossed in the post again, I'm bowing out of this! :)
24 Jul, 2009, Kintar wrote in the 14th comment:
Votes: 0
@flumpy: I'll definitely share whatever I come up with. I've been researching this for quite a while now, and Richard Bartlett's articles from almost 10 years ago are the only detailed discussions I can find, so I definitely want to open the discussion up a little more. :)

shasarak said:
EDIT: crossed in the post again, I'm bowing out of this! :)


Don't bow out! You're bringing up very good points, and anything that can be done to further clarify them is awesome. :) Your last example, especially, needs to be thought about:

> hit goblin with knife

If there is a "goblin with knife", then we either need a rule stating that social commands (hit <thing>) take precedence over potentially deadly commands (kill|hit <killable> with|using <weapon>), or the parser needs to stop and ask:

> hit goblin with knife
Did you mean you want to:
(social command)"hit 'goblin with knife'"
Or do you want to:
(combat command)"kill 'goblin' using 'my knife'"?
24 Jul, 2009, Kintar wrote in the 15th comment:
Votes: 0
shasarak said:
For example: "put the key in the hat on the treestump"


I meant to directly address this, too, but forgot. :)

The grammar I'm outlining is simple enough that "in" probably won't be one of the allowed prepositions for nouns. BUT, if we did want to do this kind of detailed parsing, the following might work:

Definitions:
put <thing> in <container>
put <thing> on <surface>

We'd end up with the following potential parses:
put (the key) in (the hat on the treestump)
put (the key in the hat) on (the treestump)

Binding will once again save the day, albeit with a very complex set of rules about noun prepositions.

Preposition rule: <thing> on <surface>
Preposition rule: <thing> in <container>

This now turns our two-phase parser into a three-phase parser.

Case 1: [n: key], [n: hat [prep: on [ treestump ]]]

For this case to succeed, the third phase parser (the prepParser) would have to locate a "treesump" surface object in the actor's location, and find an object named "hat" that passes the "on" preposition rule. The second phase parser would then verify that the "hat" object is ALSO a surface object. If not, the bind fails, and the next rule is considered.

Case 2: [n: key in hat], [n: treestump]

For this case to succeed, the prepParser would have to find an accessible container object named "hat" that passes the prepositional test for "key in", and also locate a "treestump" that is a surface object.

Hmm…I like the sound of this. So, maybe:

Phase 1: Verb binding. Locate all verbs that match the input's trigger word.
Phase 2: For each verb, parse the input according to its prepositional phrases to obtain one or more lists of noun phrases.
Phase 3: For each noun phrase, attempt binding. If the noun phrase contains a prepositional phrase, look up the rule for that prepositional phrase and parse.
Phase 3a - Preposition parsing: Split the input tokens around the preposition and run Phase 3 for each resultant noun phrase.

If any phase fails to produce viable results, the parser stores the tokens it successfully bound and then backtracks to the previous phase. Once the complete parsing/binding algorithm completes, that completed parse is stored. After all options are parsed, if only one completed parse exists, that's the target. If no completed parses exist, the failed parse results are presented to the player so they can disambiguate their input. If more than one parse produced a successful result, these are presented to the player and they're asked to choose.

This was typed in about 10 minutes between meetings at work. PLEASE tell me what I've missed, 'cause there's bound to be something. ;)
24 Jul, 2009, David Haley wrote in the 16th comment:
Votes: 0
Hmm… I know that my documentation/example was very cursory, but what you've been talking about is actually what I had done. Verbs have logical form structures attached to them that show how to build the semantics on top of the prepositional phrases you get. For example, in the phrase "put the thing in the bag", 'in the bag' could be associated with the thing, like put <the thing <in the bag>>, or it could be at the same sentence level, like put <the thing> <in the bag>. Now, the verb 'put' would know that it expects a thing to put and a place to put it, so it can reject one of the parse trees and construct an appropriate logical form.

So yes, I know my example in the earlier post was very brief as were the accompanying texts, but there might be some more stuff in there that could be useful to you.

The implementation in particular makes the backtracking parsing a breeze; I use kind of a hybrid of finite state automata and a top-down parser.
24 Jul, 2009, shasarak wrote in the 17th comment:
Votes: 0
Suggestion: if the parser detects genuine ambiguity then why not have it offer numbered alternatives, so that if the next command the player types is a number, it will execute the corresponding command. Something else you need to pay careful attention to is making sure that the parser is able to generate output for its alternatives that is phrased unambiguously enough for the player to be able to understand!

E.g.

Player types: hit goblin with knife
Parser identifies two possibilities: stab goblin using knife, or hit goblin who has knife.
Parser checks to see if there a is a knife either in the player's inventory or in the room. There is. Parser checks for the presence of a goblin and detects one.
Parser checks to see if there is a goblin in the room holding a knife. There is.
Parser concludes there is ambiguity.
Output: Do you mean 1: 'use knife to hit goblin' or 2: 'hit goblin who has knife'?
Player types: 1
Output: You stab the goblin!


EDIT: In cases where none of the parsed alternatives are valid, is it useful to list all of them?

E.g.

Player: hit goblin with knife
Output: There is no goblin here who has a knife. There is also no knife here with which you can hit a goblin, and, indeed, no goblin that you could hit with a knife even if you had one.

That might be a little excessive, but a parser as sophisticated as this may be something that players aren't expecting, so if they get a simple "can't do that" message they may just assume that the parser is being dumb rather than than it has actually understood you correctly and determined that you can't do what you're trying to do.

Here's an interesting one: there's a crowbar sitting on top of a boulder, and the player types lift boulder with crowbar. To a human that obviously means you should use the crowbar to lift the boulder; how does the game figure out that you don't mean "lift the boulder that has a crowbar on it"? That's the sort of thing for which you need to have background information about the uses of objects. If the parser knows that a goatee cannot be a weapon, then it knows not to bother with that interpretation of "hit spock with goatee". :)
24 Jul, 2009, Grimble wrote in the 18th comment:
Votes: 0
While I think natural language parsers are very interesting, I'm wondering if they're worth the effort, particularly since they are prone to the ambiguity of human language.

Obviously the application is a significant factor, and MUDs seem like a good candidate. But, being the lazy typist I am, I'll use the minimal text I can to issue a working command (e.g., "kill goblin" vs. "kill the green goblin with my rusty axe"), at which point I'm bypassing many features of the parser.

I'm revealing my age here, but did play Zork in the early 80s and remember being frustrated with trying to get the parser to understand the intent of my commands. Fixed syntax (e.g., unix shell commands) would have been preferable in my case.
24 Jul, 2009, Kintar wrote in the 19th comment:
Votes: 0
@David Haley

I finally read the PDF documentation for your parser. (Sorry, been busy today. :)) It's eerily similar to the track I've been taking with my project! I especially like the concept of pausing the parsers after the first tree is generated, and resuming them to yield a second result. That gives me an idea about my own implementation; thank you!

The one thing I think would make the biggest difference in the final logical form is the ability to associate functionality with nouns. For example, for the input "give sword goblin", CLIP returns "give(dest=sword ;gift=goblin ;)". If the 'give' verb was told that the destination has to be something that's capable of holding things, and the nouns were given the ability to hold that kind of information, then the parser would be able to recognize that the proper form would be "give(dest=goblin ;gift=sword ;)". This still wouldn't help the horribly ambiguous phrase "give bag goblin", but I think it's a step in the right direction. ;)

I'm especially excited about this direction as my domain model for my mud isn't object oriented, but rather component based. (We can fork this to a discussion of component systems if there's enough interest, by the way. I'd love to hear people's thoughts.) This means that for a given item, I've got a huge amount of information that can be used to disambiguate its semantic use in a sentence.

give sword goblin
goblin : Container, Living, Destructible, Woundable, Skilled
sword : Destructible, Weapon

Using this information, the parser (or the binder) could consult a list of rules about 'give' and determine that it's not possible to 'give' to a thing that isn't a Container, and therefore "give(object=sword; indobj=goblin)" isn't a valid parse.
24 Jul, 2009, Kintar wrote in the 20th comment:
Votes: 0
Grimble said:
Obviously the application is a significant factor, and MUDs seem like a good candidate. But, being the lazy typist I am, I'll use the minimal text I can to issue a working command (e.g., "kill goblin" vs. "kill the green goblin with my rusty axe"), at which point I'm bypassing many features of the parser.


I agree, which is why I feel any NLP designed for a mud should also be able to understand the more compact, speed-typist syntax. You'll notice that in all the examples I've given, prepositions and adjectives are always optional, and the parser should be able to work out the meaning of a command based on the class of the nouns it is given.

The main place where the extra flexibility of the parser would be handy is in areas where there are multiple nouns that match a given input. I can't tell you how many times I cussed a Diku-based MUD because I was in a room with ambiguous nouns. Most Diku derivatives I've played don't understand even basic adjectives, and that's what started me down this path.
0.0/22