Parsing user input.
Goto page 1, 2  Next
 
Post new topic   Reply to topic    mudlab.org Forum Index -> Design
View previous topic :: View next topic  
Author Message
Greggen



Joined: 16 May 2005
Posts: 36

PostPosted: Sat Sep 24, 2005 11:25 am    Post subject: Parsing user input. Reply with quote

Hi there,

After reading Dr. Bartle's series of articles on command parsing, I have implemented something similar on my MUD, with the exception of adverbs. A backtracking parser extracts a verb, subject and preposition from each sentence.

My first problem:

"put the key on the table on the shelf"

Where does the reference to the object end and the preposition begin?

"put (the key on the table) on (the shelf)" is probably what the user meant.

Bartle suggests choosing one grouping and sticking to it, so your users know what to expect. The problem comes with the way my MUD works: I have very minimalist descriptions with lots of nested detail. Commands like the following will be fairly commonplace:

"take the key in the chest on the table"

I do not want this to be interpreted as "take (the key in the chest) on (the table)", which doesn't make sense. I need "take (the key in the chest on the table)" i.e. no preposition. I can't think of any preposition the 'take' verb would use at all, in fact. Maybe "take the hot coal with the gloves" or something.

I think there are two ways of solving this: associate prepositions with verbs, so the parser knows what to expect. You lose some flexability this way though, I think.

Another way would be for the parser to generate every permutation and the binder check against the enviroment for context.

e.g. "put the key on the table on the shelf"

would generate:
  • put (the key) on (the table on the shelf)
  • put (the key on the table) on (the shelf)
  • put (the key on the table on the shelf)


The binder then checks if any are valid. The downside is this is a bit tricky to get my head around, and I'll probably be in for a lot of brain hurt coding this.

My second problem is more of an interface one. Combat in my game consists of discrete actions that have an "Action Point" cost. This doesn't sit well with a pseudo-english parser, so I also have a system where commands are distinguished with an '@' symbol (e.g. @quit @swing). Commands are associated with objects, so a sword would probably have @swing(cost 5 AP) and @thrust(cost 3 AP).

Does this system seem confusing? Any thoughts on it?

Some more general questions: What kind of parsing does your game use? What would you like it to use?
Back to top
View user's profile Send private message Send e-mail Visit poster's website MSN Messenger
Author Message
Lindahl



Joined: 29 May 2005
Posts: 56

PostPosted: Sun Sep 25, 2005 5:35 pm    Post subject: Re: Parsing user input. Reply with quote

Well lets consider why you'd want to try to create a real english parser. There are two reasons - one is just to do it, its a neat feature, the other is to make life easier for your users. The first reason can't really be debated, but I don't think the second reason really is applicable.

Considering that MUD verbs are very well established, you're really only hurting yourself. With one method (sticking with only one format) you're introducing something that isn't easily conveyed to your users, and, in addition, they must memorize it. With the other method (having the server use deduction), you're introducing ambiguity, that is defaulted to the first method, in the case of real ambiguity (even worse). I don't see a more complex english parser as a benefit to the user experience - especially since it has no effect on the feel to the game, just how the user can talk to the server.

There is, however, something to be said about allowing emote commands which, once verified, execute a command as well as displaying the exact verbage typed by the user. But I don't believe this is what you were trying to do.

You certainly should attempt some simple prepositional parsing, but you should also try and keep it simple and reject any complexity added by the user. However, if you are interested in continuing, I'd suggest sticking with one prepositional format, universally - anything more and the users will find it much more difficult to use, IMO.
Back to top
View user's profile Send private message
Author Message
KaVir



Joined: 11 May 2005
Posts: 565
Location: Munich

PostPosted: Mon Sep 26, 2005 8:16 am    Post subject: Reply with quote

As cool as I think a natural language parser would be, I can't help but agree with Lindahl's points. I implemented such a parser for my old mud, but it was a lot of work and ended up making the interface more confusing for the players, to the point that I decided not to bother for my current mud.

If you want to do it for the 'neatness' factor, I'd suggest having it togglable. You might also want to consider using the same system for handling communication with mobs, as that's something where the ambiguity can actually add to the gaming experience.
Back to top
View user's profile Send private message Visit poster's website
Author Message
Greggen



Joined: 16 May 2005
Posts: 36

PostPosted: Mon Sep 26, 2005 9:46 am    Post subject: Re: Parsing user input. Reply with quote

I disagree. The reason I was trying to do this was to emulate old adventure games. I personally didn't have to read any manual for those games, it was fairly natural. I can't say that for most MUDs, except for the basics of moving about. Some parsers don't even accept articles!!

