Chapter 5

Getting Ideas

What makes an idea for a computer game a good one? People can like a game for various reasons -- because they like competition, learning a new skill, problem-solving, exploration, or controlling something's motion, or because they are engaged by the fantasy or beauty of a game's environment. To evaluate an idea for a game, one must estimate the likelihood of turning the idea into an appealing game. This task has two parts: forecasting what will interest people, and judging whether an idea could be implemented as a working program on a particular computer.

Human interest can be sparked by a vast range of topics, but the interactive, visual form of the computer game medium is more suitable for some topics than others. For example, people are interested in other people's looks, and thus arose the art of portraiture in painting and photography. However, it is hard to imagine a satisfactory portrait of a particular person as an interactive computer game. (Hmmm. An interactive portrait -- perhaps the player's input could control the facial expression.) On the other hand, certain aspects of war can be portrayed quite effectively in a computer game. The general's strategic decisions, the map of a developing battle, the pilot's out-the-window view, and the explosion of the falling bombs each have been convincingly depicted in a game. It would seem, barring advances in interactive portraiture, that the computer game medium shows war better than faces. At any rate, some topics have been demonstrated to make interesting computer games, and other topics are still waiting to be explored. One way to prospect for good game ideas is to think about the nature of the interactive computer game.

A computer game is a simulation. The game program models the interactions of distinct entities defined by numerical attributes. For example, many video games simulate physical objects moving and colliding. Pong simulated a bouncing ball. Asteroids simulated a thrusting, turning spaceship. Pole Position simulated a race car and track. Other video games have simulated sports, like football and tennis, and card games, like Blackjack. Adventure games simulate objects in a network of rooms.

The real world offers a vast set of phenomena to stimulate -- animals behaving, plants growing, structures buckling, traffic jamming, snowflakes forming. Any process is a candidate. Every verb in the dictionary suggests an idea. Making a simulation is a process of abstracting -- of selecting which entities and which properties from a complex real phenomena to use in the simulation program. For example, to simulate a bouncing ball, the ball's position is important but its melting point probably isn't. Any model has limitations, and is not a complete representation of reality.

Idea Book

Ideas pop up while you're doing something else. The best way to nurture and ultimately harvest these spontaneous blooms is to write them down. An idea book, built up from scribbled down ideas, is a wonderful resource. It is a granary, a storehouse from which to draw in times of drought.

A good computer game is often based on several ideas that work well together. One idea might specify a metaphor or theme for a game, another might be about a method of displaying objects in the game, and a third idea might be about how input from the player would affect the game's action.

These ideas would not necessarily come to the designer all at the same time. Ideas seem to require a gestation period -- a time of mulling and musing -- before they become workable. Written notes are a good way to make sure no insights are lost along the way.

