Volume #1 Issue 4 October 1987
My latest game, entitled Trust and Betrayal, the Legacy of Siboot, has at long last been released by Mindscape. As some of you know, this project has been a long and painful one for me. I am, quite naturally, proud of the fruits of my labors, and I am tempted to boast of the surpassing glories of this design. Certainly the 13 blank pages of this issue of the JCGD are temptation enough. So, yes, I believe I shall indulge myself and show off my latest creation.
The game is, I think, important for game designers to note, because it breaks new ground in several areas of game design. The most important of these is of absolutely fundamental importance: the first incorporation of real characters in a game. Now, there have been characters used in games before. Who can forget Floyd the robot from Planetfall? Or Werdna from Wizardry? Or even Pinky, Blinky, and ole Whats-his-Name from Pac-Man? We have seen characters before, but what did they actually do? Did Floyd ever once acknowledge your existence as a human being? Did Pinky ever treat you like a real person? Did Werdna ever show you that he cared about you?
The answer, of course, is always negative. These "characters" that we have so far seen in computer games are poor substitutes for the real thing. They are Potemkin villages, false fronts that cover a shabby reality. The reality is that they are NOT characters, they do NOT have any feelings, they are NOT aware of your existence, and they can NOT interact with you as characters. They are Teddy Ruxpin dolls, not characters.
A good character is somebody with whom I can have a rich emotional interaction. A good character has a distinct personality that I can get to know, and will behave in a manner consistent with that personality, even if it isn’t always predictable. If I tell Floyd, "Floyd, you are ugly as sin!", his feelings should be hurt. And if I suggest that we perform unnatural acts together, he should respond differently.
This is of fundamental importance because characters are the vital essence of so much of our art. Try to imagine the movies without any characters in them. Try to imagine literature without any characters, or theater without any actors. You think that’s too highbrow? OK, take Star Wars and delete Darth Vader, Luke Skywalker, Obi-wan Kenobe, Princess Leia, Han Solo, C3P0, and R2D2, and what have you got left? Nothing! Without characters, the movies would be dull, boring, and lifeless. How can computer games hope to be any better without characters?
Putting real characters into computer games is not easy, as many of us have already learned. There are two gigantic problems to be solved: artificial personality, and a language of interaction. Trust & Betrayal solves them both, in a pioneering and therefore clumsy fashion.
Artificial personality involves the modeling of human personality in the computer. It is NOT related to artificial intelligence. AI is an academic discipline dedicated to the solution of academic problems, mostly mathematical in nature. Artificial personality is concerned with the capturing of human nature in algorithmic form, and is more properly treated as lying in the field of the arts rather than the sciences. The fact that artificial personality makes use of highly technical means (algorithm creation and programming) does not remove it from the domain of the arts; the sculptor, the painter, and the musician must also master highly technical material before they can ply their arts.
In the course of this project, I developed an artificial personality module that made decisions for the computer characters. The model uses seven invariant personality traits such as integrity, gullibility, desire to be liked, pride, and so forth. There are three relationship variables: love, trust, and fear. Finally, there are three short-term moods corresponding to short-term versions of love, trust, and fear. For each possible type of interpersonal event that could happen to a character, I wrote a set of evaluative equations that first determined the character’s emotional response to that event. Then I added a set of behaviors from which the character would choose, depending on his personality, mood, and relationships. The code to do all this ran to some 1100 lines of Pascal, much of it performing arithmetic calculations.
Actually, the second problem was the tougher one. I had to design a language of interaction for the game. Characters don’t mean much if they can’t express themselves. Now, the obvious choice here is the English language, but we should not be overly optimistic. We will not be able to converse in English with any computer anytime in this century. What’s the problem with stuffing English into a computer, you ask? It’s certainly not the 600,000 word vocabulary. Jeez, a few megabytes of storage can handle that easily. And grammar and syntax, those are child’s play. A few thousand rules to code up, some tables of exceptions big deal! The real problem, the killer, is this: if you want to put English into a computer, you must also squeeze in the rest of the universe.
Consider, for example, the simple word, "brick". Five letters long; you compaction freaks could probably squeeze it into a couple of bytes. The problem comes when you try to use the word. Do you realize just how much intellectual baggage comes along with that simple word? A brick is hard; if you intend to talk about bricks you had better understand what hardness means. It has flat sides; make sure that your program understands flatness, too. It is massive, so you’d better include all the laws of physics regarding the behavior of massive objects if you want to understand sentences such as, "Can you tie the paper to the brick and throw it across the chasm between us?" Oh, yes, it also has color, so be sure to include everything about color and while you’re at it, be sure to include such things as texture and thermal conductivity, as well as magnetic susceptibility and ignition temperatures and combustibility...my, my, it does get out of hand quickly, doesn’t it?
Language does not exist in isolation from reality. Language mirrors reality. We live in an immensely complex world, and short, simple words such as "brick" carry much of that complexity with them. When you see something called a brick in a regular text adventure game, you know it isn’t really a brick; it should more properly be called "the thing you throw through the window in the log cabin to get inside", because that is the true operational reality of the thing, and its ONLY reality in the text adventure. To bestow so grandiose a title as "brick" on so lowly an entity is truly a crime against the language.
I do not argue that putting language inside a computer is impossible. It most certainly will happen, eventually. After all, language is the vehicle we use to communicate with other people. It’s stupid to communicate with people in one language and computers in another. Someday, we must and will communicate with computers in English. But that someday is a long way off. So what do we do in the meantime?
One approach is to use a subset of English. Restrict the vocabulary to a few thousand words, the grammar and syntax to sixth-grade level, and keep the game environment very simple. That should hold the problem to levels that can be managed in a microcomputer.
It doesn’t. English words don’t fit inside tiny boxes well; they tend to have broader meanings than we need. Worse, I have yet to see a text adventure that restricted its environment tightly enough to allow the words it used to carry any true meaning. The game-language should be a verbal image of the game-world; so far, the subsets-of-English that I have seen are distortions that poorly image some of the traits of the their game-worlds and suggest other traits that don’t exist.
Another solution, the one that I created for Trust & Betrayal, is to create a special-purpose language for the game. This may sound radical, but in fact all computer programs create special-purpose languages. Watch some poor wretch struggling with the mass of commands in Microsoft Word sometime. It’s a language, all right, but a language designed for the convenience of the programmer, not a language designed to conform to linguistic principles. Sometimes the languages of applications programs are elaborate, sometimes they are simple, but they are always there. I decided to be explicit about it.
The language used in Trust & Betrayal has many interesting features. It is a visual language, using icons as words. The player clicks on icons to speak the words. Now, all you religious fanatics on either side of the icon issue can just calm down, because the icons are not the essence of the language. If you want, you can click on an existing icon to get an approximate English translation. The icons do allow me to build sentences that are geometric structures, and the spatial relationships between the words suggest the structure of the sentence. For example, direct objects are always to the right of the verb, and indirect objects are always underneath the verb. However, the same thing could have been done with text by showing a sentence diagram.
The first really important thing about this language is that it uses what I call an "inverse parser". A regular parser has you type in your sentence, and then it scans the sentence, figuring out what you meant to say. If you make a mistake, it spits out the sentence with a dismissive error message and you must try again. Regular parsers put the human in the position of the supplicant. That’s the wrong way to run a user interface!
The inverse parser examines the user’s situation and determines all possible words that the user could reasonably choose for the next position in the sentence. It then presents only those words that make sense, and the user selects a word from the set offered by the computer. The advantages of this are manifold. First, the user never has to play parser puzzles. Anything that can be said is automatically legal. The user cannot make a semantic mistake. Moreover, the rules of the game can be implemented in the inverse parser; thus, the user simply cannot cheat. The user cannot lie; any untruthful word is not made available. Finally, many wasteful or useless expressions can be eliminated by the inverse parser. For example, one of the constructions used by the inverse parser allows the user to offer a deal to another character. The inverse parse is able to examine all possible offers and eliminate those offers that would not make sense, such as offering information that the other character already possesses. In this way, the game is made to run faster and cleaner.
As you might imagine, all these wonderful things do not come for free. It takes a lot of code to execute all these great features, and this raises issues concerning resource consumption. How much RAM does all this take? How many cycles does it eat? And how much programmer time did it take? Well, the RAM consumption is not too bad -- maybe 30K for all the code and data. The consumption of cycles is high, but not enough to cut into the play of the game. The inverse parser always comes back in a perceptible fraction of a second. Even so, I can still enter sentences with the inverse parser much faster than I could type the equivalent text, and I’m a fast typist. It is true, however, that the creation of the inverse parser consumed a great deal of my time. I estimate that I expended about two months getting it to work properly. The inverse parser routine culminates in a single mammoth boolean expression an entire page long. As you might imagine, this took some time to debug.
The other important thing about this language is that all the words actually mean things. There are only 80 words in the entire language, but each word is fully operational. These 80 words define a complete social system. All of the interactions available in the game are completely addressed by the language. The real trick here is that the language completely covers the reality of the game because the reality and the language were defined together. I defined the entire system as a whole, struggling to find a combination of reality and language that was expressible, manipulable, and fun.
There are a number of design elements that are interesting but not earth-shaking. One of these is the "Random Events" feature. I have long preached about process intensity in games, the notion that a game is (or should be) a process-intensive program with lots of heavy number-crunching and very little reliance on data. Most games are data-intensive, putting most of their resource on snazzy data in the form of images, sounds, or predefined stories. The weaknesses in my argument have been first, that data capacity has been growing much faster than processing capacity, and second, that process-intensive games tend to lack color and texture. My concession to these problems is the Random Event, a special-case situation that arises just once during each game, although there are some fifty different random events that could arise. Each random event tells a little story and presents you with four options. The random events are not as purely process-intensive as I prefer, but they do add a lot of color to the game.
Another cute feature is the use non-commutative combat relationships. I have argued for several years now that non-commutative combat relationships are necessary to promote anticipation in game-playing. Anticipation, in my theories, is vitally important as a way of deepening the interaction between two players. The problem is, non-commutative combat relationships just aren’t realistic. If my stick is bigger than your stick, and your stick is bigger than Fred’s stick, then I can still whomp Fred real hard. I was able to get around this problem by postulating "mental combat" that takes place while you sleep. Anything’s possible if you’re willing to get weird enough.
At a recent speech in Boston, I held up a copy of Trust & Betrayal and declared that I was "nailing it to the church door". It was a cheeky metaphor, and the audience grumbled at my hubris, but if you take away the wild exaggeration, there remains a grain of truth in the metaphor. Trust & Betrayal is a radical departure in game design, and its emphasis on characters rather than resources is profoundly important. I very much hope that all game designers will look over the game, extracting the important ideas even as they look beyond the flaws.