Game Design

Game design is the work of deciding what a game asks of its player and what it gives back. The 1982-97 sources here are designers describing their own method: Chris Crawford’s advice to beginners and his revision of it two years later, a 1984 designers’ panel, Sid Meier on picking the player’s role, and Shigeru Miyamoto on the idea he says he has never moved past.

Fast facts

Crawford’s four reasons so few succeed (1982): effort, technical mastery, writing about what you know, and leaving the selling to a publisher.
His procedure: think for a month; plan the I/O; lay out a memory map; work out the algorithms; then write the program; playtest “several hundred or even a thousand times”; polish, polish, and polish for another month.
Meier’s test (1989): give the player “the most interesting things to do” — the pilot, not the mechanic.
Miyamoto’s constant (1997): “to create some kind of ‘miniature garden’”.
Crawford’s slogan (1984): “People, not Things!”

Four reasons so few succeed

In March 1982 Computer Gaming World printed “So You Want to Write a Computer Game” by Chris Crawford, then an Atari employee. Anyone could try: “you need no special training to design a game, nor any special equipment other than your personal computer.” Yet few succeeded, and he gave four reasons.

The first was effort. Among the amateur games he had seen, “the only common trait of the bad games was insufficient effort. There is no excuse for a half-finished game.” The second was technique, in the line the article is remembered for:

No great paintings were ever painted with crayons; no great symphonies were ever composed with kazoos; do you really think that you can write a great program in BASIC? I have yet to see an excellent program written in BASIC.

The third was that technique was not enough: “I know a number of brilliant programmers who have written wretched games. The best game designers are really artists at heart.” His advice was to “write a game about what you know, not what you think other people admire”. The fourth was marketing — “Don’t try to sell the game yourself; turn it over to a software house for royalties.”

The procedure he set out puts programming fifth. “First, toss the idea around in your head for at least a month before you begin any programming work”, asking “what will people feel as they play my game? What will the game teach them? How will it challenge them?” Second, “plan the game I/O before anything else. I/O is the big bottleneck in all games; it dictates what can and cannot be done.” Third, “lay out a memory map and stick to it.” Fourth, the algorithms, “the critical intermediate step between broad goals and specific code.” Then: “Fifth, write the program. Are you surprised that writing the program comes so late?” Sixth, “playtest the game several hundred or even a thousand times.” And:

Seventh, polish the game. Eighth, polish it some more. And finally, when you are truly and deeply sick of the game and desperate to get it out of your hair, polish it for at least another month.

Two years on

Crawford revisited the article in March 1984, by then heading “a game design/research group at Atari”: “The eternal truths of 1981 are the outdated misconceptions of 1984.” Some advice stood. “Assembly language is still the only development language for serious game designers”, and polish mattered more, not less: “Games like M.U.L.E. raise the stakes for everybody; the market will no longer tolerate slipshod design or lack of polish.”

Originality had become a demand rather than a plea. “The most foolish thing you could do right now is attempt to sell another PAC-MAN, SPACE INVADERS, or DEFENDER rip-off. People are utterly sick and tired of that stuff.” The biggest change was the size of the job. “The 48K disk-based game is finally the standard”, and with it the team:

Two years ago, the individual reigned supreme. The tight coding requirement of games for 16K machines gave the individual a great advantage over the team. But the demand for bigger games has made it more difficult for the individual to keep up. More and more, we are seeing software produced by teams. Richard Garriott, Dan Bunten, and Jon Freeman are examples of notable game designers who are really team leaders rather than lonely individuals.

He called it “a transition from a cottage industry to the big-time.”

“People, not Things!”

At Origins 84 Computer Gaming World put Dan Bunten, Mike Cullum of Avalon Hill, Sid Meier, Crawford, Roe Adams, Robert Woodhead of Sir-Tech and Richard Garriott on one panel. Asked which machines they targeted, Bunten answered for the trade: “We are answering according to what makes good business sense. If you are going to stay in this industry you have to respond to the market.”

Asked where strategy games were going, Crawford named the problem as an “unnecessary polarization” between “the fast paced shoot-’em-up game and the strategy game”, and the answer as “the social element inside the game”:

Games right now concentrate on ‘things’. My slogan is ‘People, not Things!’ […] We need to put characters, REAL characters, not just something with a certain number of hit points associated with it.

Adams put the same gap another way: “There is no real Dungeon Master in the game; no feeling of human unpredictability.” Woodhead listed the constraints the designer worked inside — “the speed of the computer, the amount of RAM, and the amount of disk space you have available” — and expected expert systems to supply characters “in about three years.”

Interesting decisions

Sid Meier described his method to Compute!’s Gazette in March 1989. The first choice is the player’s role: “We look for an approach that gives the player the most interesting things to do. In an airplane simulation, that’s pretty straightforward. It’s not the mechanic, it’s not the guy who designed the plane, it’s not the guy back at headquarters telling them where to fly. It’s the pilot who has the most interesting job.” For F-19 Stealth Fighter that meant a lone aircraft: “We try to pick situations where one player is the hero and has all the interesting decisions to make.”

The questions that follow are about the situation, not the hardware being simulated: “What’s really out there? What decisions does that person have to make? What technical tools are available? What problems have to be faced, and what’s creating all these problems?” And last, “Is this going to be a neat game? If a situation is too mechanical or too one-sided, it isn’t much of a challenge or a game.” Fidelity is filtered to serve that: “We’re not interested in manifold temperatures or trying to simulate the nuts and bolts of the F-19”, but “a filtered, enhanced version of reality […] real enough so you don[’t] feel you’re just playing some silly game.”

The miniature garden

Asked by Edge in January 1997 whether games had improved or only their graphics, Shigeru Miyamoto answered that his own idea had not moved: “My basic policy of making games is to create some kind of ‘miniature garden’ - and this concept has remained the same for me. But regardless of how much technology improves, it will never catch up with my original concept”. Asked whether he had become a better game creator: “Sometimes I have to realise that I am merely repeating what I did ten years ago.” The same concept underlay both his series — “when we started on the original Zelda and Super Mario Bros., we had the same kind of concepts for each game” — and he described the console itself as “a computer-like toy” that “shouldn’t be used for just one thing.”

What the player takes away

A Computer Gaming World editorial of May 1990 reported Will Wright, asked what he most wanted people to learn from SimCity: “I just hope that they’ll think about their own cities differently. Maybe, they’ll take more interest in the whole process.” The editorial’s gloss: “As the metaphors of a game take hold, they change the player’s way of viewing the situations and events outside hi[m]/herself.”

The craft of creating play