The copyright situation for this article is unclear. It does not belong to the author of this site. Please see the copyright notice. If you have information about the copyright contact me!

The Command Line Interface

by George Reese

The perfect virtual reality would be something like Star Trek's holodecks. It would provide us with a perfect representation of the virtual reality using all of our senses and translate our very thoughts into action. No virtual reality environment comes close to this on any level--the technology just isn't there. A good mud can at best provide limited visual and auditory representations to a player. Furthermore, translating player thought into action must take place through the tools of modern computer user interfaces--the keyboard and the mouse.

The ability to use the full-range of modern computer input devices is a relatively new concept for muds. In fact, most muds are still using the same mode of user input they used 1977: the command line. I would like to re-examine the command line and explore its most effective use in today's mud games.

Columbia River gorge, trying jumping across this river.

The command line is for translating player thought into game action. It is not itself part of the game. Consider a mud where a player encounters a river. There is no bridge before the player. The player considers possible actions and decides to jump across the river. The coder of this room, however, envisioned players jumping into the river. If you jump into the river, you get sucked down into a vortex that takes you to another realm. How does the player use the command line to let the game know about the desire to "jump across the river"?

A good command line interface will respond to the player's attempt at action in a way appropriate to the situation in question. For any desired action, a game should respond to a command line representing that action in one of the following ways:

Notifying the player that action is not supported on this mud (e.g. the player tries to "vifit").
Notifying the player that the action does not make sense in the current context (e.g. the player attempts to throw a spaceship).
Notifying the player that the command line is vague about the intended action it is supposed to represent (e.g. the player attempts to "attack the goblin" when there are two goblins in the room).
Notifying the player that the action makes sense in this context, but not in the sense the player intended (e.g. jump across the river versus jump into the river).
Carrying out the action. Carrying out the action may have unintended consequences (e.g. the player jumps across the river but does not make it and thus ends up jumping into the river).

In the case of the player wanting to jump across the river, the act of jumping is clearly supported. It makes sense in the context of the room and is totally unambiguous. The only question is whether you want to handle the the jumping across the river as being a wrong use of jumping or as something that leads to jumping into the river. Either would be a valid way to handle the command, but I would argue that the better way is to accept the jumping across the river and have the player land in the river.

Translating the player command into action involves four key components:

Rules: The rules define the valid syntaxes for the command in question.
Parser: The parser matches a command line against the rules for that command and then matches the tokens to the player's environment.
Synonyms: Synonyms are commands that should respond as if the command in question where being used.
Command handler: The command handler is the code that performs the action for the command.
Error messaging: Error messaging is printing out useful information to the user depending on what is preventing the player's intended action from being carried out.

The last component is key. When a player types in a command, that command always represents an intended action, even if it is a typo. Either that action should be carried out or the player should be told exactly why the action was not carried out. In cases where the mud has no idea what the player means, the mud should point the player to documentation. In other words, "What?" is absolutely never an appropriate response of a mud to a player command.

One issue that many people have a hard time coming to terms with is the fact that command rules, parsing, and aliasing should be global and handling and error messaging should be both global and local. By global, I mean that every command on a mud should be processed for a player no matter where they are on the mud. If I can throw a rock, I should be able to try to throw a bridge.

The common objects to this problem are:

Globalized commands stifle creativity.
Globalized commands place an undue burden on the administration staff.

These objections are really failures to understand the problem. The sort of creativity people are arguing for in commands is not the sort of creativity you want on a mud. You do not want coders willy-nilly making up new commands. When you do that, you create syntax games and confusion for your players. Syntax games occur when the same command (or synonyms for the same command) to do the same thing has different syntaxes in different parts of the mud. For example, one rock from one coder should be thrown using "throw rock" and another rock should be thrown using "toss rock".

Confusion also results from the fact that it is nearly impossible for locally defined commands to be documented globally. If one coder on the mud has determined that the command to use the special power of a sword is "finesse sword", a player is left to play games just to get the mud to take an action he knows damn well that he wants to take. Remember, the challenge of the sword is to learn that it has special powers, not to read the mind of the coder and figure out how we would express the action of using the sword's special powers.

Just because a creator cannot dream up new commands on the fly does not mean they are prevented from coming up with new actions. It just means a mud needs a process for a creator to communicate a newly conceived action and have the mud administration staff turn it into a globally available action.

The final objection is another red herring. The work of the administrators is to specify the rules for commands and provide simple, default handlers for those commands. The actual work of providing meaning to those commands is still up to individual coders.

The advantages of a globalized command parsing scheme so vastly outweigh the perceived, yet illusory advantages of localized command parsing as to make one wonder why localized command parsing still exists today. Perhaps it is because the move represents a minor paradigm shift, but, in the end, the question comes down to: "What makes a better player experience?"

George Reese is the author of the ever popular nightmare mudlib, he has been running the LP mud FAQ since it's inception and also hosts this magazine on his web site. Thanks for everything you have done George.