No Command Line

A big decision when creating a text adventure is whether the player will type commands into the command bar to interact with the world or will use the list of items and the compass rose in the side panes. It is important because it does not just affect how your game looks but also how you create it.

This page is not in anyway saying whether you should or should not disable text input. It very much depends on you and your game. What it is saying is that there are some significant differences between the two.

Text Input

Inputting text via the command bar is the traditional input method for interactive fiction. It offers the most flexibility to the player, creating a great sense (or illusion at least) of freedom. At the same time, this puts extra demands on the creator, as she has to anticipate all reasonable commands. If an object is mentioned in a room description, many players will expect to be able to look at it. You will also need to think of all possible synonyms for objects and verbs, because who knows what the player will try?

No Text Input

I am going to assume a game with all interactions going through the side panes; no text input or hyperlinks (if you want hyperlinks, see here).

If you decide to turn off the command bar, you need to address the limitations of the game panes. There are two parts: the compass rose with a built-in set of commands (going in 12 directions plus LOOK, HELP and WAIT); and the inventories.

Commands without item

The simple way to deal with this is to attach the command to an item. The player cannot do SLEEP, instead he will need to find a bed, and select the "Sleep" verb from that.

It is also possible to modify the side panes, say adding your own custom pane, perhaps called location commands. This could be modified each turn to reflect the current situation. SLEEP is only an option if there is a bed at this location. This is a decidely more complex solution!

Commands with multiple items

How will you handle commands with two items, such as PUT BALL IN SACK and ATTACK ORC WITH FIREBALL? There are solutions, but you really need to think of them up front, as they may have a big effect of the game. For example, you may decide there will be no containers or surfaces in your game. It is a reasonable approach, but may make other things difficult to implement, such as putting a battery in a torch.

You could try implementing commands where the second item is implicit. Perhaps USE BATTERY to put the battery in the torch, or STOW BALL to put the ball in your pack. The player could EQUIP FIREBALL in one step, then ATTACK ORC in the next turn.

No hidden exits

The compass also gives a quick indication of what exits are available; you cannot have them buried in the room description, and require the player to work out she can go that way.

No hidden objects

Similarly, the inventory lists tell the player exactly what objects are available at any moment. A lot of parser games will have points where the player has to read the room description to realise an object is there; until it is taken it is just scenery. That does not work in games with no text input.

The up side is that you do not have to implement every object mentioned in a room description.

No mystery about what an object can do

The player is restricted to just a handful of possible actions for an object at any moment. On the plus side, this again makes game creation easier, but puzzles can be much easier to solve.

What do I have to do with this cartridge? Well, if I look at the verbs, one is "Put in machine", so I will try that.

On the plus side, this is a solution to the "guess the verb" problem.

Coding issues

Displaying verbs

If the player is interacting only through the side panes it is vitally important that every object has the right set of verbs available at the right time. You can do that with the "heldVerbs", "hereVerbs" and wornVerbs" attributes, as described here.

However, for better control, you might want to look at the "verbFunction". This should be a function that takes a list as its only parameter. You can add to this list any extra verbs. The advantage of this technique is that the verbs you add can be determined by the state of the game. It also allows you to remove verbs you do not want.

Let us suppose we have an NPC, and we are tracking his state withthe "state" attribute. At some point, the NPC is injured, and his state become 4. Thereafter it makes no sense to offer a TALK TO verb, so if the state is over three we remove the last entry in the list, using pop. however, the player may want to try first aid, so instead we add an ASSIST verb.

  verbFunction:function(list) {
    if (this.state > 3) list.pop()
    if (this.state === 4) list.push("Assist")
  },

This does offer some scope to hide what an item can do, if you are building a puzzle. It does also offer scope for getting the player in an impossible situation. If an item is not showing a vital verb, the player will be stuck, so test carefully!

Remember that you may want the verbs to depend on whether the item is held or not.

Parsing verbs

It is likely that the commands Quest needs to understand are going to be a bit different. I mentioned SLEEP before; if we do that with the bed item, then the command the parser will see is SLEEP BED. There are likely to be a lot of odd commands like this that you will need to implement. On the plus side, because you know the player will not be able to try SLEEP LAMP or SLEEP DOG, the implementation is easier than normal. In fact, we can put all the new commands in an arrange, and use the array to create almost the same command for every one.

const newCmds = [
  { name:'Press button' },
  { name:'Assign crew' },
  { name:'Contact planet' },
  { name:'Assist' },
]

for (let el of newCmds) {
  commands.unshift(new Cmd(el.name, {
    regex:new RegExp('^' + el.name.toLowerCase() + ' (.+)$'),
    attName:el.name.toLowerCase().replace(/ /g, ''),
    objects:[
      {scope:el.scopeHeld ? parser.isHeld : parser.isHere},
    ],
    default:function(item) {
      msg("{pv:item:'be:true} not something you can do that with.", {item:item});
      return false;
    },
  }))
}

For the item, you just add the relevant button. For the strange machine, give it a "pressbutton" attribute (all lowercase, no spaces). For the computer console, "assigncrew" and "contactplanet", and our NPC needs an "assist" attribute.