Advanced MUD Concepts

Features of a MUD command parser.

One of the weakest parts of the vast majority of text MUDs I've found has been the parse. They often follow a very rigid syntax focused too much on syntax than actually figuring out what you mean. The simple command 'get the sword' fails on a huge number of MUDs because of 'the'. If you want to get a yellow sword from a blue box you usually end up having to type something like 'get 'yellow sword' 'blue box''

Personally, I've wanted MUD parsers to be more English like - 'get the first and second yellow swords from the weapon rack' should work properly. I've also thought that it would be cool to be able to have adverbs in sentences, so something like 'quickly get the sword' would modify get appropriately. Although I imagine it would be mostly emotive, there could definitely be some interesting game mechanics based around it. I've also wanted to see better error messages. Most muds give you 'Huh?' or its equivalent. 'get the sowrd' will probably say 'You can't find that here.' Why not 'There's no sowrd here - did you mean 'sword''? Finally, I think that there's no reason that a MUD shouldn't support having multiple verbs in a sentence - 'quickly stand and get the sword from the table'.

Although a lot of these can be done in most muds using other syntax, I think people are forgetting that the parser is the player's interface with the world, so the more expressive it is the more freedom it gives the player. With the two verbs in a sentence example - in most muds, you'd have to do 'stand' 'get sword table' which would appear to the world as 'Drealoth stands up.' 'Drealoth gets the sword from the table.' instead of 'Drealoth quickly jumps to his feet and grabs the sword from the table.'

Anyway, just some thoughts. What would you like to see in a MUD's command parser?

One of the weakest parts of the vast majority of text MUDs I've found has been the parse. They often follow a very rigid syntax focused too much on syntax than actually figuring out what you mean.

Perhaps it's the programmer part of me, but to be honest I actually prefer a fairly rigid syntax. I know natural language parsers are supposed to be "fashionable and cool", but the question is, do they really add anything to the game?

Let's look at some of the advantage of a rigid (but well-designed) command syntax:

1. Quick to type: It's much faster to type "get 2.sword" than "get the second sword". This becomes particularly important in combat situations where even a single second can make a difference. It can also save the player a lot of unnecessary typing over the many hundreds of hours they put into the mud.

2. Consistent: Once you understand the syntax for one command, you'll be able to apply the same syntax rules to other commands.

3. Reliable: Because the syntax is rigid, you won't have to worry about it trying to second-guess you or misinterpretting what you're trying to do.

4. Easy to learn: Learn the commands, learn the simple syntax rules, and that's it. You don't have to worry about learning how the various quirks of a natural language parser apply to each command, because there won't be any.

5. Easy to implement: Much easier to implement, particularly for a game which is always evolving and changing.

Even if you could create a 'perfect' natural language parser, which didn't make mistakes or misunderstand command requests, you'd most likely still find that hardly anyone used it. Perhaps the occasional newbie trying their first mud would use it, but they'd soon wittle it down to the shortest form possible. It'd be a huge amount of work for something which most people wouldn't use, just for the sake of having something 'cool' on your feature list. Plus there's the fact that no natural language parser is 'perfect'.

However that doesn't mean that the command syntax can't be made a bit more flexible. For example, my 'give' command supports the following:

This is obviously fully compatible with the standard Diku syntax, but it also supports the other typical variations that newbies tend to try, without the implementation effort required for a natural language parser.

Feedback such as "There's no sowrd here - did you mean 'sword'?" is of dubious value in my opinion. In that example it's fairly obvious what the player meant, and there's no real need to tell them about it, while other cases (eg "There's no artwork here - did you mean 'armour'?") are just going to sound odd. It's also likely to start requiring a lot of extra processing, and could end up giving some really strange messages once you start taking player names into account.

The combined verbs idea is nice though, and could certainly add some flavour to the game, particularly for roleplaying muds.

I'm with Khavir on this one, and he makes a great point about being flexable. Besides the painful amount of time and energy to make a parser like that, as Khavir pointed out, most people will break down to the fastest way of typing.

