Chapter 17. Scram

Before I became a professional game designer, I was a "Mr. Science." I went to high schools all over the state of California, putting on shows about energy policy issues for entire student bodies. After each show, I'd go into classrooms and talk to students about energy policy. To improve my classroom presentations, I wrote two little simulations on my computer: One simulated energy policy decisions and later became Energy Czar, and the other simulated nuclear power plant operations. When I started working at Atari on the Home Computer System (HCS), the marketing people were eager for educational software, so I wrote Energy Czar. Since they were eager for more, I set to work adapting my nuclear power plant simulator to the Atari.

The original simulation did nothing more than figure out the heat flow through the plant. It used simple physics equations to calculate the temperatures at various locations inside the plant and presented all the numerical results in a big, dense display crowded with numbers. As a physicist, I appreciated having all the numbers at my fingertips, but my boss, Dale Yocum, took one look at that screen and said, "We have to work on the user interface." The task was clear: convert a screenful of numbers into a pretty picture of the nuclear power plant, using just a few numbers as labels at critical points. Moreover, I had only four colors to work with, including background. I was able to add a few more colors by clever use of player-missile graphics (see Figure 17.1).

17.1. Scram screen.

With Scram I committed the most common error in game design: I used the display as the foundation of the design. Most beginning game designers make this mistake, and I was a beginner back then. It's easy to understand how we fall into this error. When struggling with a new task, the mind gropes for some solid foundation on which to build, and most beginning designers think of a computer game in terms of the visuals rather than the play.

This problem is so simple, and yet so fundamental, that it deserves some elaboration. Here's an experiment to try: Ask somebody to point to their computer. Odds are they will point to the monitor, not the CPU. The monitor is, after all, the locus of their attention during the interaction of playing the game; it is the primary sensory manifestation of the game. Yet the monitor is only a peripheral. The computer itself is a flat, square chunk of plastic and silicon buried deep inside the box. Ask a child to point toward himself, and he will respond by pointing toward his approximate center of mass his chest. Ask an adult the same question and you'll see a finger pointing at a face the face we present to the world.

LESSON 37

Design your games as play experiences, not visual experiences.

What's so wrong with this mental fixation is its failure to appreciate what's important about computers they compute! A computer is NOT an image-generation device; it is an interactivity device. A game is not a sequence of pictures; it's an interactive process. What we see on the screen is not the substance of what we get from the computer; it is only the visual expression of the deeper, more subtle process that we seek when we turn on the computer.

It is therefore a mistake to design a game by first sketching out the screen display. That screen display is a vital component of the game, but it is not the essence of the play experience. The starting point of game design must be the nature of the play experience, not the visual experience.