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
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
The rules define the valid syntaxes for the command in
The parser matches a command line against the rules for that
command and then matches the tokens to the player's environment.
Synonyms are commands that should respond as if the command in
question where being used.
The command handler is the code that performs the action for
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
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
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?"
August 1999 Imaginary Realities, the magazine of your mind.
© Copyright Information