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 the nature of the game you create.

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. If you are considering it, here are some things to think about.

Game play considerations

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 items

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 decidedly more complex solution! See here for more on how to do that.

Adding a tool bar is also a good approach, and can be done easily, as described here.

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. However, you can have exits hidden until something happens.

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

Turning off the text input

This is readily done by setting settings.textInput to false. However, there are some debugging commands you might still want to use, so you might actually want to keep the text input during the development. I therefore recommend setting it to be true when "playMode" is "dev" and not otherwise.

settings.textInput = settings.playMode === 'dev'

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 with the "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 3 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 array, and use the array to create almost the same command for every one.

Here is an example array; you should modify it to suit your game. Note that the fourth entry is for a verb that will be used when an item is held - the default is for items in the location.

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

This is the code that creates the commands; you can copy-and-paste it straight into your game. It has to be after the array; I suggest both go in the code.js file.

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},
    ],
    defmsg:"{pv:item:'be:true} not something you can do that with.",
  }))
}

For the item, you just add the relevant attribute. For the strange machine, give it a "pressbutton" attribute (all lowercase, no spaces). For the computer console, "assigncrew" and "contactplanet", and the crew manifest a "countersign" attribute.

Scenery items

Sometimes items the player can interact with are mentioned in the room description, and it looks clumsy to then list them. With text input this would be a scenery item, and would not appear in the side pane, but if there is no text input that would prevent the player interacting with it. We need to prevent the item appearing in the room description, but still appear in the side pane list.

This can be done with a simple setting:

settings.showSceneryInSidePanes = true

Conversations

There are various options for handling chatting to NPCs, some work better with no text input than others. You might want to look here and here.

I like to do this for dynamic conversations, as it puts the options by the side pane, where all other interactions are.

settings.funcForDynamicConv = 'showMenuDiag'

Meta-commands

How will the user indicate she wishes to save or load the game? Or toggle dark mode?

A relatively simple approach is to add a tool bar. The code below will give you the score on the left, the game title and room in the middle, and a set of buttons on the right.

settings.toolbar = [
  {content:function() { return 'Score: ' + player.achievements.length + '/50' }},
  {content:function() { return settings.title + ': <i>' + currentLocation.headingAlias +'</i>'}},
  {
    buttons:[
      { title: "Undo", icon: "fa-backward", cmd: "undo" },
      { title: "About", icon: "fa-info", cmd: "about" },
      { title: "Dark mode", icon: "fa-moon", cmd: "dark" },
      { title: "Save", icon: "fa-save", cmd: "save game ow" },
      { title: "Load", icon: "fa-download", cmd: "load game" },
    ],
  }
]

This assumes a score attribute on the player, by the way.

Each button has a title - the tooltip the user will see if she hovers over it - an icon and a command.

Note that SAVE/LOAD gives the save game a name "game", so only one save is stored at a time. This is a bit limited for the user, but much easier for us! However, it is worth warning the player in the HELP that saving the game will overwrite the old save.

Add this line at the end, and an extra button will appear allowing the user to toggle the text input in "dev" and "beta" mode. This can be useful to allow testers to add comments to the transcript, for example.

if (settings.playMode !== "play") settings.toolbar[2].buttons.unshift({ title: "Toggle text input", icon: "fa-pen", cmd: "text" })

Indicating new text

You may want to turn off echoing the command to the screen. One reason for that is that it may not be great English because of the way commands have to go though the side pane.

settings.cmdEcho = false

This raises a new issue (or arguably an issue for any game becomes more significant) - how does the player know what is new text? If a command just prints one paragraph, it will be obvious, but if there a a paragraph describing leaving one room, then the title of the new room, plus the text for that, it may not be clear. This can be done with CSS, as Quest will ad the "old-text" class to the old text.

See here for more.