Perhaps a pain, but you could also build a plural field into the mob, so wolf->name would be "wolf" and wolf->plural would be "wolves." Yes, that's not a good code solution, but hey. :P

Something like a plural-named property isn't a bad idea. It's common in the major interactive fiction languages, like Inform for example.

The reason I mentioned word stemming is that you could get away with not explicitly representing the plurals. There are also pluralization libraries that, given a word, will give you its plural. You could use these to get things right in the vast majority of cases, and perhaps allow manual overrides when the NLP library messes up. I would not recommend making builders manually enter plurals for everything.

I found this thread from the old MUDDEV mailing list on text parsing from 1999:

http://muddev.wishes.net/viewtopic.php?f...

I was hoping for some theory but it's mostly people stating their preferences and then devolved into genitalia waving over server hardware. Two points I walked away with where:

• Don't confuse new players.


• Minimize the amount of typing required by veterans.

Which has me thinking again that matching should be simple and greedy (in the regular expressions sense).

I liked this sample newbie experience posted by Raph Koster:

You could deal with the above scenario using the SMAUG approach of setting the default prompt to something like "type 'help newbie'" (reverted as soon as they've typed it), and replacing the "Huh?" with an actually useful suggestion.

In regard to command parsing, offering some flexibility is nice, but IMO the most important thing is to use a syntax that's simple to use, easy to understand, and consistent with your other commands. If you're targeting your game at an audience from an established codebase, you should also strongly consider a backward compatible syntax (or at the very least, avoid trying to force something completely unfamiliar on your target audience).

I wrote a simple pluralizing function that assumes the input is singular. Rather than try to handle every irregular noun in English I'm just going to add them to the dictionary as the need arises.

def plural(noun):

    """Roughly apply the rules of pluralization."""

    vowels = 'aeiou'

    irregular = {
        'child':'children',
        'foot':'feet',
        'man':'men',
        'mouse':'mice',
        'ox':'oxen',
        'person':'people',
        'tooth':'teeth',
        'woman':'women',
        }

    nl = noun.lower()

    ## is it too short to juggle?
    if len(nl) < 2:
        return noun + 's'

    ## Check for an irregular noun
    if nl in irregular:
        return irregular[nl]

    suffix = 's'
    if nl[-2:] in ('ss', 'sh', 'ch') or  nl[-1:] in ('x','z'):
        suffix = 'es'
    elif nl.endswith('y'):
        if nl[-2] not in vowels:
            noun = noun[:-1]
            suffix = 'ies'
    elif nl.endswith('f'):
        noun = noun[:-1]
        suffix = 'ves'
    elif nl.endswith('o'):
        if nl[-2] not in vowels:
            suffix = 'es'
    return noun + suffix

Then I changed my Trie to take each word added, pluralize it, and add it again. So 'take swords' will work as long as there is at least one 'sword'. Also, if builders add singular keywords like 'weapon' to appropriate items, users will be able to type 'take weapons'. I decided against trying to identify plurals, especially with partial matching. I'm hoping that greedy, expressive matching will be the most helpful:

> take all
> drop rusty weapons
> take all but broken
> take a spear

There are lots of pluralization libraries out there that are fairly good at handling special cases; you probably don't need to be doing that work yourself. That said, I suppose your universe of words is relatively small and controlled, so it's not too bad to maintain it.

penes, lol

I'm really trying to minimize dependencies and, since I'm mostly coding for fun, I didn't mind writing it myself. I did a test run with a 1,000 common nouns and the output was fairly reasonable. I do get stuff like "pantses" but since that's hidden away in the Trie the only effect is users actually can:

> take gloveses and pantses

Which I can fix via the irregular noun dictionary.

Or you can fix it by saying that your MUD was written by Gollum. :tongue:

ok, I laughed – hadn't tried saying it outloud.

At some point you will need to accept that no code is going to be able to guess right all the time, and if something like "get glass" ends up being treated as plural because you forgot to add glass to your auto-plural-detection code, the player is going to be irritated when it picks up all glass items.

I highly recommend against being clever. Clever is not correct, and it's far more user friendly to always understand exactly what the user meant (even if it requires the user to be a little more expressive in his intent) than guessing wrong occasionally and surprising the user with unintended behavior.

If the player wants all items, he should be required to type in "get all things." Veterans who like shorthand are probably going to want an mget command or something of that nature, so you don't really need to worry about the 'all' keyword being too much of a bother.

For what it's worth, I would agree with elanthis. Cleverness is cute, but you need to be really clever for that very cleverness to not get in the way.

Think of it as the uncanny valley problem. If the syntax does not purport to be clever, people drop expectations and learn to type in a fairly rigid structure. If the syntax does purport to be clever and actually understands everything, then people's expectations are satisfied. But if the syntax purports to be clever but makes enough mistakes, people will learn to expect cleverness and then get utterly frustrated when it makes unexpected mistakes – the little details it gets wrong will throw them off. And when this translates to not being able to issue certain commands, it can cause serious issues especially in a player's early time on the game.

This is coming from somebody who's spent a fair bit of time on parsing sentences and so forth; I think it's cute and a lot of fun to program, but I'm not sure I want to put this into the game. I'm thinking I might use some kind of simple syntax for simple commands, augmented with something fancier (almost like a small programming language) for issuing complex commands.

Anyhow, this might sound like rain on your parade and if so I apologize, as that is not my intention. I would be very happy actually to see these problems solved in a way that ends up working when released into the wild of player abuse.

I had already decided against trying to guess plurals – both because it's nearly impossible to parse from raw input and because the code supports partial string matching which compounds the problem.



Currently, I'm planning to do exactly that; 'take glass' will grab every glass item in the room. It wont be arbitrary though. The game will always match as many items as possible unless the player specifically says 'an arrow' or '1 gold' or 'the jade monkey'. The task is not so much to parse English as it is to write an interface. Once a player gets used to aggressive matching, I think it could play well.

I'm not married to the idea. If it bombs I'll redo it. This thread has been a real help in thinking through the issues.

If the room contained a wineglass and a glass dagger then, as a player, I would be extremely surprised if typing "get glass" resulted in my taking both items.

You'll hit similar problems with other materials. "Get iron" might mean "pick up the flat-iron from the fireplace", "get steel" might mean "get the thing that you strike against the flint to light a fire", and so forth; those are comparatively rare, but with "glass" I would expect that to happen a lot; a lot of people drink out of glasses.