Try one for yourself. The first thing this game says to me is "It's pitch black". Ok then, "turn on a light". Bingo!! However, my OCD took over and I then tried to "clean the room". (EDIT: Interestingly, I've just noticed it can handle questions like "where am I?".)

Lindahl wrote:
Considering that MUD verbs are very well established, you're really only hurting yourself.


MUD verbs are only well establised to people who have played MUDs before. More importantly, commands you see in most MUDs will still work with my parser; Their grammar is a subset of mine.

Quote:
especially since it has no effect on the feel to the game, just how the user can talk to the server.


I must disagree quite strongly here. It has a massive effect on my gameplay experience.

Quote:
There is, however, something to be said about allowing emote commands which, once verified, execute a command as well as displaying the exact verbage typed by the user. But I don't believe this is what you were trying to do.


That's interesting. I'll have a think on how this can be applied to emotes.

I'm afraid I don't completely comprehend your general point. How will more flexibillity harm a user's experience? I can perhaps see how the parser might make promises it can't keep, i.e. The user realises the parser is quite flexible and tries a command that looks like it should work but doesn't. I think the way to combat this is with informative error messages -- perhaps it didn't understand the verb, or couldn't find the object, or didn't understand the preposition.
Back to top
View user's profile Send private message Send e-mail Visit poster's website MSN Messenger
Author Message
KaVir



Joined: 11 May 2005
Posts: 565
Location: Munich

PostPosted: Mon Sep 26, 2005 10:08 am    Post subject: Reply with quote

Quote:
MUD verbs are only well establised to people who have played MUDs before.


However that's going to make up the vast majority of your players, unless you're advertising in gaming magazines or something.

Quote:
More importantly, commands you see in most MUDs will still work with my parser; Their grammar is a subset of mine.


How does your parser differentiate between 'get sword backpack' and 'get flaming sword'? I suppose you could force players to add the word 'from' - that's what I did with my old mud. It really irritated the Diku players though (and as the mud was a Diku derivative, almost all of them were from that background).
Back to top
View user's profile Send private message Visit poster's website
Author Message
shasarak



Joined: 29 Jun 2005
Posts: 134
Location: Emily's Shop

PostPosted: Mon Sep 26, 2005 10:54 am    Post subject: Reply with quote

Quote:
I can't think of any preposition the 'take' verb would use at all, in fact.

Two obviously possibilities are "from" and "out of".

However, I'm firmly of the opinion that a system like this does more harm than good unless it can actually be made context-sensitive. Why? Because natural language is context-sensitive by definition. Natural language is what people actually say or actually write/type when communicating with other people. And, when you talk to another person, there is always a context, and anything and everything and everything you say is interpreted within that context.

My standard example:

"Put the key in the hat on the tree-stump".

That could mean:

"There is a key in the hat. (The hat is nowhere near the tree-stump). Take the key out of the hat and put it down on the tree-stump."

Or it could mean:

"There is a hat sitting on a tree-stump. Somewhere else (in my pocket, for example) there is a key. Take the key and put it in the hat."

In a real-life situation it is obvious from context which one you mean. For a system like this to be of any use at all (IMO), it has to understand that you might mean either possibility, and determine which one on-the-fly. So, if the user enters that command, the system should then check to see:

- Is there a hat on a tree-stump?
- Is there a key already in a hat somewhere?

And the response will be determined by the answers to those questions. In fact, ideally, you need to do enough analysis to be able to determine which, out of all of the following responses, is appropriate:

"There is no key here."
"There is no tree-stump here."
"There is no hat here."
"There is a tree-stump here, but it doesn't have a hat on it."
"There is no key in the hat."
"You have a key, but it is not in the hat."
"The key is already on the tree-stump."
"There is a hat here, but it is not on the tree-stump."
"The key is already in the hat, although the hat is not on the tree-stump."
"O.K."
"Do you mean I should take the red key out of the green hat and put it (the key) on the treestump, or do you mean that I should take the blue key and place it in the purple hat (which is on the tree-stump)?"
"The key is already in the hat on the tree-stump."

As Lindahl points out, unless you do this level of analysis on the original command, it will only work correctly some of the time. This means that you are encouraging users to switch from a command system that is a little slow but which always works, to one that only works sometimes. To my mind, that's making things worse rather than better.

If it were the case that a particular system based on grammatical parsing alone got it right 98% of the time, then there would be a case for using it. But if it only gets it right 60% of the time, it's going to do more harm than good.

A separate issue is the question of how far you can abbreviate instructions when they cease to be grammatical at all. If I say "give the sword to KaVir" that's unambiguous. The most natural abbreviation of that (and a gramatically correct abbreviation, according to the rules of collquial grammar) would be "give KaVir the sword"; or, if you wanted to abbreviate it still farther, "give kavir sword". Unfortunately Diku was written by people whose native language was not English. In Diku, you have to say "give sword kavir". This is senseless, but it's also an established convention.

Worse still, different codebases have different conventions. If you want to pick up the second of two swords in an old LP Mud you say "get sword 2". On Diku you say "get 2.sword".

I think the best way to handle this is actually to allow both possiblities, but to give the player a "console setting" which allows him to choose which of the various possible parsing methods he prefers to use, depending on what he is accustomed to. You could, I suppose, extend this idea to the originally-suggested prepositional analysis. if the user himself can choose in advance can choose whether "put key in hat on treestump" means "put (key in hat) on treestump" or "put key in (hat on treestump)" then that's slightly less objectionable than forcing a choice on him.

Or you could appeal to techies by allowing them to use brackets to determine operation priority. Smile

But, IMO, context-sensitivity is still really the only way to go, if you want to go beyond the standard instruction set at all.
Back to top
View user's profile Send private message
Author Message
Greggen



Joined: 16 May 2005
Posts: 36

PostPosted: Mon Sep 26, 2005 11:08 am    Post subject: Reply with quote

Quote:
How does your parser differentiate between 'get sword backpack' and 'get flaming sword'?


That's one of those tricky ones that's resolved by context. "get sword from backpack" or "get the sword in the backpack" will definitely work.

I could make your example work with a backtracking parser resolving by context if I wanted to, but it would actually be more consistent with my game design to leave it how it is (<--- this is possibly an excuse to be lazy).

So, yes, I guess there will be incompatibilities I hadn't thought of. I am fairly certain these incompatibilities will be few and far between -- small annoyances rather than game-breaking. I am also fairly certain these annoyances will be made up for by additional flexibility these same users never had before.

If these players come into my game expecting a traditional DIKU style, they are in for more of a shock than a couple of commands not working correctly anyway. Like I mentioned before, I hope to make my game resemble old adventure games rather than dungeon hacks.

Quote:
However that's going to make up the vast majority of your players


My personal experience tells me differently. I played a MUD for a few years and there were an awful lot of players who had never used a MUD before. It was my first MUD too. This may have had something to do with them starting their name with 'aa' though. The cheap bastards.
Back to top
View user's profile Send private message Send e-mail Visit poster's website MSN Messenger
Author Message
shasarak



Joined: 29 Jun 2005
Posts: 134
Location: Emily's Shop

PostPosted: Mon Sep 26, 2005 11:38 am    Post subject: Reply with quote

Quote:
So, yes, I guess there will be incompatibilities I hadn't thought of. I am fairly certain these incompatibilities will be few and far between -- small annoyances rather than game-breaking.

And I'm fairly certain they won't be. I guarantee you that any non-context-sensitive rule you think up for a situation like this, I can think of a common example where it will fail. Try me. Smile

Quote:
I am also fairly certain these annoyances will be made up for by additional flexibility these same users never had before.

What additional flexibility? What actions can the player carry out with this system that he couldn't carry out before? All you've done is added ambiguity, and made the player have to remember additional rules about the way the parser works.

There are one or two actions you can't carry out with standard MUD instructions, but they're nothing to do with a lack of natural language. Instructions like "pick up red hot iron with tongs" - i.e. using something other than your hand to pick something up. Or use of adverbs: "turn knob gently to the right", "pull lever hard", etc.

If (for example) you have a situation where the only way you can usefully distinguish one key from another is by its position, then the problem is that your objects are not adequately described and distinguished. There is nothing to be gained by allowing the player to type "put key in pocket on shelf" as distinct from "put small brass key on shelf" (assuming both refer to the same key). The former is ambiguous, the latter is not, unless you have a multiplicity of small brass keys. If you have, make one of them a large, wrought-iron key, one a tiny copper key, one an intricately-carved bone key, etc.
Back to top
View user's profile Send private message
Author Message
Greggen



Joined: 16 May 2005
Posts: 36

PostPosted: Mon Sep 26, 2005 11:44 am    Post subject: Reply with quote

shasarak wrote:
However, I'm firmly of the opinion that a system like this does more harm than good unless it can actually be made context-sensitive.


I am certainly thinking towards implementing a context-sensitive parser, as I outlined briefly in my original post. That has its own set of problems, however.

Quote:
"Put the key in the hat on the tree-stump".

Quote:
... it will only work correctly some of the time.


This is why Bartle suggest using a consistent, if sometimes wrong, behaviour. The users will know what to expect after using parser for a while.

They will learn "put the key in the hat on the tree-stump" means "put (the key in the hat) on (the tree-stump)" and not "put (the key) in (the hat on the tree-stump)".

Of course context-sensitivity is ideal.

Quote:
If it were the case that a particular system based on grammatical parsing alone got it right 98% of the time, then there would be a case for using it. But if it only gets it right 60% of the time, it's going to do more harm than good.


What if it got it right 99% of the time for simple commands, yet allowed more complicated commands that worked well enough once you had worked out their quirks?

Quote:
Worse still, different codebases have different conventions


Although I try to make things comfortable for as many as possible, I have little to no respect for convention.

I don't think this is a bad thing. Why would you want every game to have a similar interface? It'd be very constricting. These aren't business applications -- people want games to be different, I believe.

For an existing example, take a look at Kavir's godwars2 which is coordinate based. Try to accomadate DIKU players, yes. Provide 'north', 'east', 'south', 'west' and 'kill' commands. But these commands aren't well suited to the game at all. You'd expect players to stop using them eventually.
Back to top
View user's profile Send private message Send e-mail Visit poster's website MSN Messenger
Author Message
Greggen



Joined: 16 May 2005
Posts: 36

PostPosted: Mon Sep 26, 2005 11:55 am    Post subject: Reply with quote

Quote:
What additional flexibility?


This is difficult to convey. I suggest first playing through the game I linked earlier.

DIKU commands can do anything this parser can do the same way an assembler can do anything Ruby can do. It's technically true, but one is much more graceful.

To extend the programming analogy, it's also "the right tool for the right job". I believe this kind of parser will just suit the style of my game a lot more.

I guess flexibility was the wrong word -- it's more about feel. A pseudo-english parser feels like you're talking to the game, rather than programming your player character to carry out commands.

Also, I find a well constructed parser becomes a joy in itself to use. I find myself thinking "Wow! I'm impressed! It understood that perfectly." more often than I think "Arrggh! I'm frustrated! That's not what I meant at all!".


Last edited by Greggen on Mon Sep 26, 2005 12:05 pm; edited 1 time in total
Back to top
View user's profile Send private message Send e-mail Visit poster's website MSN Messenger
Author Message
KaVir



Joined: 11 May 2005
Posts: 565
Location: Munich

PostPosted: Mon Sep 26, 2005 11:57 am    Post subject: Reply with quote

Quote:
So, yes, I guess there will be incompatibilities I hadn't thought of. I am fairly certain these incompatibilities will be few and far between -- small annoyances rather than game-breaking.


They won't be game-breaking, but they're the sort of annoyances that will detract from the game for those who are used to a different interface. As silly as it might sound, one of the main reasons I never really got into LPmuds was because - coming from a Diku background - I felt very uncomfortable with the command syntax.

Quote:
I am also fairly certain these annoyances will be made up for by additional flexibility these same users never had before.


I suspect you'll find that those users who are annoyed by it simply won't use the additional flexibility. The parser in my old mud went pretty much unused, except when I wanted to create cool-looking logs for usenet posts and mud forums. Even when I told players to type "get the trousers from my backpack and wear them" they would still end up typing "get trousers backpack" (then "get trousers from backpack when the first command didn't work) followed by "wear trousers".

Quote:
If these players come into my game expecting a traditional DIKU style, they are in for more of a shock than a couple of commands not working correctly anyway.


I think it's important to distinguish between gameplay and user interface. You can have a completely different style of game, and many Diku players will still enjoy it, as long as the interface is familiar (or at least compatible).

A good example of this would be the 'give' command, which shasarak also mentioned. In Diku you type 'give sword kavir'. I wanted to support multiple keywords, so my original solution ended up as 'give sword' (after first targetting kavir). This proved extremely annoying, so I later added the options 'give sword kavir', 'give sword to kavir', 'give kavir sword' and 'give to kavir sword'. The result is a command which is more intuitive than Diku, while still being fully compatible with it.
Back to top
View user's profile Send private message Visit poster's website
Author Message
Greggen



Joined: 16 May 2005
Posts: 36

PostPosted: Mon Sep 26, 2005 12:18 pm    Post subject: Reply with quote

As counter-intuitive as this sounds, maybe I should deliberately break compatability with diku, lpmud, etc. ?

Maybe this will actually get players used to the idea that they are not playing a diku and shouldn't expect any diku conventions, forcing them to learn a new game.

<arrogance> If new players leave because of this, maybe I didn't want those kind of players anyway? Smile </arrogance>

Quote:
As silly as it might sound, one of the main reasons I never really got into LPmuds was because - coming from a Diku background - I felt very uncomfortable with the command syntax.


I actually never got into another MUD after my first. Learning new stuff sucks, but it's unavoidable if you want to try something new.
Back to top
View user's profile Send private message Send e-mail Visit poster's website MSN Messenger
Author Message
Drey



Joined: 15 May 2005
Posts: 24
Location: Livonia, MI

PostPosted: Mon Sep 26, 2005 4:21 pm    Post subject: Reply with quote

Greggen wrote:
This is why Bartle suggest using a consistent, if sometimes wrong, behaviour. The users will know what to expect after using parser for a while.


DIKU also uses a consistent, if sometimes wrong, behavior and folks get used to it.
Back to top
View user's profile Send private message Visit poster's website
Author Message
Tyche



Joined: 13 May 2005
Posts: 176
Location: Ohio, USA

PostPosted: Tue Sep 27, 2005 5:33 am    Post subject: Reply with quote

Greggen wrote:
Quote:
How does your parser differentiate between 'get sword backpack' and 'get flaming sword'?


That's one of those tricky ones that's resolved by context. "get sword from backpack" or "get the sword in the backpack" will definitely work.


Try it under Merc, the flaming sword example produces...That's not a container. Tricky or not it's already a case not handled by Mercs .

Greggen wrote:

MUD verbs are only well establised to people who have played MUDs before. More importantly, commands you see in most MUDs will still work with my parser; Their grammar is a subset of mine.


Your good point in bold has been missed. There's no reason you have to limit yourself to just Diku friendly. Mush/MOO friendly and popular LP library friendly and all at the same time is certainly possible. Consider that among Diku derivatives shortest case parsing was criticized at the time. Yet it's quite common now.

There are good points here about providing familiarity. So allowing the user to choose their interface or even map it themselves is feasible in some architectures and maybe desirable. It'd be harder to do it in designs where verbs are created on the whim of builder/coder.

I'm currently working on a parser that will use auto-completion.
Back to top
View user's profile Send private message Visit poster's website
Author Message
KaVir



Joined: 11 May 2005
Posts: 565
Location: Munich

PostPosted: Tue Sep 27, 2005 8:31 am    Post subject: Reply with quote

Greggen wrote:
As counter-intuitive as this sounds, maybe I should deliberately break compatability with diku, lpmud, etc. ?

Maybe this will actually get players used to the idea that they are not playing a diku and shouldn't expect any diku conventions, forcing them to learn a new game.


You're not just forcing them to learn a new game though - every quality mud does that. You're also forcing them to learn a new interface. Actually it's not as bad as I make out, because your parser would likely be very close to what most people are used to, but even slight differences can discourage people from giving your game a fair chance. And if your game is already completely different to Diku, I'm not sure you really need to emphasis the point any further (i.e., there's no advantage in being different simply for the sake of being different).

Tyche wrote:
Try it under Merc, the flaming sword example produces...That's not a container. Tricky or not it's already a case not handled by Mercs.


Right, but what I was responding to was Greggen's comment about compatibility (the "Their grammar is a subset of mine" one you highlighted in bold). Merc doesn't handle the flaming sword example because it doesn't handle multiple keywords - but Greggen's parser does handle multiple keywords, and therefore Merc commands such as 'get' and 'give' wouldn't be subsets of his parser. You're going to end up with some very confused players typing 'get sword backpack' and being told they can't see anything like that (because the parser is looking for something on the ground with both 'sword' and 'backpack' as keywords).

Tyche wrote:
There's no reason you have to limit yourself to just Diku friendly. Mush/MOO friendly and popular LP library friendly and all at the same time is certainly possible.


True - the more the better - although I think you have to be sensible about it. I've tried to keep my commands fairly compatible with Diku because that's the background most of my players come from. It'd probably be worth being more LP-friendly as well, but I doubt anyone from a purely MOO/MUSH background would have any interest in my mud, so I wouldn't bother with compatibility there.
Back to top
View user's profile Send private message Visit poster's website
Display posts from previous:   
Post new topic   Reply to topic    mudlab.org Forum Index -> Design All times are GMT
Goto page 1, 2  Next
Page 1 of 2

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

Powered by phpBB © 2001, 2002 phpBB Group
BBTech Template by © 2003-04 MDesign