IMO a mud parser should at a minimum support object/indirect object switching, a few ways of handling multiples, and multiple verbs.

At a certain point though you cross the line between the command parser and the world model (let's conveniently forget for a second that the two are never fully separate). What I mean is by saying a parser should support 'put the sword on the table', do you mean the table is a simjple container, or your mud supports object stacking?

If you log in to MUD and MUD II or 2 (mudII.co.uk 23; mud2.com 23) and check their help you'll find some interesting information on their verb parser.

One thing I've wondered is if a mud could use the work that 's been done on interactive fiction (IF) compiler/interpreters, two of the main languages being TADS and Inform, as 'the parser' is dear to the heart of many people who write and play IF:

At a certain point though you cross the line between the command parser and the world model (let's conveniently forget for a second that the two are never fully separate). What I mean is by saying a parser should support 'put the sword on the table', do you mean the table is a simjple container, or your mud supports object stacking?

At this point my mud doesn't exist, but if (and maybe when) it did, it would be on the table. Looking at the table would give 'There's a table here with a sword lying on it.' If you kicked the table, it would fall off - if it was made of glass, it might break when it fell.

Right now I've been mostly doing the parser for fun, to see how far I can take it so that it still understands my commands. One feature it has right now is that adjectives on a noun are attached as a list to it, so 'get yellow shining sword' 'get shining yellow sword' 'get yellow sword' and 'get shining sword' all will (probably) target the same object.

Also, to reply to KaViR's point that it's faster to type - I was thinking of this system as a compliment to a shorter condensed system, not a replacement. If a person knows the condensed syntax, they'll obviously use that. If a player wants to get the second sword, all they have to do is type 'get the second sword.' The game might even reply with 'HINT: This command is the same as 'g 2.sword'.' I think that having a more english like syntax available would help make it so the player doesn't have to be constantly looking up help files for commands.

The other thing that will be implemented will be the ability to specify a number of objects to perform the verb on. 'get three apples from basket'

Here's some buggy code in Ruby that I threw together yesterday. Doesn't work properly yet, but I'm getting there.

[code] # An object within the game. Takes a name and any number of adjectives
class Game_Object
attr_accessor ;adjectives #A list of adjectives associated with the object
attr_accessor ;name #A single word describing the object

def initialize(name,adjectives)
@name=name
@adjectives=adjectives #adjectives can be any number of single words.
end
end

private
def is_adjective?(word)
@nouns.each do |noun|
return true if noun.adjectives and noun.adjectives.include?(word)
end
return false
end

private
def is_ignore?(word)
return @ignore.include?(word)
end

private
def is_list?(word)
return word=='and'
end

private
def is_type?(type,word)
case type
when ;verb then return is_verb?(word)
when ;adjective then return is_adjective?(word)
when ;noun then return is_noun?(word)
when ;preposition then return is_preposition?(word)
when ;counter then return is_counter?(word)
when ;adverb then return is_adverb?(word)
when ;list then return is_list?(word)
when ;ignore then return is_ignore?(word)
end
end

#Yes, this shouldn't be here, but it makes life easier.
public
def look
puts "You see;"
@nouns.each do |noun|
line="A "
if noun.adjectives
noun.adjectives.each do |adj|
line += adj + " "
end
end
puts line + noun.name + "."
end
end

#These ones are syntactically correct, but should return errors for reasons
#such as an object not existing
puts "The following should fail due to circumstance;"
puts parser.parse('get axe') #no axe in the room
puts parser.parse('get the second shining axe') #Again, no axe in the room
puts parser.parse('get the second shining axe from the chest')
puts parser.parse('get the sword from the strange box') #No strange box.
puts parser.parse('get second long sword') #only one long sword
puts parser.parse('sit on couch')
puts parser.parse('sit on the couch')

puts

puts "The following should succeed;"
puts parser.parse('sit')
puts parser.parse('get sword')
puts parser.parse('get shining sword')
puts parser.parse('get the sword')
puts parser.parse('get the shining sword')
puts parser.parse('get the second shining sword')
puts parser.parse('get sword from chest')
puts parser.parse('get the sword from the chest')
puts parser.parse('get the shining sword from the chest')
puts parser.parse('get the second shining sword from the iron chest')
puts parser.parse('sit on chair')
puts parser.parse('sit on the chair')
puts parser.parse('sit on the wooden chair')
puts parser.parse('sit on the metal chair')
puts parser.parse('sit on the second chair')
puts parser.parse('sit on the second wooden chair')
puts parser.parse('sit on the second sturdy wooden chair')
puts parser.parse('put the second sword on the second wooden chair')

One of the weakest parts of the vast majority of text MUDs I've found has been the parse. They often follow a very rigid syntax focused too much on syntax than actually figuring out what you mean. The simple command 'get the sword' fails on a huge number of MUDs because of 'the'. If you want to get a yellow sword from a blue box you usually end up having to type something like 'get 'yellow sword' 'blue box''

Personally, I've wanted MUD parsers to be more English like - 'get the first and second yellow swords from the weapon rack' should work properly. I've also thought that it would be cool to be able to have adverbs in sentences, so something like 'quickly get the sword' would modify get appropriately. Although I imagine it would be mostly emotive, there could definitely be some interesting game mechanics based around it. I've also wanted to see better error messages. Most muds give you 'Huh?' or its equivalent. 'get the sowrd' will probably say 'You can't find that here.' Why not 'There's no sowrd here - did you mean 'sword''? Finally, I think that there's no reason that a MUD shouldn't support having multiple verbs in a sentence - 'quickly stand and get the sword from the table'.

Although a lot of these can be done in most muds using other syntax, I think people are forgetting that the parser is the player's interface with the world, so the more expressive it is the more freedom it gives the player. With the two verbs in a sentence example - in most muds, you'd have to do 'stand' 'get sword table' which would appear to the world as 'Drealoth stands up.' 'Drealoth gets the sword from the table.' instead of 'Drealoth quickly jumps to his feet and grabs the sword from the table.'

Anyway, just some thoughts. What would you like to see in a MUD's command parser?

This is technical and really doesn't have an impact on the players' "expressive" freedom. They're commands, not expressions.

I'm curious. Would you require them to type "Check my character's skill level?" or "Log out of the game." with proper punctuation while you're at it? I think you see the senselessness of that.

This is pretty interesting. In my experience, if your commands are closer to the general language it'll be much easier for players to get into the game. You'll be eliminating a somewhat significant first hurdle. Having to read through HELP BASIC_COMMANDS when they're two pages long on a new MUD is something very un-fun to have to do and if you could just go ahead and type "get the sword from the backpack" it'd make things a lot easier on new players. There's no reason to not include some sort of condensed syntax in there as well for advanced players, of course.

Furthermore, you could make things easier by giving hints if a player enters a wrong command, ala Google's "Did you mean 'get the bardiche from the weapon rack'?"

Having multiple ways to tell the MUD something is a plus for players as well, since they can stick to whatever syntax works for them. I've found I much prefer inputting commands that make some general sense and I'll always prefer that to typing ID numbers (which mind you are still incredibly useful).

We lean towards supporting natural english command syntax at AL, though we do support short syntax as well so long as it isn't ambiguous. We have a simple NLP system with verbs where each command must have language option functions put in manually if they make sense, and the parser takes care of the generic work. Basically, we try to take a lot of the irritating guesswork out of learning new command syntax.

Here are some examples -- note that objects have a position in the room, so some syntax involves position:

One of the weakest parts of the vast majority of text MUDs I've found has been the parse. They often follow a very rigid syntax focused too much on syntax than actually figuring out what you mean. The simple command 'get the sword' fails on a huge number of MUDs because of 'the'. If you want to get a yellow sword from a blue box you usually end up having to type something like 'get 'yellow sword' 'blue box''

Personally, I've wanted MUD parsers to be more English like - 'get the first and second yellow swords from the weapon rack' should work properly. I've also thought that it would be cool to be able to have adverbs in sentences, so something like 'quickly get the sword' would modify get appropriately. Although I imagine it would be mostly emotive, there could definitely be some interesting game mechanics based around it. I've also wanted to see better error messages. Most muds give you 'Huh?' or its equivalent. 'get the sowrd' will probably say 'You can't find that here.' Why not 'There's no sowrd here - did you mean 'sword''? Finally, I think that there's no reason that a MUD shouldn't support having multiple verbs in a sentence - 'quickly stand and get the sword from the table'.

Although a lot of these can be done in most muds using other syntax, I think people are forgetting that the parser is the player's interface with the world, so the more expressive it is the more freedom it gives the player. With the two verbs in a sentence example - in most muds, you'd have to do 'stand' 'get sword table' which would appear to the world as 'Drealoth stands up.' 'Drealoth gets the sword from the table.' instead of 'Drealoth quickly jumps to his feet and grabs the sword from the table.'

Anyway, just some thoughts. What would you like to see in a MUD's command parser?

This is technical and really doesn't have an impact on the players' "expressive" freedom. They're commands, not expressions.

I'm curious. Would you require them to type "Check my character's skill level?" or "Log out of the game." with proper punctuation while you're at it? I think you see the senselessness of that.

Take care,

Jason

I think you're missing the point here. The idea is to make it verbose enough that the player doesn't have to worry about getting bogged down in the syntax and can accomplish their goals without having to refer to help files.

Suppose that there are three leather bags. In bag number two, there are two cool swords, the second of which you want to get.

In most muds you end up typing something like get 2.'cool sword' 3.'leather bag'. However, suppose a player doesn't know this - it's not exactly the most intuitive expression out there. They try get second cool sword from third leather bag. That fails on a lot of muds, and I don't think it should. The interface should be intuitive. That doesn't mean that get 2.'cool sword' 3.'leather bag' won't work either - in fact, as I said in an implimentation I would probably pass a hint saying that "You can condense this command to <blah>." My philosphy is verbosity as an option for the player, not a necessity. Or suppose you want to get all of the cool swords from the bag, but you don't want to get the uncool swords or the "sorta cool sword" - is that even possible on most muds in a single command?

In addition, verbosity can allow for more complex commands, giving the player even more freedom to interact with the world in the way that they see fit. I don't know of any mud parsers that would let you specify multiple verbs within a command, or that let you get more than one of a different type of object.

I absolutely love having the option of versatility in a parser, mostly for the simple reason that the mudworld can get very complicated, and you need to be increasingly specific commands to deal with it!

For example, our mud supports subdescriptions on objects, so if you 'examine hat' and find that theres an inscription on the hat, you can
...
'examine inscription on hat'
'examine inscription on floor'
'examine second inscription on walls'
'examine my hat'
...
this is really useful when youve got twelve different inscriptions on the walls, more hats laying on the floor, that inscription-covered shield you also picked up etc.... trying to differentiate between all the different types otherwise could drive me up a wall!

The only issue I have, is that unfortunately I am afflicted with typoitis, which means that no matter what i type, without proofreading, 4/10 characters are wrong... trying to bang off complicated commands like "draw zigzags in red sand on the ground" while trying to cast a spell in combat generally requires aliasing

Something that I personally would LOVE to see in a mud (or maybe a mudclient even) would be a version of the 'autocorrect' or spellcheck function of wordprocessors

I would argue against NLP on the principle of least supprise.
English has ambiguities, and NLP has a tendency to just choose one of those ambiguous overloads for you. The end result, you type in some command which you think is going to do one harmless thing, and could end up doing something dangerous, which gets you or others killed.
Having extended syntaxes for commands to explicitly handle all the different variants your mud needs, potentially with several variants for performing the same task is well and good. But full NLP is a dangerous ground.

Our command parser actually allows "get the sword in my pouch" as well as "get sword pouch" as well as "ge sw pou"(or any abbreviation of that). It's good to see we're going somewhere not all MUDs have gone. We also ahve an accoutn system, though I see that is not something everyone agrees on.