Ever woken up one morning to find that one of your arms has gone dead? The feeling has practically gone, you can hardly move it and it just feels like a weight attached to your shoulder. This is what a bad text-based adventure can end up being like if the parser (ie, the part of your game which understands what the player has typed) is no good. The same goes for adventures where everything around you is of no interest and cannot have anything done to it without the writer's express permission. If a player can't control their character due to communication problems or they find are surrounded by boring objects and backdrops, they can't get on with playing the game and having fun, and may just give up and do something else instead.

Basic Commands

OK; so it's not that difficult to make a basic parser. Here's a list of really essential commands which just about every text-based adventure has, along with the abbreviations which can be used:

• North (n), South (s), East (e), West (w) - allow the player to move in this direction if possible. The same goes for the other compass points, which can be shortened to ne, nw, se and sw.

• Up (u), Down (d) - for climbing up and down stairs, trees and so forth.

• In, Out - for entering and leaving buildings and other structures. May be synonymous with a compass direction, in which case you'll have to make the two commands equivalent lest the player think there are two ways out instead of one.

• Look (l) - provides a description of the player's surroundings.

• Examine (x) - provides a specific description of something present in the room or that the player is carrying.

• Get/Take, Drop - allows the player to pick up and drop items.

• Inventory (i) - shows the contents of the player's inventory.

• Wait (z) - waits for a turn without doing anything.

• Again (g) - does the last command again.

However, these and many other commands will usually be built into the programming tools that you will use to make your game, and so it is more a matter of making sure that these commands can be used. Every item and most of the things a player will otherwise be able to see should be available for close examination, and it can be quite dull to be told that everything you look at has nothing interesting about it. Players will often examine something looking to find out whether it is useful or has a specific purpose, so make sure every item comes with the right sort of description.

Some Considerations

The above verbs should be usable even if you don't allow a player to do something. If someone wants to climb a tree but the game won't allow it, a descriptive message about the trunk being too steep and the branches being out of reach will be much more interesting than a simple 'you can't'. The same goes for attempts to pick up a dead frog, pass through a locked door or drop your only piece of clothing in a place where it's freezing cold. In these cases, stick a descriptive piece of text in the part of the code which stops the action from happening, rather than just preventing it.

Needless to say, if you give the player an item of food and a glass of water, they'll want to be able to eat and drink them, respectively. However, you should also try to think outside of the usual, as you can never quite be sure what sort of odd things the player may want to do. While eating flowers, drinking battery acid and breaking open a vial of toxic liquid aren't things people tend to do in real life, they are still possible, and you'll still need to give some response if the player tries to achieve something that simply isn't meant to happen. A good way of doing this is to point out that the character you are playing doesn't think they want to do that sort of thing, or a simple direct message to the player asking them whether they're in their right mind.

Instead, you may actually want to allow the player to do something particularly stupid which may lead to them losing the game. However, in this case, you should make sure they have specifically asked to do that thing, as opposed to letting them drink some acid simply because they typed 'drink' and the acid was the only drinkable item present.

What Happens If I...

It's a good idea to have a list of the main verbs used in text-based adventures and to add an outcome for each combination of verb and item. However, things become a lot more complex when given items which can be used on others, thus generating a vast array of combinations. If you intend to add many items to your game, be prepared to spend a lot of time considering all the possible interactions and, once you've finished, make sure you go back and check that you've added all the necessary actions and outcomes for each item.

Direct and Indirect

One good habit to get into is to define different responses depending on whether the item is being used as a direct or indirect object. A direct object is the item that the player will do something to, and an indirect object is the one that will be used to do it. In other words, the player would use the following syntax:

[verb] [direct object] with [indirect object]

For instance, in 'unscrew screw with screwdriver', screw is the direct object and screwdriver is the indirect object. This works when 'screw' is the direct object, as it can be unscrewed. Were it the other way round, you might want to display a message pointing out that you can't unscrew a screwdriver. However, if you just added a general message saying that you cannot unscrew a screwdriver, it would pop up every time the player used 'unscrew' and 'screwdriver' in the same sentence. The solution to this is to have the warning appear only when the screwdriver is the direct object - the item that the player is trying to unscrew - but not when the screwdriver is the indirect object - the item that is being used to do the unscrewing.

Guess the Verb

One thing that can easily make a game really frustrating is a lack of more than one specific word to perform each task. Finding out that you needed to flip a switch when you've already tried using switch, pull, push and flick can be quite irritating, especially if the game then tells you that you've just 'flicked' the switch. A good way around this problem is to consider every plausible synonym for each verb you use - fortunately, programming tools like TADS¹ come with a built in library of common verbs and their synonyms, so you'll usually only have to be careful if you add extra verbs.

A more important variation of this problem is 'guess the noun', where only a certain word for an item will work. It is a good idea to include all the nouns and adjectives which could describe the item, so that a large red shoebox can also be referred to by the player as a 'red box' or 'large shoebox'. You should make sure the game is able to accept any word which it uses to describe important items, although you shouldn't go as far as including every single noun you use as something that can be individually grabbed and examined.

Modifiers and Multiple Actions

Some modern games even go the extra mile by allowing you to say several things at once, thus saving the player from typing in each command separately. For instance, in some games:

• all allows the player to do the action to everything possible.

• except comes directly after 'all' and allows the player to exclude some items.

• and allows the player to perform another action at the same time.

• then does the same but performs the action after those earlier in the sentence.

• it can be used to refer to the last item referred to in the sentence.

• him/her can be used to refer to the last male/female person referred to in the sentence.

However, unless you intend to write your game from first principles, it will depend on the package you use as to whether your game will support such words. Just keep in mind that these words can be used to perform more than one action at once, thus allowing more effective usage of turns.

Talking to Others

Allowing the player to talk to other characters in the game can make the game's world a lot more immersive, but only if it's done well. The easier way to handle talking is to allow the player to use the command 'talk to' to start talking to another character. This can then either trigger a short segment of text in which an entirely pre-scripted conversation takes place, or can offer the player a limited list of options as to what they want to talk about.

The more complicated version involves the 'ask ... about ...' and 'tell ... about ...' commands, each of which allows you to talk to a certain person about a certain item or subject. This sort of game requires a lot more effort, as each character in the game should be able to respond to enquiries about any of items or other subjects of conversation that the game might prompt the player to come up with.