There are a number of tricks you can play on your binder to stop it from getting even more bloated than necessary. This column, I’ll be going through some of these, so you can pick and choose from among any that interest you. I’ll also be suggesting some painless ways of helping the players by tinkering with the parser.

Firstly, there’s the problem of what to do with commands like DROP 6 BALLS IN 2 BAGS. Does it mean drop 6 balls in one bag and another 6 in the other bag? Or does it mean drop the same 6 balls, once in each bag? Hmm, well the thing to bear in mind here is that the command as given doesn’t actually make sense, therefore so long as you’re consistent you’re at liberty to do what you like with it! I would bind the 6 BALLS, bind the 2 BAGS, then ignore the second bag and drop all the balls in the first one. Only if in the process of doing that the bag was destroyed would I then go on to the second one.

Destruction of objects by commands can be a problem. Let’s say that as a prank you took a branch, set fire to it, and typed BURN EVERYONE WITH BRANCH. OK, so the branch burns the first person in the room, then the second, then the third – oh, oh, the third person is carrying gunpowder! Boom! Everyone in the room is killed! So when the dust settles and the command to burn the fourth person in the room is executed, the fourth person is no longer there... The only solution to this is to check before you invoke each command that the objects to which it refers are still around. Well, that or don’t ever destroy or move objects collaterally...

English has many compound nouns, which are nouns made up of other nouns. Examples: EMPEROR PENGUIN; POTATO CHIPS; BIRTHDAY CARD; DINNER PARTY; DEPUTY ASSISTANT CHIEF CONSTABLE. Treat the leading nouns as adjectives (or both adjectives and nouns). The adjectives don’t necessarily have to do anything, so long as they parse. The same applies for compound verbs such as PICK UP and PUT DOWN: treat the auxiliary parts as adverbs and then fold them into the verb later when doing the binding ({ pick up }: get).

Similarly, occasionally you get adjectives that can be used as nouns, eg. THE YOUNG. Don’t bother agonizing over whether it’s an adjective or a noun – make it both! In general, if a word seems to be acting like a part of speech that officially it isn’t, be practical about it. I wouldn’t claim that the word MARKED is a preposition, but if by making it be one I can get my parser to work on GET ENVELOPE MARKED “personal” then I’m quite happy to do so. On the other hand, I wouldn’t recommend changing prepositions into nouns: GO IN should use IN as an adverb, not as a noun (well, not unless you want to drive yourself nuts fixing the weird parses that arise from allowing this).

You can help players a lot by abbreviating commands. I don’t mean G for GET, I mean DT for DROP TREASURE and DXT for DROP ALL EXCEPT TREASURE, things like that.

Players often want to repeat commands. Although you can hack your grammar to allow stuff like GO WEST 3 TIMES, try using non-standard punctuation. In MUD2, I make each full stop (period) mean “repeat this many times”. Thus W. means “go west once”, but W... means “go west 3 times”. I regularly see command sequences such as W.......N......E.....N.D..... that string together lots of individual commands into one long input line.

Commands don’t have to be words. :-) can be a synonym of SMILE.

Don’t worry about ambiguity at this stage – it’s too late. Make your choice and be consistent. Trying now to make GET BALL ON TABLE pick up a ball that’s on a table and DROP BALL ON TABLE drop a ball that you’re holding onto the table is pointless. You already decided when you wrote your grammar where the invisible brackets went.

Put in synonyms for commands that are used often, so it only takes a few keystrokes to enter them. Don’t insist on the shift button for quotation marks. Words that can be implied, such as THE, can be omitted.

When an input line contains an error, give the player as much information as possible about it. I mentioned a few columns ago that you should log it for your own benefit, but listing a broken line isn’t the same as telling people what’s broken with it. For unknown words, tell the player that the word is unknown; for unparsed sentences, tell the player how far you got, what you were expecting to get, and what you did get (for every word in the sentence). Here’s an example from MUD2. You can do better:

*drop the biggest 3 diamonds into the bag then
I made sense of some of that:
        drop[verb]   the[definite article]   biggest[superlative]   
        3[integer]   diamonds[noun]   into[preposition]
        the[definite article]   bag[noun]   then[sentence conjunction]   
end-of-line[uh?]
I was expecting the end-of-line to be a verb.

Note that if you’re not careful you can give away more information in your error messages than you want players to know. Don’t tell them too much!

Well, believe it or not, that just about wraps up parsing..! I’ll finish it off next article with a complete example, then I’ll go on to something else.

I heard that collective sigh of relief, you know...