Contents
Synthetic Creations
Chris Crawford
An Approach to Plotting for Interactive Fiction
Scott Jarol
Compression Considerations
Rhett Anderson
Observations on Games for 4-8 year olds
Ariel Szczupak
The Self-Publishing Option: Customer Service
Kathleen 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 , through MCI Mail (my username is CCRAWFORD), through the JCGD BBS, or via direct modem. No payments are made for articles. Authors are hereby notified that their submissions may be reprinted in Computer Gaming World.
Back Issues Back issues of the Journal are available. Volume 1 may be purchased only in its entirety; the price is $30. Individual numbers from Volume 2 cost $5 apiece.
Copyright The contents of this Journal are copyright © Chris Crawford 1991.
_________________________________________________________________________________________________________
Synthetic Creations
Chris Crawford
Synthetic Shakespeare
Some years back I saw an article in Scientific American that triggered some thoughts about algorithms. The article was about an experiment that somebody performed with the works of William Shakespeare. They assembled a great deal of Shakespeare’s text in a huge file. Then they built frequency tables for each of the characters in the alphabet. Thus, they found that the letter "e" occurred x% of the time, and the letter "z" occurred y% of the time, and so on for each letter. Since they counted spaces and common grammatical symbols, they ended up with, say, 32 entries in their frequency table.
The next step was to prepare a frequency table for each pair of entries in the first table. Thus, they counted the number of times that the pair "aa" occurred (very rare, that pair), how many times "ab" occurred, and so on through "zz" and the various grammatical symbols. This table would have been 1024 entries long.
Next they prepared a frequency table for triplets, 32K entries long. And then one for quadruplets, one million entries long. Then followed even bigger frequency tables -- I think that they went as high as octuplets, but this would have required a staggering amount of storage space -- one terabyte!
Once all these frequency tables had been built, the researchers were in a position to turn them around. A sequence of random numbers could be used to select letters at random, but the choice of letters would be weighted by the frequency tables. For example, suppose that we have already built the string "bal". We must now choose the next character. Since our string is only three characters long so far, we consult the table of frequencies of quadruplets. We find absolutely zero instances of the strings "balq", "balx", "balz"... but we do find instances of "bala", "balb", "balc", "bald", "bale", "balf", and so on. Thus, we might choose any letter from a through f, but we will surely not choose a q, x, or z.
Note that this technique is not restricted to single words; entire sentences can be built using the method. After all, the end-of-word character (a space) has its own frequency tables. Thus, the substrings "ble", "tion", and "ing" will have a higher frequency of being followed by a space.
The researchers found that strings built by frequency tables using these methods were remarkably "Shakespeare-like". They didn’t make much sense, but they sure had a lot of Elizabethan panache. It reminds me of that hilarious Danny Kaye routine in which he stands up to make a speech at a diplomatic banquet and speaks "synthetic French", stringing together nonsense French-sounding syllables with excited gestures, strong intonation and deep feeling. Remember that the researchers had to use a terabyte of memory to build their frequency tables. Danny Kaye starts to look pretty impressive, doesn’t he?
Synthetic Province Names
So what does this have to do with games? There are a number of applications. I used the method to create random province names for Guns & Butter. Often computer games need to generate lots of names for islands, countries, planets, ships, people, or whatever. Most of the time we simply store a few score names in a big table and then randomly choose names from the table. This works, I suppose, but the procedure described above makes possible better results.
In the case of Guns & Butter, I started off with a list of Mongol and Turkish names. It was easy to get; I hired somebody to type in all the names from a huge index in a scholarly book about Central Asia. At runtime, I read in all the names and build my frequency tables in RAM. I only went as far as letter triplets. This was an easy decision. Quadruplets would have required two megs of RAM for the frequency table. Triplets required only 64K (and this can be reduced if you restrict yourself to just the 26 letters of the alphabet and a space character then the total drops to under 40K.)
With my frequency tables all set up, it was an easy matter to spew out names. The routine for the whole job (reading the file, building the frequency tables, and generating the names) required just 150 lines of Pascal. Piece o’ cake.
How good are the results? All in all, passable. By resorting to an exotic language phoneme, I was able to get away with minor flaws. If real Mongol-speakers were to look at my province names, they would surely gag. But to an English speaker, they have a consistent flavor that seems believable. And in looking at thousands of generated province names, I have noticed only a few duplications. Here are some of the names generated by my algorithm:
Kabinongot, Yushin, Kamangri, Bakirksh, Ogalymamus, Malda, Tuna, Turte, Bogdigizer, Jakset, Murbihuzde, Imuji, Aniboorkha, Vigizirgin, Drot, Shaisakhat, Kerigin, Toqusecbad, Yumyshuksa, Yatoquc, Botoqtambu, Mohi, Tushai, Vogarnis.
This list may seem unnoteworthy. But look closely; it has some impressive traits. First, all the words work; they are all pronounceable. They all have reasonable ratios of consonants to verbs, in roughly the correct relationships. They are all of roughly the correct length. Lastly, they all share a Mongol-Turkish flavor.
I now realize that the algorithm could have been improved by adding reverse frequency calculations. My original algorithm calculated only forward frequencies. That is, if I had the string "bal", I would determine the next character by consulting the frequency table for the string "al?", where "?" denotes one of the 27 characters that I might append to the string. This created a problem with excessively long words; occasionally the algorithm would generate words of unacceptable length. To counter this, I simply cut the algorithm off at ten characters.
A better way would have been to look ahead once the string reached eight characters in length. The improved algorithm would ask, "What three-letter string ending in a space can be matched to the end of the word we are buidling?" In other words, instead of looking for frequency table entries of the form XX?, we look for frequency table entries of the form ?XX. It’s a reverse match instead of a forward match.
An even better algorithm would have given equal weight to the reverse algorithm, with the forward algorithm dominating the first part of the word, the reverse algorithm dominating the end of the word, and the two algorithms gray-merging in the middle.
A small problem arose with the possibility of vulgar, obscene, or racist terms being generated. I had to insert a routine that checked the output against the inclusion of substrings that might be offensive to some of my players. Unfortunately, the list of potentially sensitive substrings is long, and I checked only the most serious. Someday I’ll get an outraged letter...
The use of an exotic language phoneme covered many flaws. I tried to use English countryside place names, and the results were dismal. When "Warwickshire" comes out as "Sharewarckwir", well, it just doesn’t sound right. I didn’t try to do anything with French or German names, but it should have worked.
Generalizing
This scheme need not be restricted to the creation of names. It can be applied to any set of sequences of items chosen from a small set. Music springs to mind. If you treat music as sequences of notes, then you could build frequency tables for all the symphonies of, say, Beethoven, and then spit out "synthesized Beethoven". Exciting as this may sound, it probably won’t work. I spoke with Tod Rundgren about it and he pointed out that the notes are a small part of the total information content of a musical score. Moreover, with multiple notes playing simultaneously, the problem very quickly becomes very complex. According to Tod, such schemes have been tried with little success.
There are other possibilities. Here are some silly ones. The object code of a computer program might provide us with the raw material for "synthetic software" wouldn’t that be fun? Or perhaps we could create "synthetic intelligence" by recording all the moves of an expert player of a game over many playings, building frequency tables, and then synthesizing move sequences.
The concept can be extended into two dimensions to build two-dimensional frequency tables for certain types of images. Perhaps we could synthesize images of a given class from a frequency table. I suspect that for this to work, the images will have to be represented as sequences of constructs at a higher level than mere pixels. A binary frequency table offers no real information content. Visual structures with repetitive elements (maps, for example) can be synthesized if we choose the right kind of "visual atoms" for which to build our frequency tables.
_________________________________________________________________________________________________________
An Approach to Plotting for Interactive Fiction
Scott Jarol
Last time we reviewed the method of dramatic plot analysis developed by Bernard Grebanier. Grebanier created his “Paradigm” as a tool with which to study and to construct plots for stage plays. Another writer and teacher of dramatic writing, Syd Field, has taken an approach to plot analysis and development that reflects his background in the industrial process of filmmaking. Field’s method (as described in his books Screenplay, and The Screenwriter’s Workbook) is even more mechanical and easier to apply than Grebanier’s. While Grebanier’s Proposition centers on the motivational heart of the story, Field maps out the time sequence of the major events that define a well-made movie plot, or more specifically, an American movie plot.
Without condemning less rigidly plotted movies, Field claims that all of the blockbusters, regardless of artistic merit, rely on a simple and easily discernible pattern. He calls his model the “Paradigm” (which of course means “model”).
Field reduces movie plots to primarily three events: Plot Point I, Plot Point II, and the midpoint. He even goes so far in his empirical approach as to graph the Paradigm:
Copyright Syd Field
The Plot Points and Midpoint take place at specific times within the first and second Acts. Field uses the term “Act” in its most basic Aristotelian sense. Act I contains the story’s beginning, Act II, its middle and Act III, its end.
Plot Point I, the culmination of the first act, is the event that sets the story in motion. In movies this is the event that’s usually easiest to identify because it almost always occurs one quarter of the way into the story, at about the end of the first 20 to 30 minutes. The first Plot Point of Star Wars occurs when Luke Skywalker, upon discovering the scorched remains of his Aunt and Uncle, agrees to accompany Obi-Wan Kenobi on his journey to Alderaan. That is the end of Act I. At this point we know what the story is about: a small force of rebels is determined to destroy the evil Empire’s doomsday weapon, and our hero, the son of a mystical warrior, has joined the cause. In the second act we expect to see what he will contribute to the cause of freedom, or more specifically, whether he will successfully help Obi-Wan Kenobi deliver the plans of the Death Star to the rebel forces.
Plot Point I corresponds to the second element of Grebanier’s Proposition, the “cause of the action.” If Grebanier weren’t as concerned that the plot points be expressed as actions performed by the main character upon the second and third characters, he might say that “Luke Skywalker has joined the rebellion.”
In Romeo and Juliet, Plot Point I is the marriage. One problem with Grebanier’s Proposition is that it lumps the remaining seventy-five percent of the story under the ludicrously general label of “The Consequence of the Action.” Of course it is, what else could it be unless it were another story altogether? The only plot element beyond the first act that Grebanier addresses is the Climax. Field’s paradigm, on the other hand, can at least help us identify the events that constitute the larger part of the story.
The writer, director, and editor impose some rigid structural constraints on a modern movie. In a two hour movie, Act I takes up the first thirty minutes, Act II is sixty minutes long, making it half the length of the film, and Act III occupies the last thirty minutes. The last act is usually where the Big Chase takes place because the good guy has already figured out who the bad guy is and now has to catch him. Watch Beverly Hills Cop again and figure out when Eddy Murphy’s character determines that the art dealer is actually a cocaine smuggler, and when he actually begins his assault on his estate.
To account for the action of the play after Plot Point I (we’re going to mix terminology here as we try to synthesize Grebanier’s theories with Field’s) Grebanier introduces the notion of dramatic “Climax.” Syd Field, on the other hand, describes the “turning point” of a screenplay as the “Midpoint.” Grebanier spends a lengthy chapter defining and illustrating the Climax. To paraphrase him: the Climax is what the Main Character does to the Third Character that determines the outcome of the story. Field never refers to the Midpoint as the climax, nor does he define the midpoint in terms of actions of the characters upon each another. Grebanier differentiates between the Climax and the climactic action. Field probably avoids the word “climax” because in the screen industry, climax means frenzied action rather than dramatic importance. So, are Grebanier’s “Climax” and Field’s “Midpoint” synonymous?
In Back to the Future, the event that triggers the main complication falls at a point about one third of the way through the story. That’s when Marty inadvertently rescues George, his father-to-be, from the oncoming car driven by Lorraine’s father. The midpoint is actually where Marty decides that he has to get his parents together at the “Enchantment Under the Sea” dance. In the script, as a matter of fact, he sees the poster announcing the dance on page 69 out of 132. The Midpoint signals the beginning of the unfurling. Field points out that in Chinatown, the Midpoint is when Jack Nicholson’s character, Jake Gittes, figures out the deeper connection between Evelyn Mulwray, Noah Cross, and Hollis Mulwray; from that point on he tries to prove his hunch.
Grebanier wants us to state all the plot points in terms of actions performed by the Main Character on either the Second Character or the Third Character. Back to the Future has five prominent characters: Marty, Doc Brown, George, Lorraine and Biff. The Main Character is easy to identify, but it may be more difficult to pick out the Second and Third Characters.
Doc Brown is the chorus of the story, as in ancient Greek theater. If it weren’t for his presence throughout, Marty’s chief problem would be how to get back to the future. However, in the second act, Marty’s problem is how to repair the historical damage he has done before history rewrites itself without him. The technical problem of re-achieving time travel is left to Doc Brown. Like a fairy-godfather, Doc Brown coaches Marty, explaining to him the consequences of his actions and suggesting solutions.
If we rely on Grebanier, George must be the Second Character. Marty rescues George, the “cause of the action.” This would be a safe bet, since the second act is dominated by Marty’s relationship with George.
Intuitively, we might guess that since this story is essentially a romance, Lorraine must be the Third Character. But Marty doesn’t actually do anything to or with Lorraine until late in the Second Act, when he drives her to the dance. Again, according to Grebanier, the Third Character is someone that the Main Character acts upon in a way that significantly determines the outcome of the story. Character number three must be Biff, who Marty buries beneath a load of manure, which would make that event the Climax.
Clearly, to make Back to the Future conform to Grebanier’s Proposition, we have to pull some shenanigans — like disregarding most of the first and third acts. Field’s Paradigm doesn’t depend as much on the relationships of the characters to define the plot points.
Field’s complete Paradigm actually enumerates five essential events in a movie script:
Copyright Syd Field
Pinch I and Pinch II are the two turning points of the first and second halves of the second act. Another way to look at this is as a recursive definition of plot. Pinches I and II are actually the first and second Plot Points of Act Two. Without Grebanier’s more rigorous character constraints, we can easily express Back to the Future in terms of Field’s Paradigm:
Act I
Plot Point I Marty drives to 1955.
Act II
Pinch I Marty pushes George out of the way of the car.
Mid-Point Marty realizes that his deadline is the dance.
Pinch II Marty accepts Lorraine’s invitation to the dance.
Plot Point II Marty and George make a plan.
Notice the conspicuous flatline in the third act of Field’s graph of the Paradigm. Both authors describe the conclusion of their dramatic models in somewhat ambiguous terms. Obviously, the third act is the portion of the story wherein we should find the resolution to the complication introduced by Plot Point I.
Just like the first two acts, act three needs its own beginning, middle and end. The third act resolves all the problems of this complex story. We could analyze Act III with its own Paradigm:
Act III
Plot Point I George knocks out Biff with a left hook.
Midpoint George kisses Lorraine (accomplishing the objective set by Marty and Doc Brown at the Midpoint of Act II).
Plot Point II Marty, whose birth is now assured, drives the DeLorean back to the future.
Resolution Thanks to George’s triumph over Biff, Marty finds his family transformed into a clan of loving an accomplished individuals.
The third act is a mechanism constructed in the first and second acts, and triggered into motion by Plot Point II.
To express the plot of Back to the Future in terms of Grebanier’s Proposition requires some labor:
1. Condition of the Action: Marty, having traveled to the time of his parents’s adolescence, encounters his father.
2. Cause of the Action: Marty interrupts the event by which his parents met by pushing his father out of the way of an oncoming car.
3. Resulting Action: Will Marty unite George with Lorraine and undo the damage he has caused to history?
The Climax occurs when Marty antagonizes Biff by luring him into the manure truck.
Unfortunately, this approach completely ignores the main story, which is about time travel. The enclosing plot cannot be expressed in terms of the three main characters: No matter how you look at it, Marty’s trip in the DeLorean is a solo flight. So the proposition works for the structure of the second act, the middle hour of the movie, but not for the movie as a whole. A Proposition for the entire movie might look like this:
1. Marty McFly, the son a Milquetoast, realizes that the quality of his life is suffering as a result of his father’s weakness.
2. Marty travels back to 1955 and changes the circumstances of his parents’s first meeting.
3. Will Marty unite his parents, altering his father’s self-esteem in the process?
I doubt that such a contrivance has any value except as an academic exercise with which to prove that the Proposition can be forced to work.
The Midpoint may or may not coincide with the Climax. There are three ways to look for the Midpoint. You can either time it, count pages, or guess. For movies you will need to use the first method, unless you can get a script (which is actually pretty easy). For short stories, page count is not reliable so you’ll have to trust your judgement. The important thing about the Midpoint seems to be that it involves a change in the Main Character’s perspective. In Homer’s Odysseus, the Midpoint occurs when Odysseus forces his way into Hades, anxious to witness the splendor enjoyed by fallen heros. When he arrives there, Agamemnon sets him straight, explaining that death is the great equalizer, and warning him to cherish his life on Earth. From then on, Odysseus seeks safety rather than adventure. Odysseus is a linear plot — Odysseus and his crew face one obstacle after another on their journey home from war — so the Midpoint is also the Climax.
In general, the Midpoint, that is the literal Midpoint as Field describes it, applies only to movies and television — specifically commercial American movies and television. These stories are designed primarily to entertain audiences rather than to enlighten them, and because our tastes are governed largely by our cultural heritage, Hollywood screen productions tend to exhibit a common structure. Also, because screen production in this country is truly an industrial process, requiring the coordinated efforts of hundreds of individuals, standards have emerged which make it possible for each of these people to contribute their expertise according to accepted guidelines and therefore with predictable results.
For either of these methods of plot analysis we could likely find equal numbers of examples and exceptions. Authors usually don’t write from blueprints, so we shouldn’t expect to find neatly spaced studs and rafters in their work. But, though the model may be flawed, each analysis we complete helps us to better understand the mechanics of narrative, which in turn gives us tools by which to judge the quality our own creations.
In Part 3 of this series, we’ll examine how these models of plot construction can be used to fashion a “virtual personality” for the Player Character of an interactive fiction.
_________________________________________________________________________________________________________
Compression Considerations
Rhett Anderson
[Rhett Anderson is a columnist for COMPUTE magazine and a founder of Neandersoft.]
It’s been only a few years since my Computer Science classes at Case Western Reserve and Kent State. I realize that we game programmers aren’t typical (or stereotypical) programmers, but I am still appalled by what I learned and didn’t learn in those classes.
Currently, I am appalled about what I learned and didn’t learn about data compression.
Shockingly, I heard the word “compression” only once, in an algorithms class. I still have the textbook, Data Structures and Algorithms, by Aho, Hopcroft, and Ullman, pusblished in 1983. I don’t mean to pin the blame on these three gentlemen, but they painted Huffman coding as a reasonable method of compression. This may have been true once, but it wasn’t true in 1983. And Huffman coding is even more of an anachronism today.
This may suprise other programmers my age. I’m sure that Huffman coding is still in use. For instance, my contemporaries Tim Midkiff (the other co-founder of Neandersoft) and Tim Victor (currently programming VAXes at Hanna-Barbara) both used Huffman coding in programs at COMPUTE, and they didn’t go to the same colleges I went to. The problem with Huffman coding(or rather, one problem) is that you need to save a table with the compressed data.
Perhaps I’m in danger of stating the obvious, but compression is especially important for game programmers. Compression of graphics and sound data gives you more room for graphics, sounds, and code.
Assuming your decompression code is faster than a floppy drive, it might even raise your game to a higher level of interactivity. That means that even you CD programmers, with your virtually unlimited storage, may benefit from efficient compression.
I recommend the book Text Compression, by Bell, Cleary, and Witten. It’s part of the Prentice Hall Advanced Reference Series. It’s brand-spanking new, published in 1990. Don’t let the title fool you, the book will help more than adventure game programmers. Text compression refers to compression of documents of text. But “document” can be a file, and “text” can be groups of characters of any alphabet, including bytes in the range 0-255. You should be able to find it in the nearest university bookstore. If you can’t, order it from your favorite bookstore. The ISBN number is 0-13-911991-4. Read the whole book — it will plant a lot of seeds in your brain.
This book finally puts Huffman coding in its place. Although the authors think most highly of statistical coding, game programmers will be more interested in dictionary techniques, which include the famous LZ family of encoders used in CompuServe’s GIF format and ARC and related file archivers.The book lists and describes LZ77, LZR, LZSS, LZB, LZH, LZ78, LZW, LZC, LZT, LZMW, LZJ, and LZFG. While there’s no source code to go along with this alphabet soup of methods, a few careful readings of the appropriate chapter will give you all you need to know to write a compression program and a real speed demon of a decompressor. Your compressed data will be significantly smaller than Huffman coded data, and much faster to decompress. For instance, I’m currently decompressing a digitized Amiga screen (320x224, six bitplanes — 53760 bytes), in less than two seconds. I’ve never seen a Huffman decompressor achieve a tenth of this speed. You might find it humorous that my compressor (100% machine language) takes over half an hour, but Tim’s working on one that should take about two minutes to do its job.
I’ve promised not to give away all my trade secrets, but in general, LZ compression works like this: Every item of data in the resulting file is either a byte, or a pointer back to a previous byte. This pointer consists of a distance back into the file and a length. Depending on a flag, the decoder copies a single byte to the destination, or [length] bytes starting at [the current position less the distance]. There are trade-offs involved when you decide the exact format for the flags and pointers. Game programmers should keep in mind that you shouldn’t sacrifice a large amount of speed for a small amount of memory.
Once you have such a powerful tool in your utility belt, you’ll be tempted to use it for all your compression needs. Don’t do it. LZ compression is wonderful, but use your imagination to try to find better ways to compress. Sometimes it’s helpful to sit down with a hex dump of the data you need to compress.
You might want to even graph the data, or write a program to analyze the data in various ways.
Replacing Compression with Construction
As we’ve learned from fractals, a few numbers can produce a screenful of spectacular results. While it is possible to build pictures from fractals, it’s currently impractical for games. We need special silicon for the job, or microprocessors that are faster by several orders of magnitude (I’d like to be proven wrong on this point). But there are cases where your program can generate graphics instead of merely decompressing them. An example would be the computer versions of Dragon’s Lair, where it’s highly unlikely that all the screens of animation are composed of bitmaps. It’s more likely that the animated characters are built up of polygons. Here’s a case where thinking of a bitmap screen as a vector screen let the programmer create a game that would have otherwise been impossible. Chris Crawford has stated in this Journal that the human face can be built piece by piece instead of merely drawn and stored. Be creative.
Digitized sound is tricky to compress. I have used a combination of Fibonacci delta encoding (where approximate differences between successive bytes are stored instead of actual volume data) and LZ encoding to compress 160K of speech down into 60K. But you can do better by coding information about each wave. Whereas graphic data must usually be compressed exactly to be usuable, audio data often must only approximate the original data.
Your graphics data can be several times greater than your code size. You have several choices for compression. You can use a byte-run strategy (like IFF or PC Paintbrush formats) or LZ coding. But you can do even better by remembering that graphics data is two dimensional. It’s not simply a string of bytes, it’s a string of bytes that nearly repeats every n bytes (where n is the number of bytes in a horizontal line of pixels). Hypercard’s author noticed that fact and achieved fantastic compression.
As Always, Think First...And Last
Consider your compression strategies before you write the first routine of your game. Consider them again from time to time as you work. And most importantly, consider them after you’ve finished, so that your next game will be even better.
Since compression is more art than science, compression routines and strategies are closely guarded. But if every programmer strives for better compression, the game player will benefit. And so will we.
_________________________________________________________________________________________________________
Observations on Games for 4-8 year olds
Ariel Szczupak
How this article came to be...
I was helping my kids, 5 & 6, play Sierra’s Holy Grail Quest. At a certain point they had to decide between fighting a duel with the Black Knight in order to free Gawaine (maybe dying in the process), and passing safely, abandoning Gawaine. My kids consulted each other and chose the safe alternative, leaving Gawaine to die
This incident brought into focus many past observations about the special needs of this age group. The sad conclusion was that most computer games I know are boring and/or frustratingly difficult and/or not relevant to the interests and capabilities of this age group.
Most of what I have to say is common knowledge but not common practice. It is addressed to game designers and authors.
I’m not a game author, and don’t plan to be one. I am working on, and investing in, a game design related product. The cash register hasn’t rung yet, so I’m not a ’Game Industry Professional’.
I’m not a child psychologist or an educator. Working with AI, I keep up with cognitive theories & experiments. I get impressive amounts of theoretical and practical input from a teacher specializing in learning disabilities (my wife). I am also involved in educational activities.
I live in Israel, so most of the children I observe do not speak English. The children I’m in contact with are from many backgrounds, not just “computer pro kids”. MS-DOS computers are the most common platform for computer games in Israel. The games available here are a small part of the total industry output.
Bearing in mind all the above, I think what I have to say is relevant but you’ll have to judge for yourselves.
Some very loose definitions
The age group I’m referring to can be called “computer game beginners”. To become a member a child needs the basic knowledge to operate the game and platform, with or without adult help. He also has to show interest in playing a computer game and winning. Having fun watching adults play or playing with the computer as a toy do not count (unless you’re a hardware retailer).
A child stops being a beginner when he reaches a certain maturity, both psychological and physiological, as a game player. That maturity can be more easily observed than defined. I mean the stage when adults watching the child play get these “I’m old” or “(S)he knows what (s)he’s doing” feelings. Total playing autonomy is not a requirement as the child may be still be limited by missing knowledge, language problems, etc.
In my experience this group covers roughly the ages 4 to 8 — and I do mean roughly. Some kids know what they’re doing at 3, others never will and will probably end up being politicians.
When classifying software for that age group, I usually think in terms of educational/creative /game. A game for the purposes of this article basically means it has rules, it has a winning condition and its place in the Grand Scheme of Life is to have fun playing it.
What’s so special about this age group?
The changes in children during this age period are obvious: size, strength, coordination, language (speech, reading and writing), problem solving, knowledge, independence, ego formation, interests etc. These developments, the fast rate of change, and the fact that most game-related abilities are not fully formed, seem to me to be the major game related characteristic of this age group. More, the challenge posed by the games can help these developments.
This seems to pose an insuperable problem: how can you design games for a group with such varying and changing abilities? I hope that the following observations will give you some ideas.
Karate kids
Did you ever stop to think what happens to a keyboard that is used as the input device to an action game? Older children can differentiate between fast and hard. Older children have assimilated concepts such as “delicate equipment” and “responsibility”. The beginners group cannot and have not. They understand “hit the key” literally.
I’m starting with this very prosaic observation because it is symptomatic. In many ways these children are temporary invalids, but some design attention will make them (and their parents) happy.
Most joysticks are sophisticated, ergonomic, solid input devices, but designed for bigger hands. Keyboards are frustrating — they are delicate, most keys are relatively small targets while being tightly grouped, and there are all kinds of strange symbols on the keys (think about what “Enter” means to a 4 or 5 year old.)
Mice are a good input device for these ages. They are small enough, coordinating movement and button pressing is easy, and they are solid enough for the task. They are not ideal, as they offer only a limited range of functions. Using mice involves using the concepts of “left” and “right” (buttons) which are being assimilated at these ages.
I’m not advocating mouse-only games. On the contrary, I think the challenge of using keyboards and joysticks is a positive one. What I am saying is that some thinking is needed. If you design a game with this age group in mind, don’t assign the “blast nasties” function to the space key but use a mouse button with repetitive action when pressed, and don’t assign the pause function to a three level, mouse-controlled, menu but use a key instead. Even better — duplicate functions.
Gift wrapping
How important are colors, graphic resolution, sound, etc? Not very. They add to the overall enjoyment but are not critical to the appeal of the game.
What is very important is richness of details. The details don’t have to be artistic creations, and they don’t have to be part of the actual game play. They just have to be there. Four crudely done but different faces are a better usage of pixels than one digitized face. The details have to be recognizable and namable; abstract patterns or sounds don’t count (“flower” will work, “interlocking triangles” will not). If you have trouble accepting this non-professional claim, get a high resolution puzzle-type game with a built-in construction set and experiment.
Note that gift wrapping is important in getting the game sold in the first place. I’m not advocating using a VGA to put a lot of CGA grade figures on the screen. On the contrary, use the VGA to add a digitized, detailed, background.
Did I pass the test?
The most common error in games especially designed for this age group is that they become IQ tests or training programs. The reasoning behind such designs goes something like: “At the age of X, children develop capability Y. Let’s make a game that will help them develop that capability while having fun.” It’s a good marketing point, but the results are usually disastrous.
Children can make a clear distinction between tasks they have to do, tasks they want to do and tasks they are not allowed to do. Computer games should fall into the “want to” category. When a game is marketed as also being educational, the natural reaction of parents will be to tell the children “this game is good for you” and try to keep track of the child’s progress — making the child think it’s “have to” software.
Even worse, children in this age group try to emulate their elders. The emphasis will move to peer emulation only later. As parents or elder brothers and sisters do not play these games they will get labeled as “have to do this baby stuff”.
Lastly, designing a game with emphasis on a specific capability results in the game having a very short useful life. The changes during this age period are very fast and the time between the “can start playing” and the “holds no challenge” stages is very short.
Such games are also educational/training programs but most of them don’t have score tracking and analysis, focus on weak points, etc. These are features I expect to find in good educational software.
Designing good semi-educational games for this age group is a very difficult task. It can be done, but I’m not sure it’s worth the effort. You don’t have to disguise education in order to make it interesting, so why not concentrate on making good games?
Note that adding animation sequences or using cartoon characters in an educational program does not make it a game. What it does do, is make a richer educational program.
What do you take me for?
Another common error is underestimating the children in this age group. A child cannot use a joystick to roll backwards while firing a laser in 0.1 microseconds or solve Zork I, II and III in 3 hours. It doesn’t mean that (s)he’s an imbecile.
They are constantly pushing themselves forward, trying to emulate grownups. They are aware of some of their limits, but do not accept them. They are expanding their world. They are moving from the small family circle into the larger and frightening Educational System. They are used to challenges. If they are interested in a game, they will try very hard to master it.
On the other hand you can’t just give them adult-level games covering adult interest areas. What you can do (extreme example) is design a candy shop simulation using a stock exchange simulation game engine. Even better, label it as being for ages 10 and above.; they are extremely susceptible to reverse psychology.
The minstrel in the gallery
“Nobody buys adventure games for their stories”. I’m quoting Brian Moriarty (JCGD, Oct 1990). He may be right, as players in this age group do not buy the games they play, but for these children the story is the most important aspect of the game. It doesn’t matter if it’s an adventure, a puzzle or an action game. They take the stories very seriously, to the point where dramatic scenes can cause physiological reactions.
You don’t have to supply a novel-sized story to make them interested. An outline will do, or even enough recognizable and namable graphic elements. They will fill the story in. A game using characters from books or TV series, will make them purr with happiness. So will animated sequences, as they prefer to think in story terms (“He climbed the stairs” vs. “He has to put his left foot there, then ...”).
The important design point is that they have to be able to recognize the story line or the elements from which they can build one. A 50 page printed story is very nice — if the parents will read and explain it to them. A short animated sequence with the character names in block letters will have much more effect.
King Kong vs. Godzilla
Against whom are these children playing? It’s an important question, because if they don’t play to win, the game becomes a toy and different design rules apply.
The children in these ages regard their elders as role models, while they perceive themselves to be incomplete. They like doing what their peers are doing, but will usually prefer cooperation to competition. In fact, peer competition might be the stage where they stop belonging to this group. They don’t understand the concept of personal achievement. They don’t anthropomorphize the computer into an opponent.
In computer game terms, multi-player games will have less appeal than games allowing cooperation between several players. Solitaire games and puzzles have almost no appeal. All this is not true if they see older children or adults play these games, as the games become “I’m growing up” challenges.
So far it may seem that designing games for this group is a losing battle, as a game designer cannot control the environment in which the game is played. But here comes the story teller to the rescue — if the child can experience the game as a story and understand that there is a happy ending vs. several unhappy ones, then (s)he will have a real, internal motive to win the game.
Note that the attraction to stories does not mean that all games for these children should be adventures. All self respecting (ahem...) action games have a story line.
“The Valley of Fear”
Some additional reactions to Brian Moriarty’s observations (Oct 1990 JCGD) when applied to games for children in this age group.
The computer, among other functions, is a storytelling medium for these children, like a TV or a book. That there are cheaper and better media does not really interest them, nor do the price of the game and the effort involved in producing it.
Interactive story-telling is not an Infocom invention. Every story teller knows that young children are suckers for participation in the story development. One of the oldest tricks when telling an on-the-fly story is to let the children interact, giving the story teller time to think ahead.
“People like adventure games they can finish.” The most frustrating computer game experience for a child in this age group is to get interested in the outcome of the game story, only to find out that he cannot reach the happy ending because the game doesn’t allow for his shortcomings as a game player. In this case read it as “Children have to finish games they like”.
“Emphasizing storytelling at the expense of interactivity might make adventure games more accessible to the general public”. Replace “interactivity” with “complex game control” and you get the Golden Rule for designing games of all types for this age group. Right, if you haven’t used your marker yet, this is the time to do it.
This page intentionally left blank
Did you think I assumed it was erased? Or that I can’t see there’s a logical link between the previous page and following one? These are adult questions. A child will not dare question the motives of his Gods. (S)he will assume that (s)he is doing something wrong.
Unnecessary complexity is bad design no matter what the intended audience is. In the case of this age group it becomes critical. The child has to be able to start the game, understand or memorize the controls and be able to concentrate on game playing. So if you can’t determine automatically if it’s a VGA/mouse/MIDI system, at least write a config file after the install instead of asking the same questions over and over.
Assumed guilty until proven innocent
A lot of games cannot be played by this age group because of copy protection. I dislike hard copy protection, but in this case it usually makes the game simpler to operate. The real problem is soft copy protection.
Children in this age group cannot play a game that asks every x minutes for a word out of the manual. They will have problems using codes, coordinates, passwords, etc. They are only starting to understand what a map is. They will have problems reading photocopy-proof text, assuming they can read.
They can find a specific page in the manual. They can choose one picture out of many. They can read (or identify the symbols) in short, block-letter words.
I have to go to the bathroom
Please, please, please: If you want young children to play your game, let them save it even if it’s an action game. It’s not just the physiological problem; they have a need to finish the story and can’t understand why they have to start reading from the beginning each time. They also have short attention spans and cannot spend hours in front of the computer.
I’m the speed king
You may be, but the children in this age group are not. If you want them to ask their parents for more games like the one they just played, let them slow the action parts to speeds they can handle. If it’s a game that appeals also to older children or adults, they will use the slow mode for training, but will try to compete in the faster modes.
The 64K$ question
These children have problems understanding large numbers. Scores in the million and billion range confuse them. They prefer single or double digit scores. Help stop inflation.
They love complex scoring - “I may be slower than you, Dad, but I’m a better person”. They can understand symbolic or qualitative scoring better than numerical or quantitative scoring.
Conclusive hint
If you will stop to think about these commonly known observations, you may find that it doesn’t take that much effort or investment to make your teen-ager or adult game attractive to, and playable by, young children. a
_________________________________________________________________________________________________________
The Self-Publishing Option: Customer Service
Kathleen Crawford
As one changes from author to self-publisher there are many choices that must be made. One of those is how to handle customer service. While you might think that the box art and advertising are much more important, your decisions about customer service can have long-term positive or negative financial implications for your business. Your decisions in this area must be carefully considered. In this article, I will discuss the reasons for and the options available for customer service. Future articles will discuss setting up customer service, opportunities to make customer service a profit center, and the day to day operations of a customer service department.
Why have customer service? Because you have to! First, customers, retailers and distributors expect that there be a phone number to call for problems and questions. Not having a customer service line means that customers with problems will go back to the retailer for help (or exchange) resulting in product returns or bad customer relations The retailers will then turn to the distributors and finally to you with returns or complaints. Second, customer service gives you valuable feedback with which to improve or enhance the product. Third and most important, your master distributor will probably insist on some support.
Before you can decide which option to choose, you must decide how much basic support the product will require. You must take an objective look at each version of the product and decide how much support it will require. It may not surprise some of you that Chris claimed that the Mac version of Balance of the Planet was perfectly bug-free and would require no support. And in fact, we have not had one complaint about bugs or problems with the Mac version; but that does not mean that we have had no calls. There was the guy with the 16-color display who wondered why his colors did not match the screen shots on the box. There are people who lose the installation card or don’t read the installation card. There are people who get bad disks. The disk duplicators say that less than 1% of the disks will be bad. If the game sells 25000 units, that’s still 250 calls.
The IBM world is even more complex. In addition to the kinds of calls mentioned above, there are all of the compatibility issues in the IBM world. Have you really tested the product on every clone with every option of mouse, sound, graphics, and applications? Of course not -- that would be impossible. You must be prepared for calls about compatibility issues. For every 1000 units sold you can expect from 10 to 150 calls. You must guess what that number will be.
After you have decided how many calls you expect, there are four basic options you can use to cover customer service: cover the calls yourself, pay your master distributor to do it for you, find a third party service to cover for you, or set up a customer service department to handle the calls. Each of these has advantages and disadvantages.
Do It Yourself
Covering customer service yourself is the cheapest way to go. You publish your phone number and the hours that you will answer the phone on the warranty card. This option would have worked for Mac Balance of the Planet because we have received less than 4 calls per 1000 units. However the intangible costs can be disconcerting. Remember, you are publishing your personal phone number in every box. Our customer service line has gotten calls at 6AM Sunday morning and 11PM on a weeknight. One call came in just as we were sitting down to Christmas dinner with our family. Random calls disrupt a programmer’s thought process. If you get very few calls, you could save a bunch of money doing it yourself; a great many calls could seriously disrupt work on future projects.
Master Distributor
Paying your master distributor to handle customer service is simple and convenient. Our contract does not allow me to say how much our master distributer would have charged us, but I can assure you that it was not cheap. Let’s say that the master distributor charges you 75¢ per unit sold to handle customer service. If you sell 20,000 units, you will pay the master distributor $15,000 to handle customer service. That’s a lot of money. And what do you get for it? How do you know that customer service is handled properly?
And what about the warranty cards? Do they go into the master distributor’s data base or are they sent to you? If they are sent to you, how do the customer service people know who they are helping?
Third-party services
The next option (finding a service that would learn the product, handle the calls, and create the warranty card database) looked most attractive to me. I expected some sort of per-call charge, so that the more calls the service received, the more it would cost. The problem is that I could not find such a service. Most such services charge a fixed rate. Maybe the numbers just don’t add up. Maybe I will run the numbers and set up that business myself it seems like too good an idea to let slip away.
In-House Customer Service Department
The last option is the most difficult. Setting up a customer service department has a lot of advantages and huge risks. The advantages are complete control and lots of feedback. You can create databases of your customers, databases of your types of calls and monitor the sell-through of the product on a daily basis if you want. You decide how to handle different types of problems. You can make customer service a selling point for your company. You can even survey your customer base for new products or services. The only risk is money and time. You have to hire people, manage them, pay them, rent office space, and hook up phones. It can be worth the effort but it can lock you into leases and payroll. I will discuss this last option in more detail in the next article in this series.
_________________________________________________________________________________________________________
My First Computer Game
Chris Crawford
My first computer game was a tactical armored combat game. I wrote it in FORTRAN on an IBM 1130. That machine had 16K of RAM and hard disk packs that provided lots of virtual memory. I/O consisted of a Selectric teletypewriter. You booted the machine with the appropriate hard disk in much the same way that you now boot older PCs with a floppy disk -- except these disk packs were 18 inches in diameter and weighed four pounds. The machine itself was the size of a large desk.
I had a set of maps from the Avalon-Hill game Panzer Leader and some lead miniatures of tanks. I placed these on a table next to the computer. The computer would print out coordinates of events and I would move the tanks around the map to reflect the changes dictated by the computer. Then I would enter my own moves according to a precise input format.
The game had a data structure for the map in RAM, and it could figure its way through a hexgrid. It had primitive fog of war, with hidden units maneuvering behind ridges and forests, then surprising the enemy with sudden attacks. It may surprise you that I was able to get so much function into so little space, but remember that most of the RAM consumption of a computer game goes for graphics, sound, and user interface. I didn’t have any of that in this game, just the raw game, so I could get a lot of game into that small space.
The AI wasn’t very good -- I had to give it a 2:1 superiority, but that was enough. I can still recall the intense excitement I felt when the computer, having routed me from a defensive position, pursued my beaten forces all the way across the map.
I started working on the game in May of 1976 and got it running in September (this was all part-time work; I was teaching physics at a community college in Nebraska at the time.) I tuned it during the fall and introduced it to the world in December of 1976. I set up a wargame convention at the college during Christmas break -- I called it Wargy I and invited the thirty or so attendees to come on up to the computer room for a game against the computer. This was novel stuff for 1976, and they seemed impressed with the experience. The computer stomped several of them easily.
_________________________________________________________________________________________________________
