Playing interactive fiction teaches you to think about other games, and other
programs and user interfaces, in terms of syntax.
         

An interface composed entirely of buttons, like this website, provides only
verbs. Many video games are the same way. Verbs are direct: Jump, Go East, Save.
Others allow certain verbs to take a single noun: Shoot Headcrab, Get Lamp.

Very, very few games make proper use of adjectives, adverbs, and prepositions.


Adverbs are, on the surface, easy: Shoot With Railgun versus Shoot With Pistol.
But this misses the point. The real power of adjectives and adverbs is
polymorphism, the technique by which the combinatorial explosion becomes a tool
instead of an obstacle.

The problem with Shoot With Railgun is that the adverb With Railgun will usually
only apply to one verb: Shoot. It is conceivable that it would also affect Bash,
but most games would not modify the behavior of Bash on the basis of which
weapon was equipped, if the verb was implemented at all. More fundamentally, the
adverb is naturally limited to a relatively small problem domain. There are only
so many things you can do with a railgun.

(I am considering With Railgun an adverb rather than Railgun a noun on the
assumption that the game treats the railgun as an instrument or mode rather than
an object to be manipulated in its own right. If, for example, the railgun could
be disassembled, or dropped into a bucket to serve as a counterweight in a
physics puzzle, or shot at with another gun to create an explosion, then I would
treat it as a noun.)

By contrast, now, imagine a game with a Hastily adverb. Applied to the Move
verb, it makes the difference between walking quietly and running noisily;
applied to the Shoot verb, it increases firing rate but decreases accuracy;
applied to the Take verb, it reduces attack of opportunity but introduces a
chance of dropping or perhaps breaking the noun that the player is trying to
take.

Imagine further that there are several such adverbs, and that they can be used
in any combination, their effects stacking. Perhaps the vocabulary might include
Recklessly, Magically, Stealthily, and Charismatically.

From a code perspective, combining these effects could be made relatively
trivial. Each adverb would have a well-defined effect, and the net effect of
several adverbs would be created by applying the individual effects
sequentially.

But from the player's perspective, this would add far more tactical complexity,
and hopefully depth, to the game. Each combination of adverbs, with each verb,
would have unique tactical utility and significance.

Furthermore, the combined effects would be predictable once the individual
adverbs were learned. This means that mastering the system would consist not of
memorizing vast tables of special cases and combinations, but rather of
reasoning heuristically about the known rules of the system. "I need to
accomplish such-and-such," the player would say, "and I have these tools. How
can I get there from here?"

The deeper the syntax is, the more advanced and complex reasoning the player can
undertake.

The deepest syntax is recursive, and for this we need prepositions. Unlike
adverbs, which at best can be merely applied to various verbs and stacked with
other adverbs, prepositions and conjunctions can chain together whole predicates
into vast, complex notions.


I don't know of any game that uses syntax that deep. But I have seen the
difference in non-gaming user interface design.

A window-and-icon desktop offers virtually no syntactic depth. You can generally
summon any of several verbs on a noun via a pop-up menu, and you can drag nouns
into folders and (sometimes) applications, but that's about it. Verb and noun,
sometimes noun and noun.

Contrast that to a fully-featured command line. Not only do most verbs come with
a whole slew of personal adverbs (including prepositional phrases that take
standard nouns as their indirect objects), but constructs such as `backquotes`
and the | pipeline mean that verbs can be nested indefinitely. Consider the
following command:

  ls -l `which ls` | head -c 10; echo

This arcane invocation is composed in a straightforward way of simple, commonly
used Unix commands. I'll break it down.

"which ls" returns the location of the executable that is run in response to the
command "ls", and the `backquotes` mean that that value will be substituted in
the enclosing command. In this case, "which ls" yields "/bin/ls", so the line
becomes:

  ls -l /bin/ls | head -c 10; echo

The ";" simply separates two commands to be run sequentially. So we can rewrite
this as:

  ls -l /bin/ls | head -c 10
  echo

The "|" also separates two commands, but with the additional meaning that the
output of the first is passed to the second, not unlike dropping a file onto an
application icon.

The "ls" command lists files. It is commonly used to list the contents of a
folder (roughly the same information obtained by looking at a folder window full
of icons), but here we're specifying just a single file to be listed.

Normally this wouldn't be very useful -- it would just tell us the name of the
same file that we named to it -- but the "-l" adverb tells "ls" to give the long
listing, with various metadata. In this case, the output of "ls -l /bin/ls" is:

  -rwxr-xr-x 1 root root 96216 2008-06-26 19:31 /bin/ls

The various parts of this line indicate various facts about the file: who has
permission to do what with it, how many links there are to it, who owns it, how
much space it takes up on disk, when it was last modified, and its name.

The command "head" takes the first few lines of a long block of text. Its "-c"
adverb makes it clip by characters rather than lines, and the "10" specifies
how many characters to take. Thus, the command "head -c 10" takes the first ten
characters of whatever we give it.

The first ten characters of the output of "ls -l /bin/ls", not coincidentally,
are the permission information.

Thus, the ultimate output of this command:

  ls -l `which ls` | head -c 10

is this:

  -rwxr-xr-x

The command "echo" starts a new line, like pressing Enter in a text editor.


The ultimate effect of the command, then, is to locate the program "ls" and
extract its permission information for display.


The moral of the story is this: in a single command, composed by simple, known
rules out of simple, known parts, a very specific effect is achieved.

To enable the user of a window-and-icon interface to do the same thing, the
programmer would have to explicitly anticipate that users would want the
computer to perform that particular combination of tasks. With each additional
combination, the programmer's task becomes larger. The combinatorial explosion
absorbs the programmer's effort; it is an obstacle.

But good, powerful, flexible syntax grants vast power to the user at modest cost
to the programmer. Each additional combination requires nothing more of the
programmer, yet is a great boon to the user. The combinatorial explosion
amplifies the programmer's effort; it is a tool.