For a game idea to be feasible, the designer must have a plan for implementing it on a particular computer. A general plan is good enough in the beginning. Such a plan should specify how the entities in the game-simulation will be represented with data, and what routines must be written to perform the simulation. There should be reason to think that this program and its data can fit into the memory space of the target computer, and that the program will be fast enough not to offend human patience. Having settled on an idea, the task of the programmer is to take the idea and turn it into a working program. My starting point is always an idea written down in a few lines on a piece of paper. For example, Figure 5-1 shows my general plan for implementing a graphical adventure game of rooms and movable objects on the Apple II computer. (This software was the foundation on which Rocky's Boots was built.) The plan includes, first, a scheme for organizing data in memory (in this case, for describing rooms and objects), and second, descriptions of routines that will operate on this data.

As a second example, Figure 5-2 shows my notes for the idea of simulating logic gates with adventure game objects. These notes give some idea of how ideas come -- as related thoughts but in no particular order. In contrast, the notes of Figure 5-1 are really an implementation plan, which is the next stage beyond a raw idea. An idea ("Wouldn't it be neat if you could...") often says nothing about how the program to do it would be structured. It is up to the programmer to come up with a plan for implementing his idea.

Not every idea can be implemented. The resources of memory and processing power are limited on every computer, and particularly so on personal computers. Experienced programmers keep the speed and space limits of their computers in mind as they plan. The notes of Figure 5-1 include some timing estimates (in milliseconds) for the two slowest routines.

Figure 5-1

Figure 5-2

As an idea for a program is expanded into an implementation plan, the plan is, because of its brevity, vague or silent regarding many details. A programmer can easily get bogged down in these details (choosing variable names, addressing modes, etc.) if he begins writing the program too soon. A better method is to plan individual routines in the same way as the overall program was planned. The method I have evolved for doing this is to write down some of the major points to consider in short English phrases, and then outline the code to be written in a high-level English-like pseudo-programming language. For example, Figure 5-3 shows the details being worked out for the routine which writes the maze background on the screen, which was the first routine mentioned in the overall plan of Figure 5-l.

Figure 5-3

Once the general structure of the routine has been decided on, the programmer can concentrate on the many decisions to be made as he chooses the individual instructions that make up the routine. These low-level decisions include choosing which machine registers to use, choosing variable names, deciding when to add explanatory comments, choosing addressing modes, and choosing among various coding methods for implementing, for example, loops. Figure 5-4 shows the assembly language program created from the plan of Figure 5-3.

Figure 5-4

Advice to the Game Designer

As computer games rose spectacularly out of obscurity, there was little tradition to guide the designer of new games. Many people offered their opinions about what made a good game. Others moralized about what topics should or should not be addressed by computer games. It was difficult to make sense of all the uproar, and impossible to find any consensus. There were few, if any, agreed-upon principles of computer game design. Nevertheless, it is interesting to survey some of these often-conflicting bits of advice.

Some people offered the opinion that computer games were too violent. Usually in the next breath they added that computer games could more beneficially be used to motivate learning. Most of these people were neither game players nor game designers. They seemed to regard computer games as a powerful, possibly dangerous force, which might, like nuclear energy, be beneficial if it was properly controlled.

When the critics said computer games were too violent, they meant that some computer games simulate violent, war-like acts such as dropping bombs and firing missiles. Disapproving of violence, they disapprove of its depiction, and fear that the young players of video games will fail to see the important distinction between a shoot-'em-up video game and pressing a button that destroys a real city. A revulsion for real violence -- for murder and war -- is sane. But simulated violence is not real violence. The kids in video game arcades know that their actions have no effect outside of those painted boxes.

Does participating in simulated violence give the participant a desire for or an insensitivity to real violence? A question like this is difficult to answer with certainty. All that could be charged is a subtle linkage of games to violence -- we know that kids do not walk, with glazed eyes, from video games to their fathers' gun racks and begin shooting. It might be useful to examine parallel cases. In the play, MacBeth murdered the kind of Scotland. Does Shakespeare's MacBeth breed assassins? A Monopoly player drives his opponents bankrupt. Does Monopoly educate tomorrow's heartless slumlords? The ethics and ideas and situations in fictitious worlds do affect those who enter them. But the effect might as likely be a realization of the awful consequences of an act as the imitation of its perpetrator. In any case, it would be absurd to ban MacBeth to prevent assassination, or to ban Monopoly to promote social justice. The link of video games to violence is equally remote.

Journalists photograph war. Their rationale is passing the truth on to others. Perhaps a complete bomber-game should convey not only the challenge of guiding a bomb to its target, but also the resulting horror of burning cities, vanished civilization, and cessation of life.

Sometimes a cautious publisher, to protect its reputation, can force a game to be modified to purge it of violence, or some other offensive quality. An early version of Rocky's Boots featured the kicking of ducks. Kicking ducks, cute furry little ducks, was considered violent, and violence was bad news for a publisher of educational software for young children. After protesting the absurdity of it, I changed the ducks into alligators, cruel scaly nasty alligators, thus lessening, or at least making more justifiable, the violence of kicking them.

A similar sanitization occurred during the development of Atari 2600 Adventure. The game was conceived as a quest, and so naturally the goal of the quest was to recover the Holy Grail. However, to avoid any possible offense of religious beliefs, the Holy Grail was given the safer name of the "Enchanted Chalice."

In another case, the game Magic Spells taught children spelling by presenting the letters of a word on the screen in scrambled order, and had a vocabulary of 500 spelling words. During a demonstration of educational software for some parents at a certain school, the spelling word "STRAIGHT" was randomly scrambled into "SHITTRAG." The parents were shocked and the teachers mortified. They felt that the program should have detected and censored profane letter-combinations.

Profanity filters have been tried in programs for children. A common practice in text-dialogue games has been to ask the player his name, and insert the name here and there to personalize the dialogue:

What is your name?

DANNY

Good work, DANNY ! ! !

Mischievous 11-year-olds readily conceive the idea of giving a false name, and then giggle with delight when the program says:

Good work, Shithead ! ! !

A profanity filter routine can compare each input string typed in against a list of forbidden words, and refuse to accept profane inputs which it detects. This opened two lines of attack to the kids. The first was to discover the contents of the forbidden word list by trial and error, and the second was to circumvent the detection algorithm by such stratagems as "S-H-I-T-H-E-A-D."

At the same time that they were trying to remove the violence and profanity that might contaminate their children, many people felt that educational computer games were a good thing because the motivation of the video game could be allied with the wise choices of curriculum designers. Educational software could make learning fun! This missed the point. Learning was already fun, and interesting, and challenging. It was school that was boring, forcing children to go and sit in the same place day after day, with a limited variety of activities.

A real merit of using computers in schools, besides the possibilities of learning about computers themselves, was that a computer simulation could bring into the classroom a process that was too dangerous or too inaccessible to bring there otherwise. For example, a car-simulation which modeled carburetor, pistons, distributor, drive shaft, and so on could be used by children to understand how a car works. A real car is more interesting, but it is also greasy, bulky, expensive, and has dangerous electric shocks and spinning rotors. Or again, a real volcano is not suitable for classroom demonstrations.

A computer simulation can also expose the insides of a process, give invisible radiation visible markers, and convert the scale of a phenomenon in space and time to be suitable for human inspection and patience. Our perception of real phenomena can be extended, as if we possessed Superman's x-ray vision.

The designers and players of computer games have always been guided by their own perception of what is interesting and enjoyable, and haven't paid much attention to the ought-to's of the moralists. They prize a quality of a game called "playability" -- being fun to play. A playable game offers the player some interesting choices. The player should be able to improve his performance. A game should have some novelty or innovation to distinguish it from its predecessors. A game should be challenging. A playable game makes it hard for the player to accidentally get stuck in hopeless situations. There should be a means of offering the player variety from one game to the next.

There are several different ways to insure that successive games differ from one another. In action games, the player can't duplicate his actions precisely from one game to the next, so each game is different. A human opponent is unpredictable, and this gives a game variety. Another technique used to achieve variety in a game is to drive game events from a random number generator routine.

Random number generation is like rolling dice. Each roll, a number is produced, by chance, from a range of values -- the range 2 to l2 for a pair of six-sided dice. Simulating a dice roll on a computer is difficult because there are no chance phenomena inside a computer. The output of every program is determined by the input given to it. The best that can be done is to produce a series of numbers that jump around within the given range of numbers, like dice rolls do, and that have no discernible pattern. The output of a random number generator seems unpredictable. Random number algorithms are designed to produce each number in the output range equally often, and to make the values of successive numbers independent of one another. Random number generators produce a flat, patternless, featureless series of numbers.

The use of cards and dice show that the element of chance is important in (non-computer) games. Random number generation provides a similar mechanism in computer games -- an unpredictable automatic selection from among several alternatives. It is worth using sometimes. However, events driven by random numbers have a certain dullness to them. The player has no real hope of discerning any pattern in the events at all, because these algorithms are designed to be devoid of pattern. In the real world, by contrast, events are often unpredictable, but they are controlled by underlying mechanisms which, upon inspection, reveal patterns. (Normally friendly dog attacks -- ah ha! Rabies. Snowstorm in July -- ah ha! Eclipse.) Controlling game creatures with patternless random number routines deprives the player of the joy of discerning patterns and understanding something new.

As an alternative to randomness, the computer game designer has another method at his disposal. Simulation of a complex but consistent environment is a better technique than randomness for achieving variety in a game. For example, in Atari 2600 Adventure the bat moved in straight lines through the complicated network of rooms, occasionally encountering an object that made him change direction. This mechanism gave the bat a very complex behavior. The bat could fly past the player frequently for a while, and then disappear to another part of the game-world, and could even get stuck in a trajectory that repeated until the player interrupted it. This complicated and (somewhat) understandable behavior made the bat interesting. A bat which was randomly injected, once every minute or two, into the room with the player would have been much less interesting. Furthermore, since the player would have been unable to understand, predict, or control the bat's behavior, dealing with a random bat would have been much more frustrating.

It seems to me that simulation is a technique that offers material for designers of both educational games and games made purely for entertainment. Just about any phenomenon that can be named can be simulated. Fighting bull walruses. Snowflakes forming. A bolt of lightning. A moral dilemma. Given a phenomenon to simulate, the problem is to decide what are its parts, how these parts can be represented with numerical values, and what the relationships are that let these parts affect one another. Furthermore, since an interactive graphical simulation is an attractive use of the computer's resources, it is desirable to give the parts of the phenomenon a graphical representation, and to introduce a means for the player to interact with and participate in the phenomenon being simulated. When a graphical simulation faithfully mimics and exposes an inaccessible part of reality, it expands our perception.

---------------------------------------------------