Table of Contents
Editorial: Off and Stumbling
Chris Crawford
Letters
George Metos, James Kerwin
Second Generation Adventure Games
David Graves
Some Observations on Credit Assignment
Chris Crawford
A Fun Game Design Cookbook
Gregg Williams
We Are Not Keeping Pace With the Hardware
Chris Crawford
Salary Survey
Chris Crawford
Call for Articles
Chris Crawford
EndPage: Late Night Ruminations
Chris Crawford
Editor Chris Crawford
Subscriptions The Journal of Computer Game Design is published six times a year.
To subscribe to The Journal, send a check or money order for $30 to:
The Journal of Computer Game Design
5251 Sierra Road
San Jose, CA 95132
Submissions Material for this Journal is solicited from the readership. Articles should address artistic or technical aspects of computer game design at a level suitable for professionals in the industry. Reviews of games are not published by this Journal. All articles must be submitted electronically, either on Macintosh disk or via modem. No payments are made for articles. Authors are herbey notified that their submissions may be reprinted in Computer Gaming Forum.
Copyright The entire contents of this Journal are copyright © Chris Crawford 1987.
_________________________________________________________________________________________________________
Editorial: Off and Stumbling
Well, the first issue went out to about 100 people, and the response, while not overwhelming, was pretty good. I was worried that I would get so few subscriptions that the effort would not be worthwhile. So the JCGD is a “go”. Hurrah!
As always, though, it could be better. I would certainly like to see more subscriptions, not for monetary reasons, but to establish greater credibility for the Journal. It is my hope that this forum will command some respect from the various publishers and magazines who help make this industry function, and the best way to get that respect is to have the Journal represent the views of a large segment of the designer community.
I therefore ask all readers to subscribe if they haven’t done so yet, and to spread the word about the Journal to their professional acquaintances. For my part, I am again sending this issue out to everybody on my mailing list, even those who have not yet subscribed.
Russell Sipe at Computer Gaming World is starting a new magazine called Computer Gaming Forum. Although the subject matter is similar to that of this Journal, his target audience is more general than this Journal’s. He has asked for permission to use material from the Journal in his new publication, and I have agreed in principle. Therefore, in the future, any person submitting material to the Journal should realize that his material might well appear in Russell’s new magazine. As with the Journal, no remuneration is offered for published material.
Which brings me to the subject of copyrights. The first issue of the Journal was not copyrighted, because I did not wish to discourage software publishers and magazines from photocopying issues and spreading them liberally through their offices. However, many people have argued long and hard against this policy, and so I have decided to yield to their persuasion. I now assert copyright for the Journal. Any author who wishes to retain copyright for his own work should simply append the notice “Copyright © Author Name 198x” under his byline.
_________________________________________________________________________________________________________
Letters
Re: “Whence come computer game designers?”
It seems that there are a few common denominators among the five game designers that you have listed. I think I can still be objective enough to say that all five formulated design opinions in a medium other than home computer games. You cite histories such as board games, television journalism, and literature. I have a lot of respect for competent state-of-the-art game designers. Why have these (and probably many other) game designers evolved into using computers as their medium of expression? My guess is that they feel that with a computer they can transcend their prior restrictions of size, speed, uniqueness, convenience, graphic appeal, portability, etc. Oh, can marketability be another?
I will go out on the limb and also guess that all five game designers you have discussed DID NOT intend to become video game designers during the years of growth of their game designing abilities. Not that any of the five would not love to have anticipated and planned on becoming video game designers. Unless you expect a large circulation of your journal among the not-so-large pool of game designers, may I humbly suggest a realistic pathway toward a career as game designer? We know that would-be designers will also be reading the journal.
My first suggestion is to develop a port or conversion of an existing game. To do this, one needs a deep understanding of a given computer, graphics, assembler, own development system, have a business connection, etc. Then possibly a second port, maybe even a third. Finally, an original, albeit in collaboration with other designers or suggestions by the publishers. Bright designers will attain confidence and abilities as they practice. Too often, I am asked how a person becomes a game designer by individuals who are not involved whatsoever in game development.
We work with a lot of publishers, and I am convinced that their input is vital. In some cases, they spend hundreds of thousands of dollars on market research. This is valuable, virtually free information for the game designer. They may or may not know how to design a game, but they sure know what kind of game they want to sell. I know that it has worked in the past for many designers, but a designer who develops his/her ideas into a completed game without a contract is making life tough unnecessarily. I will bet I sound a bit too business oriented, but let's face it, we are talking about professional game designers. If they do not take a business-like approach to this, I believe their chance of remaining a game designer is lessened. Even game designers need to eat.
George C. Metos
General Manager and Vice President
Sculptured Software
One comment: could we refer to ourselves as “computer game designers” instead of “video game designers”? I have always associated the term “video game” with arcade games and the Atari 2600. We’ve come a long ways since those days and don’t need to use a term that has, in some people’s minds, a tawdry connotation. —Editor
Re: Doug Sharp’s analogy comparing games to movies
....I too like to use analogies to movies in thinking about computer games. But while I’m sure his comparison of games to movies is valuable for him, he should remember that they are different art forms. It makes as much sense to talk of computer games surpassing movies as it does to talk of movies surpassing books. Movies and computer games are different media, with different strengths and weaknesses. Competing with movies is a dead end; it can only hurt the development of computer games, not help it.
First, computer games will never equal the storytelling power of movies. There are a number of reasons why any attempt to do so is doomed to failure. Computer games fall short as a storytelling medium because of the impossibility of realizing living characters within the story. Doug himself admits this, although he asserts it will someday be possible. (I disagree that it will ever be possible.) But even if it were possible, it makes no sense to use a medium today in a way that will only be valid one hundred or one thousand years in the future.
In the second place, computers and computer games are inherently a “cool” medium; movies are a “hot” medium. By this I mean that aesthetic distance is minimized in movies, but is great in computer games. A cool medium cannot engage the audience as fully as a hot medium. It thus cannot have the storytelling power of a hot medium, although it is better for other purposes.
Third, movies (and plays) get much of their power from the resonances between the structural layers. The congruence between the theme, plot, setting, and character layouts generates emotional power. Computer games will never have a significant theme level because the outcome is variable. The lack of theme alone will limit the storytelling power of computer games.
Further, I must challenge his assertion that “Our machines will surpass film and television in graphic and aural quality well within our working lives.” This claim is preposterous. It may be true for television, but certainly not for the movies.
Chasing after movies is a fruitless ambition. Rather than head down blind alleys, we should look for what computers can do well. If we utilize the strengths of the medium, we will make better and more profitable games.
When we think of the strengths of computers, the first one we think of is their computational power. We must use this power to make good computer games. But the notion that computer games must involve AI is wrong. Again, Doug’s type of game and others will require advances in AI to reach maturity. But the point of computer games is to make a human think, it is not necessary for the machine to think. We should not get hung up on AI, but use it only when needed.
Both Chris and Doug assert the importance of AI in creating lifelike characters. I think computer game designers are missing the main line here. It is not necessary to re-invent the human being; we have plenty of those already. Rather than enjoying the company of fake humans, humans like to get together with real humans....I believe the most fertile and fruitful path of development is to create games that allow human beings to have fun together....
James Kerwin
_________________________________________________________________________________________________________
Second Generation Adventure Games
by David Graves
[David was one of four implementors of a mini-computer based, multi-user, real-time text adventure game called Quest; it allowed up to twenty human players on terminals to interact with each other or with simulated characters. He is now working on a participatory novel.]
Expanding the horizons of the traditional adventure game format has created a new genre in literary entertainment: the participant novel. Implementing a participant novel, in which the player is more a character in a plot than a solver of puzzles, demands special computer modeling techniques. As the program increases in complexity, use of the proper representation of the novel’s simulated environment becomes critical. Without a strong model of the world and its physical laws, and without a dynamic interface to this world, the developer is doomed to producing a limited and unstimulating game. The field of Artificial Intelligence provides programming constructs useful for creating these games of greater complexity and sophistication. This article will present a few ideas borrowed from the field of AI: use of lists and trees, attributes, natural language parsing, English generation, semantic frames, and goal-oriented routines, and show how they support the complex model that a participant novel requires.
Lists and Trees
Given that a participant novel will be populated with a great many people, places, and things (hereafter called ”objects”), there must be a dynamic method for tracking and altering the position and relationships of each physical object. In AI, the most heavily used organizing structure is a list. One can create a model of the world as lists of containers: cities contain houses, houses contain rooms, rooms contain things, and things contain other things. The traditional method for representing complex relationships of objects is through lists of lists, also called trees. Under this arrangement, every object has pointers to its parent (the thing that contains it), its children (the things it contains), and its siblings (the things in the same place with it). This can be coded as three arrays: parent, child, and sibling. Each slot in the array contains either an object’s identifying number or ”nil” (a null pointer). An object that is empty would have nil in its child slot, and an object that is alone in a container would have nil in its sibling slot.
Objects containing several other objects are represented using the child and sibling arrays together. The container points to the first child and the first child points to his sibling, who points to the next sibling. The end of the list is indicated with a nil sibling pointer. For example, a chest containing a lamp and a rope would have the object number of the lamp in its child slot, and the object number of the rope would be in the lamp’s sibling slot. The lamp’s sibling slot would be nil. Both the lamp and rope would have the object number of the chest in their parent slots, and nil in their child slots. Representing the world in this way makes it very easy to manipulate groups of objects. Moving a chest to new location involves changing only the pointers of the old and new locations and the chest. The contents of the chest never need be considered. No matter how large the object tree becomes, moving any object and all of its contents can be done by changing only a few pointers. Since people, places and things are all represented in the same type of data structure, only one routine is required for all types of object movement.
It is important that the constructs used in the model be simple and consistent. The model should be general enough that special constructs will not be required each time the programmer thinks of a new type of object to implement. For example, supporting surfaces (such as tables and chairs) can be implemented using the same parent, child, sibling scheme. The objects resting on the table are its children. The internal representation of the table and its children is identical to the container representation, so supporting surfaces are easily added to the model.
Attributes of objects
All objects have characteristics or “attributes” that define that object’s limitations. Some attributes are boolean (stating whether this object is flammable or immovable for example) and some may have a numeric value associated with them, such as the weight and volume of an object. Some attributes are unchangeable (such as flammability and mass) and some are variable, describing only the current state of an object (i.e. closed, locked, and burning).
Using attributes to define how an object may be manipulated within the model world allows the programmer to define a much more consistent and dynamic world. Consider the case where the programmer creates a fireplace and some logs. He adds some special case logic to his program that will support burning the logs with the expectation that the player will attempt to burn the logs in the fireplace. However, if the player tries burning a chair in the fireplace, nothing happens because the luckless programmer didn’t think of the player trying that. This mess can be avoided by building the game’s verb routines around a system of attributes. By defining the attribute “flammable” and making the Burn verb check for the presence of this attribute, the programmer allows the player to burn down anything flammable, such as furniture, papers, doors, and fireplace logs. Thus, he defines the generalized phenomenon of “burning” rather than coding individual cases.
Once the programmer has decided on the set of attributes he wishes to support, he need only write individual action routines that manipulate those attributes, then decide which attributes apply to each of his objects. Thus, some whiskey could be defined as having the attributes liquid, edible, and flammable. Groups of attributes can work together in subtle and wonderful ways, allowing the player to perform activities in ways not even considered by the programmer. Would you think of putting moonshine whiskey in a lantern if you had no kerosene?
Recognizing natural language
Understanding natural language has proven to be a difficult problem in AI, but much can be done in a participant novel by recognizing relatively simple statements in the following syntactic form:
[Subject] VerbClause [DirectObject] [Preposition IndirectObject]
Optional sections of the syntax are enclosed in brackets. Each word in a command typed by the player is looked up by a dictionary routine and is identified as a verb, noun, adjective, or whatever. The most simple command or “statement of intent” is simply a verb. Instructions to another person are indicated by using that person’s name as the subject of the sentence, as in “Sam, run!” Omitting the subject of the sentence implies that the player himself is the actor. Direct and indirect objects are noun clauses, which consist of some optional adjectives followed by a noun. Prepositions such as “at,” “in,” and “on” separate a direct object from an indirect object. Conjunctions, punctuation, and articles (such as “a” and “the”) can be tossed out by the parser as “noise”, or verified to appear in the expected positions.
This syntax will accept input strings such as “Put the gray stone into the large oak chest”. By further extending the parser to allow a list of objects as a direct object and allowing sentences to be strung together, the program can recognize statements like “Open the chest, take the lamp, the knife, and the long rope, then climb the stairs”. Since everyone has a slightly different way of saying what they mean, the program must have a very large dictionary with links between synonyms. Thus, “Set the lamp on the table” and “Place the lantern onto the table” could be recognized as having the same meaning.
Travel is something that happens frequently in this type of game, so it should be very easy for the player to express what is desired. The parsing scheme above will recognize travel syntax such as “Climb the tree” or “Enter the cottage,” but not “Go east” or its abbreviated forms, “East” and “e”. Recognition of these few irregular forms can be added to the parser as a special case.
The parser should be able to recognize modifiers for verbs. The simple case is the use of an adverb, as in “Carefully open the door”. A more complex case is where the player uses a verb and a preposition together in a way that changes the meaning of the verb. For example “put down” means drop, “put out” means extinguish, and “put on” means wear. This can be implemented by creating a table with verb/preposition pairs followed by the resulting verb. When a verb/preposition pair in the command string matches an entry in the table, it can be replaced with the resulting verb. Parsing then continues as if no preposition has been seen yet. This trick also allows recognizing a command with a dangling preposition such as “Take the cloak off” which would otherwise be rejected by the parser as an incomplete sentence.
We are all accustomed to using pronouns (such as “it”) and expecting our listener to resolve what we mean by reviewing the preceding context. A natural language parser might be expected to do the same. A simple rule for implementing parsing of “it” could be “Replace the ‘it’ with the last direct object named”. The parser could also be expanded to allow words such as “everything” or “all” in place of a direct object. This lets the player make statements like “Drop everything into the chest“ . Note that the semantics of “everything” change with the verb used. In “Drop everything,” “everything” really means “everything that I’m holding,” while in “Get everything,” it means “everything that I’m not holding”. For some verbs, such as “Examine,” the scope of the word “everything” is “all visible objects, whether held or not”. The player may also wish to set the scope of “everything” to a limited domain, as in “Look at everything on the table”. Regardless of how “everything” is used in a sentence, it can be implemented by simply calling the verb action routine once for every object within the the command’s scope.
Generating English
While interacting with a participant novel, the player is going to read vast quantities of text. Some of this may be “canned text” and some will need to be generated. The constant attributes of a location could be described with fixed text, but certainly not the descriptions of the objects there. Since most objects can be moved around, placed in and on each other, and change state, the program must be capable of dynamically producing the text to describe them. The key to generating interesting text is to vary the length of the sentences generated, vary the sentence structure, and use different synonyms whenever possible. For example, to describe the “children” of a table the program might generate:“There is a knife, some bread, and a key on the table,” or “A knife, some bread, and a key are on the table,” or “Resting on the table are a knife, some bread, and a key”. The description generator would have a list of synonymous phrases such as “resting on,” “lying on,” and “sitting on”.
A text generator must pay careful attention to the issue of grammar. When a sentence contains a list of objects, the objects must be counted so that the conjunction “and” can be inserted before the last object. Lists containing more than one object will use “is” instead of “are”. The attributes of an object will dictate when to use “a”, “the”, or “some” in a noun phrase. Attributes also indicate the type of preposition used in the generated text. For instance, describing the children of a surface (such as a table) would dictate the use of “on,” while containers would have things “in” them.
The result of the player’s actions can be reported via a text generation facility as well. When the player enters a vague command such as “Drink,” the program would give all the details of what happened, such as “You drink some cool water from the stream,” thus informing the player that his canteen has not been taxed. This reporting mechanism should make use of pronouns when an object is mentioned more than once in a sentence, to avoid generating text that sounds too mechanical. An example of this would be “You give the bowling ball to Sam, but he drops it”. As before, the attributes of an object will aid in selecting the appropriate pronoun.
Frame-based exceptions
Any nontrivial model of reality will contain a large number of objects whose characteristics and behaviors differ from normal expectations. These exceptions might range from personality quirks to magical or“high-technology” physical properties that deviate from the norm. A computer model of such a world needs a simple method to define, organize, and deal with all these exceptions. One method is to attach to each exceptional object some information about the context in which an exception applies, and the effect of invoking that exceptional behavior. The effect is defined as a fragment of executable code. The context is defined in a semantic frame. In AI, a frame may be defined as “an instantiation of a context”. In this scheme, a frame is a simple template for a single semantic action using a specific verb type and specific objects. Any object can point to a unique frame, which points to a code fragment. This way, a frame defines the semantic context in which an exception handling code fragment applies.
Assume we had modeled the mouth of a volcano as a large container. Normal semantics for an object tossed into container dictate that the object will come to rest inside the container. In this case, however, we want to have the object be completely destroyed. The volcano could then be defined with a frame that reads “Throw anything into the volcano”, to provide the context in which the exception will be invoked. Whenever an actor throws any object into the volcano, this frame is selected as matching the actor’s action. After the default processing for this action, the code fragment attached to the frame is executed. The code fragment would cause the object to be destroyed, and perhaps display a colorful description of the event.
Frames may specify a specific context (by requiring a specific verb, direct object, and indirect object) or a more general context (with a range of verbs, and “wild card” matching of direct or indirect objects). Moreover, some frames must take precedence over others. Any action might match the frames attached to the direct object, the indirect object, the location, or the character performing the action. Since an action might invoke several conflicting exceptions, the game program must select the one frame that is the best match to this action. Consider the case of an explosive with a context frame stating “Throw the explosive into the volcano”. This frame is more specific than the volcano’s “Throw anything into the volcano”, so the explosive’s frame is selected. The code fragment can then define some effect that is an exception to the “normal” exception.
An object may have any number of frames attached to it, and multiple frames may point to the same code fragment. A code fragment may override the default semantics for an action completely, or simply append additional semantics. Finally, objects may be defined which inherit frames from other objects, which speeds development and lowers the chance of coding error when defining objects with similar exceptional properties. It is important to note that the use of semantic frames is intended only for those actions or properties that are exceptional, and should therefore be used as sparingly as possible. Attaching the same exception frame to many objects can be an indication that it is not so exceptional after all. In this case, one may want to define a new object attribute for this “non-exceptional” exception, and handle those objects via the normal semantics routines.
Incidentally, one can use a scheme of frames and code fragments to control behavior for simulated actors in the story, but the results are very limited. The actor becomes only a “stimulus-response” being; he responds only to actions or commands from the player, and speaks only when spoken to. For example, an actor named Sam might have a frame attached to him, stating “Throw anything at Sam”. If the player (or another actor) throws any object at Sam, the attached code fragment is executed, which might put out a message like: “Sam is outraged by the insult, and draws his weapon”. Clearly, the actor can only demonstrate those behaviors that were preprogrammed. Things become much more interesting when actors are capable of original behavior. Each computer-controlled actor should be able to recognize a need, then create a plan to fulfill it. Different personality types (based on attributes, once again) would give rise to different types of behavior.
Goals and subgoals
A standard feature in many adventure games is the requirement that the player remember long sequences of actions in minute detail and type these sequences when needed. Forgetting to perform one of the steps in a sequence results in an error message. For example, if the player sees a bottle of beer on the table and says “Drink the beer,” he is likely to get an error message like “You aren’t holding the beer” or “The beer isn’t open”. Memorizing detailed sequences of instructions is not what most people would call fun. Wouldn’t it be much nicer if the computer could just “understand” the player’s intent?
It turns out that it is relatively easy to create a system in which the programmer defines a corrective action for such an error, instead of giving an error message. By defining the prerequisite state attributes for any action, the system can automatically break a goal into sub-goals. Thus, when the Drink routine finds that the player is not holding the beer, a new sub-goal is set: get the beer. Upon resolving that sub-goal, the Drink routine is re-entered. It then checks to see if this container is open and if not, it sets a new goal: open the container. In the end the player is told of how all these events proceeded with a message like: “You take the beer from the table, open it, and drink from it”. This is type of processing is not the generation of a plan to achieve a goal, but simply filling in the implied prerequisite actions.
Any new goals must be stored on a stack rather than in a static structure, since any goal can create new sub-goals, which may create others. Each goal must be resolved in order, the latest goal first. The game program simply attempts the action on the top of the stack, pops it off if successful, or pushes new sub-goals if needed. It is important to note that only errors concerning variable attributes are correctable. Errors caused by conflicts in fixed attributes (such as attempting to set fire to a stone) are not correctable by creating a new sub-goal. If a noncorrectable error occurs, the player is informed and his goal stack is cleared.
Note that once all of the verb routine have all their prerequisite states defined as sub-goals, it becomes very easy to simulate intelligent behavior by other actors in the story. For example, if the player asks another character to “Go out, get the rope and return,” the character appears to make intelligent decisions like opening the door before attempting to exit, and untying the rope from a tree before attempting to walk away with it. The pace of the game remains brisk since the player need not specify each detailed step in a process. The software “understands” what is implied by the player.
Summary
By selecting a simple, yet powerful model, the designer can create a much more dynamic, consistent representation of the novel’s fantasy world. All of the ideas presented have been successfully applied to a working game system, which is still under development. Of course, even the best software needs a well written story to make an interesting participant novel, but that a topic for another article.
_________________________________________________________________________________________________________
Some Observations on Credit Assignment
Chris Crawford
One of the minor issues in all of the entertainment industries is the manner in which the creator’s name is presented to the public in the work. A product creates an intangible asset: fame. The financial value of this asset lies in the tendency of customers to buy more products associated with a name that they recognize and respect.
To whom should this asset accrue? Most of us would answer, “To the author, of course!” but in practice this does not work out that way. Publishers want a piece of that pie for themselves. Moreover, the greater the fame of the designer, the stronger his negotiating position. Thus, publishers have strong economic incentives to minimize the author’s credit and maximize their own. They are in an excellent position to act on these incentives. After all, the publisher controls the design of the package and the advertising. The result is that few game designers get the credit they deserve.
This is not a new problem. The various entertainment industries are all partnerships between creative people and businessmen, and the same economic forces play in other entertainment industries. The other industries have the advantage of experience over our industry, and they have worked out solutions to some of these problems. Perhaps their compromises can provide a benchmark for our own industry.
I thought it would be interesting to compare the behavior of computer game publishers with that of other publishers. So I sat down with a variety of products and made some measurements. I measured the size of the type in which the author’s name appears on the front cover of the product. (If the author’s name didn’t appear, I entered a value of zero.) I also measured the size of the type in which the publisher’s name appears on the front cover of the product. (Again, I entered a value of zero if no publisher’s name appeared on the cover.) I then averaged the values I measured from ten different products and divided the average author’s name size by the average publisher’s name size. The resulting ratio gives us an idea of how much recognition authors get, independent of the individual artistic considerations for each package. Generally speaking, authors would like to see this ratio very large, while publishers would like to see it very small. I did this experiment for four categories of entertainment products: books, compact disks, videotapes, and computer games. The results:
Category. Ratio
Books: 4.00
Compact Disks: 1.36
Videotapes: 1.14
Computer Games: 0.75
Now, there are a lot of special considerations to toss into this stew. For example, book publishers seldom put their names on the front cover; they make their mark on the spine of the book. This is why the value for books is so high. The compact disks I used were all classical, and I measured the size of the performer’s names, not those of the composers, even though the composer is arguably the name that people most recognize. Finally, the selection of computer games was eclectic; no two products came from the same publisher. I also excluded any products from before 1985; in the early days, publishers didn’t put the author’s name on the package at all.
What conclusions can we draw from this data? I wouldn’t squeeze this small amount of data too hard, but I think that the pattern is clear: we authors of computer games do not get as much recognition as our compatriots in other entertainment fields.
What can we do about it? Well, we could sit around and hope that publishers will freely bestow a greater place for our names on the packaging. Or we can start to demand it in contract negotiations. I personally hope that we can avoid specifications of this nature; I would rather see our industry informally (stochastically?) establish industry conventions that are comparable with those we see in these other industries.
_________________________________________________________________________________________________________
A Fun Game Design Cookbook
Gregg Williams
[Gregg is a senior editor at BYTE magazine. Although he has no published games to his credit, he has written about games for BYTE and Computer Gaming World, he has sat on panels about games at the West Coast Compuer Faire, he has served as a playtester for a number of games, and he has even tried his hand at designing a few games.]
As the old cliche might have gone, “I can’t define a good game, but I know it when I see it.” Over the years, studying and playing both computer and noncomputer games, I began seeing patterns and repeated elements that usually signal a “fun game.” (This is a technical term we use in the game design community to describe certain games. A fun game is something you enjoy playing, even if you lose. If you more often kick yourself for dumb moves than congratulate yourself for clever ones, you are not playing a fun game.) So this article does not make any sweeping generalizations about games in general, just about fun games.
I call this a cookbook because I know all these ingredients are to be found in some really good games--just as a dictionary has all the words you’ll need to outdo Shakespeare or Judith Krantz (depending on what you’re after). Like the apprentice alchemist trying to create the Philosopher’s Stone from base materials, I have tried my hand at finding the magic combination of ideas that makes a fun game. I have not succeeded so far, but I keep trying. What follows is the latest version of my cookbook. I will try to illustrate my points with both computer and board games (asterisks mark non-computer games). The first section will cover the really important points. The next section will cover more mundane points that bear repeating. The third section will include some ideas that I have found useful in their own contexts but not universal.
Primary Elements
At a game reviewer’s panel at the 1987 West Coast Computer Faire, the audience asked us about our favorite fun games, and all four of us mentioned multiplayer games. (I will ignore here the unfortunate reality that they don’t usually sell all that well.) From M.U.L.E. (by Dan Bunten) to Maze Wars ( by MacroMind), games that pit human players against each other have a spice about them that solitaire games lack. It’s fun to play with and against other people. Not only do you have a more interesting opponent, you also have a witness, someone to be gracious to when you win and to kibitz with when you lose. Two-player games are fun, butI really enjoy that rare 3- or more player game that is more an excuse to get some friends together than to defeat an opponent in battle. Favorite 3- or more player games include the two above, Can’t Stop* (Parker Bros.), Robot Rascals (also by Dan Bunten), Cosmic Encounter* (West End Games), Acquire* (Avalon-Hill).
A fun game includes luck, but not too much of it. To me, luck is the leavening that delivers a game from taking itself too seriously (a characteristic that is usually the kiss of death, fun-wise, for a game). With chess, for example, if you lose, it’s your fault; but with backgammon, you can blame your demise on bad luck. On the other hand, there is no satisfaction in winning a game that is more luck than skill; you want a game in which your skill is the factor that carries you to victory. This is evident, for example, in backgammon, in which both players get both good and bad luck each game. It’s what you do with it that makes the difference; good backgammon players almost always win against worse ones.
One of the most nebulous but important attributes of a fun game is what I call a sense of delight--the ability of a game to deliver such a completely unexpected and game-upsetting turn of events that you can’t help but laugh, even when you are the one who gets the shaft. This often happens when the elements of a game combine in an unexpected but delightful manner. One example is in M.U.L.E., when an earthquake moves a mountain over to an adjacent square, thus making mincemeat of your best-laid plans. Another is in Ricochet (Automated Simulations, now Epyx), when a shot ricochets in a way you hadn’t expected and wins (or loses) the game for you. And who can forget the pure delight you experienced the first time you saw Pinball Construction Kit (by Bill Budge)? Numerous fun games have another, related element: a sense of humor or whimsy. In Illuminati* (by Steve Jackson), playing the Gnomes of Zurich, you can control (for example) the Cattle Mutilators, who in turn control the Fast Food Chains, the FBI, and the Orbital Mind Control Lasers. In Mouskattack, an early but nontrivial variant of Pac-Man, you are a harried plumber trying to lay pathways of pipe without running into three rather dangerous mice. Let’s face it: you’re not going to find Boris Spasky playing these games--the object here is to kick back and have a good time. The humor element is often simply a motif that doesn’t directly affect a game’s mechanics; still, it offers an important cue as to how the designer wants you to approach the game.
For those of you who grew up in households where no one ever yelled for any reason, a game that lets someone attack your pieces in a battle to the death may not be your idea of a fun game. (I am, I admit, such a person.) Let’s face it, it’s hard to keep from taking such a game seriously — on however symbolic a level, that person is trying to kill you, a fact that is hard to take nonchalantly. This brings me to the game element of indirect aggression. In a game that uses this element, you don’t directly attack your opponent; instead, you may win simply by getting to the goal first, by competing for a resource in limited supply, or by charging exorbitant prices for something your opponent has the free will not to buy (that is, if he or she doesn’t mind losing and/or dying <heh, heh>). This element often goes together well with a humorous motif to make a (largely) innocent game that is fun for all and makes no enemies. M.U.L.E. is an excellent example of indirect aggression, as it also is of forced cooperation, another way of lowering the antagonism among players. Cosmic Encounter* reduces the stigma of attacking another player by forcing you to attack the player whose color your draw at random from a nonreplenished supply of chips.
Probably the hardest part of a game to design in is a small but rich set of possible moves. I personally am intimidated by games that give you dozens or even hundreds of possible moves (e.g., conventional wargames and countless poorly-designed games). Instead, I want a game that gives me just a few possible moves, each of which has a vastly different but easily visible effect on the game. For example, your character in the classic Lode Runner (by Doug Smith) really has only three moves: move left, move right, and dig a hole, yet various authors have created literally hundreds of different challenges using only these three moves (and the other game elements over which the player has no direct control).
In mathematics, we speak of three mutually perpendicular unit vectors (unit-long lines with an arrow on one end) as being orthogonal; this means that any point in three-dimensional space can be reached by staring at the common origin of the three vectors and adding multiples of them together. I like this idea and apply it when I can to game design: your possible moves should “span the problem space” (i.e., be able to affect every aspect of the game state) and do it in a way that all the moves are “perpendicular” (that is, they affect the game state in non-overlapping ways).
The above situation implies some other things about the game. First, there must be more than one way to win the game, so you should have several strategies from which to choose. Second, regardless of how bad the moves available to you in a certain turn are, one of them should improve your situation, worsen your opponent’s, or both.
Some games go even further than this and ensure that they are conceivably winnable even up to the last move. Sometimes you may need a really improbable dice roll or other chance-related influence. Sometimes the designer has put “hard wired” eleventh-hour respites into the game by giving all opponents one last shot at undoing the work of the player who will otherwise be the winner. I know of at least three non-computer games that do this: a dice game called Cosmic Wimpout*, Cosmic Encounter* (no relation), and Star Trek: the Enterprise Encounter* (West End). (The first two have made the Games 100 list. The last two were designed by Eon Products, for whom this game element has become a trademark.)
These thoughts lead me to another, very important element found in several fun games, a tendency to handicap the winning player. This tendency maintains the possibility of any player winning and softens the difference inherent in players of differing abilities. For example, M.U.L.E. contains both good and bad random events; the first-place player can get only bad random events, and the last-place player can get only good ones. In Ricochet, opponents play one round of a game, trying to hit the other’s bumpers. Three rounds make a game, and on the second and third rounds, the computer decreases the number of bumpers for the player who has just lost (giving the winner fewer targets to hit in the next round) and increases the value of the winner’s bumpers (making the win more valuable to the player who has just lost).
Secondary Elements
By now, I’ve covered the really important elements of a fun game. But there are some less exciting, underlying issues, the absence of which can handicap or sabotage a game design.
The game should make good use of graphics, sound, and color. The more you involve the players’ senses, the better. Ask yourself, “Is the computer necessary for this game?” Computers represent an unprecedented opportunity to create games that couldn’t be done without them. Your game can use the computer for randomizing, for equalizing players of differing skills, for pacing the gameplay, for scorekeeping and recordkeeping, for autonomously regulating what the players see, hear, and know, and many other tasks. Let’s not see any more adaptations of cribbage--or if we do, the game should take us places a deck of cards never could.
In a 3- or more player game that has sequential turns for all the players, it is good if you can keep all the players involved, even outside their turns; this keeps them emotionally invested in the game. In Cosmic Encounter*, for example, a player’s hand may include an Edict card that can be played during another’s turn. In M.U.L.E., players compete for land grants and buy and sell commodities with each other each turn.
Finally, try to ensure that you have the simplest human interface possible. Your inputs, in order of complexity, are button, paddle, joystick, and keyboard. If your game needs a keyboard, maybe that’s an indication that you are giving the player too many choices; or maybe it means that you have been lazy and haven’t used on-screen menus where you should have. One of my favorite two-player strategy games, El-ixir (I-soft, a very small company), uses only one button, to choose one of four options as they appear on the display; because you have under 10 seconds to make your choice, the game gets — and keeps — your attention. In the Apple version of Cytron Masters (SSI), you use one game paddle to control one side of a hectic real-time wargame.
Miscellaneous Elements
Though it’s fun to play a space game as Captain Joe Blow of the U.S.S. Whatever, the game takes on new meaning when you play it as Captain James T. Kirk of the U.S.S. Enterprise. A role-playing game that lets you play a favorite fictional or real-life hero can be a lot of fun. (This is one of the few justifications I can see for licensing, but it can still fail — Mindscape had bad luck with games based on names like Stephen King, Rambo, and James Bond.) A less potent form of role-playing occurs when you play a character made up for the purpose; still, anything that encourages a player to identify with his or her game persona will enrich the playing experience.
Players will feel more comfortable with a game with an environment that can be directly manipulated, one that allows them to mentally link their action to some visible change in the game state. Epyx’s Dragonriders of Pern (licensed from Anne McCaffrey’s science-fiction novels) is an example of what not to do. Not only did I have over a dozen possible moves each turn, I never could establish any direct relationship between my moves and the events that followed. I found it to be a muddied, hopeless experience that I finally gave up on.
I’m a sucker for clever game elements, and here’s one of my favorites: give each player an exclusive advantage to exploit. The resourceful player can rub his or her hands together and say, “With this power, I alone can rule the world! Nothing can stop me now! <hideous cackle>” My favorite example of this occurs in Cosmic Encounter, where each player represents an alien race with one special power. The power allows or forces them to play the game with one rule altered for them alone — how strong each individual counter is in combat, how they draw cards from the deck, and so on. This element also leads to some “cliffhanger” combat scenes and unexpected results.
Bringing Elegance out of Chaos
Yes, that’s the essential task of game design (or any other art form), and it isn’t easy, as you all know. When I see a game I wish I had invented, my first temptation is to say, “Is that all there is to it? I could have done that!” But after trying my hand at several designs, I now realize that a given elegant game was probably the end result of a long trial-and-error process. Just as Thomas Edison tried thousands of materials before coming on the one that made electric lights possible, we should remind ourselves that perseverance, even more than talent, separates the professional from the amateur.
_________________________________________________________________________________________________________
We Are Not Keeping Pace With the Hardware
Chris Crawford
Compare the hardware situation in 1983 with that of today. Four years ago the typical home computer was an Apple II, Atari 800, or Commodore 64 with an eight-bit 1 MHz 6502, 64K RAM, and a floppy disk drive with about 100K of capacity. Today, the typical computer in the home is more likely an IBM PC compatible or a Macintosh, Amiga, or Atari 520ST, boasting a 16-bit processor running at perhaps 8 MHz, at least 512K RAM, and a floppy disk with at least 320K of capacity. In other words, in just four years, overall processor power has increased by perhaps 500%, RAM has increased by 800%, and floppy disk capacity has increased by at least 300%.
One would expect that such dramatic increases in hardware capability would be followed by commensurate increases in the quality of the games that we design. After all, a smaller increase in the power-to-weight ratio produced by the internal combustion engine made possible practical automobiles and airplanes. A smaller increase in the efficiency of steelmaking (the Bessemer process) made structural steel economically viable for architectural use and forever changed the skylines of our cities. Have we game designers used the boon provided to us by the hardware people as effectively as earlier creative people took advantage of their opportunities?
I think not. I think that most computer game designers today are still locked into the 64K gestalt of the Apple II. We still think small. We are like the stodgy architects of the late 19th century who continued to build low, squat buildings when others were building skyscrapers and the Eifel Tower. Even when we design games for big machines, we create little more than 64K games with lots of features tacked onto them.
Consider, for example, the field of computer wargames. This field was well-developed in 1983; has it undergone any revolutions since then? No. My own Patton Versus Rommel, released in late 1986, provides the perfect example of what has happened with computer wargames in the last four years. It is better, yes — the graphics are nicer, the user interface is smoother, and there are more features, but the game represents only a series of refinements on my earlier game Eastern Front (1941), not a revolutionary departure from past practice. And Patton Versus Rommel was one of the more innovative wargames to come along in 1986.
Consider the field of adventure games. The same story applies here. We have seen a steady evolutionary trend. The games have gotten better each year, but they remain 64K games in style and structure. The one bright note that we have seen in this field is provided by the graphics adventures created by ICOM Simulations. (I do not claim that use of graphics is necessary for adventures to advance, only that the pure-text designers have surrendered the initiative to the graphics adventures.)
I think that the problem lies in our attitudes. Partly it is a failure to think in revolutionary terms. A student of scientific revolutions once wrote that such a revolution does not occur until there is a widely perceived need for one, even if all the data is in place to support it. I think that we’re in the same boat. After having survived the Great Crash of 1984, we are all pretty pleased with ourselves that we are alive and breathing.
My own experience illustrates some of the other factors that contribute to the lack of emphasis on keeping up with the hardware. I learned microcomputer programming in the earliest days. I mastered the fine art of scrunching lots of game into a very tiny space. I was proud of my skill. But my current project is designed for a Macintosh with 512K of RAM and 800K of disk capacity, and I for the first time in my career I found myself not worrying about the consumption of resource. In fact, I do not fully utilize the available RAM or disk space. This suggests that I have not yet figured out how to design an honest 512K game. Sure, I could stuff lots of junk onto the disk, but that wouldn’t be the same as designing a true 512K game.
I therefore issue this warning to all computer game designers: you’d better start thinking about the difference between a 64K game and a 512K game. These are different animals. You can’t build a 512K game by tacking a bunch of expensive graphics onto a 64K game. Customers who purchase a computer five times more powerful than a Commodore 64 have a right to expect games that are five times better than what they would get on a Commodore 64. So far, I think that we have failed to meet that expectation.
_________________________________________________________________________________________________________
Salary Survey
Money, money, money. Everybody wonders about it. How much money do game designers make? It’s impossible to say — the information is not available. So it’s up to us to put together our own statistical assessment of the amount of money that we make.
To preserve your anonymity, I have enclosed in the envelope with this Journal a self-addressed postcard. I want you to put just two items of information on the postcard and pop it into the mail. The first item is the percentage of your time that was devoted to designing or programming computer games during calendar 1986. The purpose of this is to address that group of people who work on computer games part-time and hold a “real job” to support them. The second item is your gross income from working on computer games during calendar 1986. Do not subtract business expenses, such as telephone bills, rent, or computer equipment. We all have an idea of how big those can be and can mentally deduct it. It would be appropriate, if you are willing to do so, to subtract any money that was paid out for subcontracting, such as money spent on artwork, sound, and so forth. We don’t want to inflate your apparent salary if all you’re doing is passing the money on to other workers.
Now, each one of us does business differently. The instructions above will work fine for some of you, but there will surely be a good number of people whose special circumstances don’t quite fit the terminology used above. Just use your own judgment and report as accurately as convenient how much money you made during calendar 1986 from your work as a computer game designer or programmer. Do not include income derived from any activity other than the design or programming of computer games.
I will compile the results and report them in the next issue.
_________________________________________________________________________________________________________
Call for Articles
Once again it is time to ask for article submissions. This Journal needs articles, and they have to come from you, the readership. There are a number of types of articles you might submit. A letter is a short piece that presents your reactions to ideas presented in the article. If it’s concise, fair, and to the point, the odds of my printing it are high.
You could submit an opinion piece; Gregg Williams’ “A Fun Game Design Cookbook” is such an article. I warn you, though, an opinion piece must satisfy some tough standards of clarity and precision.
Another possibility is a straight technical piece, such as David Graves’ “Second Generation Adventure Games”. The pitfall to avoid here is overemphasis on narrow technical issues. The focus of this Journal is squarely on design issues. Any technical material must be presented at a high enough level that its expression is not tied to any particular machine or programming language.
Industry issues are always a good subject for an article. These are tricky articles to write, for I will not publish idle grousing or fawning praise about individual publishers. Any such articles should probably be statistical in nature, presenting information about publishers in aggregate.
One class of articles that I would very much like to see traces the design evolution of a genre of games. For this issue I approached six different people, trying to find one person who would write an article on the design evolution of adventure games. Obviously, I was unsuccessful. I myself may someday do such an article on the evolution of computer wargames.
Now for some rules and restrictions on article submissions: first, I like to keep all articles to less than 3,000 words. That’s about 18K characters. This issue, for example, comes out at around 58K characters, so an 18K article is going to eat up one-third of the total space in the Journal! If you need a lot of words, you had better have a lot to say.
Second rule: it MUST be submitted in machine-readable form! I am NOT a typist and I will NOT retype your article for you! There are three ways that you can submit articles to me: 1) a Macintosh disk; 2) BIX mail; or 3) direct download via modem. If you wish to use this third option, submit a hard copy of your article and include your telephone number. I may be signing up for MCI Mail soon, which would create a fourth channel.
Third rule: the deadline for each issue is the fifteenth of the previous month. The deadline for this issue was July 15th; the deadline for next issue will be September 15th.
So get cracking and flood me with lots of great articles!
_________________________________________________________________________________________________________
EndPage: Late Night Ruminations on the Game Designer’s Life
Chris Crawford
I am sometimes told by acquaintances, “Gee, I sure wish I could be a game designer. What fun it must be!” Most of the time I just smile and say, yup, it’s fun. I seldom bother to tell them what it’s really like to design games for a living.
There’s the delight and curse of being in absolute control of my own time. Every aspect of my schedule is under my direct control. The only real time constraint on me is a contractual obligation to deliver a finished game ten or twelve months from signature. Otherwise, I am free. If I don’t feel like working one day, I don’t have to. If in the middle of the day, I feel like taking a long lunch, or just going for a walk, I can. I can take a vacation whenever I want, for as long as I want.
The curse of this is the ever-present sense of responsibility. I cannot take a moment off without feeling some pang of guilt that I am not working my best. The employee can tell himself, ‘I earned this vacation, and I will enjoy it!’ I will never be able to say that to myself; every minute of relaxation is a minute stolen from the project. Under these circumstances, relaxation becomes something that is doled out in carefully rationed amounts. I relax just enough to keep my sanity, just enough to refresh myself for the next round of work. In three years, my longest vacation has been three days in Yosemite.
Another duality of freelancing comes from the creative control it offers. The good side of this is the opportunity it provides for me to do my very best work. I don’t have my efforts watered down by the mediocrity of a large organization. I don’t have to waste my time sitting in meetings, or explaining my decisions to some uncomprehending dork three departments away, or hassling the various bureaucratic problems of The Organization. I am vastly more productive now than at anytime in my life.
But the price I pay for this comes late at night, when I lay awake wondering about the decisions I must make on the morrow. There’s no fatherly boss down the hall to take my uncertainties to. There’s no friendly coworker in the next office to bounce ideas off of. There’s no gang around the water cooler to trade banter with. I’m all alone. The decisions I make weigh on me, and there is nobody to share the burden.
Finances? They’re a roller coaster. Five years ago I had a hit, and I was rich. Three years ago the industry collapsed, and I was poor. Only the fact that we had saved much of the money from the good days saved us. Now I have a hit again, and again I am rich. But who knows when the royalties will dry up? Who knows whether this next game will be a hit or a failure? I save my money and work my butt off, hoping fervently that hard work and talent can stave off bankruptcy. So far, it’s worked.
It’s not fun, not in the way most people imagine. I don’t sit in front of the computer laughing and giggling as I assemble an array of cute tricks to tickle your ribs. It’s hard, grinding work, trying out things that don’t work, then trying more things that don’t work, until finally I try something that does work. I scowl at the screen a lot. Towards the end of every project, I become an ugly person. My temper grows short. I yell at my wife. My body starts to screw up in a dozen ways. I hate the project and I hate myself. My grip on reality weakens. No, it’s not fun.
What is fun is the deep satisfaction that comes from creation. It’s not an immediate sense of gratification I get from putting together some cute bit of code or some nice feature. No, the true joy of this job comes a few months after I have stamped out the last bug in a cold fury of desperate, behind-schedule bug-fixing. I shoot the last disk off with an angry or exhausted cover letter and joyfully turn away from the project that has ruined my life for so long. And then one day months later, a delivery truck comes down my driveway with a box that has my game in it. With trembling fingers I tear open the box and there sits my game. So beautiful it is! I turn the box over and over in my hands, savoring every detail. Inside is the rules manual and the disk. It all looks so wonderful, so professional, so perfect. I mount the box in a frame and proudly hang it on my wall with my other creations. Only then, months after I have finished work on a game, can I appreciate it.
Later still, when I can look back from a distance and see what I have made, I can weigh the creative agony against the joy of creation, and say, “It was worth it.”