First Draft Proposal

The central problem of Talk to the Animals lay in the language. How could I design a language that would permit the kinds of interactions I wanted between the player and the characters of the game? It was obvious to me that I could not use natural language; researchers had been struggling with the problem for years and had not come close to solving the problem on big computers, much less a little personal computer. This led to the conclusion that I would have to invent my own little language. I needed a system of subjects, verbs, direct objects, and so forth that would permit the player to Talk to the Animals.

Now, there already existed a solution to the problem of using language in games: the parser. Indeed, one of the more successful games companies in the industry at that time was InfoCom, famous for the powerful parser that lay at the heart of its excellent adventure games. These games allowed the user to type a sentence in normal English; the parser would then figure out what the sentence meant. The problem, unfortunately, was that parsers were notoriously obtuse. The great majority of sentences that a reasonable person might type would confuse the parser.

Sometimes it was a matter of vocabulary; I experienced this problem in a particularly frustrating form. In the adventure, I had entered a room and read the detailed description of the room, which included a mention that there was a rock lying on the table. I typed "Pick up rock," to which it replied, "I see no rock here." It then re-listed the room description: "Big green room. There is a rock sitting on the table." I was beside myself with fury. I attempted many adroit schemes for laying my hands on that rock, but failed until I typed "Pick up stone." The computer responded, "You now have the stone."

More often, though, the problem was more fundamental; you simply weren't allowed to carry out the great majority of actions that you might contemplate. If you wanted to move the table to the kitchen so that you could stand on the table and look on top of the refrigerator, that would likely not be possible. If the designers of the adventure game did not intend for you to carry out an action, the words for that action would not be included in the parser, and the only way to establish this was through tedious trial and error. A typical fragment of an adventure game might read like this:

You are in the outer entryway. There is a door leading into the main room of the building.

Open door.

The door appears to be stuck.

Kick door.

The door shakes but remains stuck.

Throw rock at door.

The door shakes but remains stuck.

Use knife on door.

The door shakes but remains stuck.

Shoot door with gun.

The door shakes but remains stuck.

Set fire to door with matches.

The door appears to be inflammable.

And so on and on and on. The difficulty here arises from two facts:

• First, the working vocabulary of the game is much smaller than the working vocabulary of most people. The odds are low that any word you choose will actually do something in the game.

• Second, the working vocabulary of the game is hidden from the player you don't know what the magic words are. You just have to guess.

For all these reasons, I had rejected the parser approach immediately. My solution would have to use a small subset of the English language that was unavoidable. I just needed some way to make that subset obvious to the user and broad enough to handle all the situations in the game. The solution hit me in the face as I was traversing an airport. All the iconic signs for restrooms, departures, arrivals, restaurants, and so forth provided the perfect model. Some sort of iconic system that would be my model.