So You Want to Write a Computer Game

from the March/April 1982 issue of Computer Gaming World magazine

by Chris Crawford

You’ve had your computer for some time now. You’ve used it to teach yourself how to program and to handle a few household problems. You’ve also used it to play games. You have noticed that many of the games available for your computer are less than perfect. Soon you begin finding the technical flaws in them, and modifying some of them. The day inevitably comes when you decide that you could have done a better job than the designer. You tell yourself ‘Maybe I should write a computer game.’

There’s certainly plenty of motivation to write a computer game. Perhaps you have heard stories of the fabulous wealth awaiting the designer of a successful game. Perhaps you have read magazine articles about those wild and glamorous fellows who design the games. Or perhaps you are motivated by the simple pleasure of making people happy with your own creativity.

Whatever your reasons you are certainly not alone. More than a million people own personal computers. All over the country, thousands and thousands of people are coming to the same conclusions that you have come to. There is nothing stopping anybody from doing it; you need no special training to design a game, nor any special equipment other than your personal computer. No investment of money is required, nor will you need other people to help you with the programming. You can do it all by yourself in your spare time. It should be easy! Why then, when so many people want to, have so few people been successful designing games? There are four main reasons.

First, the successful game designers work very hard at their games. They are perfectionists who spare no effort in the quest for excellence. They have an eye for detail, putting in fine points that few customers notice. They polish their programs endlessly, rooting out all the bugs to achieve a flawless product. I know a software evaluator, a man of deep insight, who tells me that he can always tell top-notch software submissions from their user manuals; they are always carefully typed and free of spelling errors. Inevitably, the software accompanying such manuals is equally flawless. I have seen many games by amateur designers, some good and some bad, and the only common trait of the bad games was insufficient effort. There is no excuse for a half-finished game.

The second distinguishing trait of successful game designers is their technical expertise. They all are completely comfortable with assembly language and they all know their machines well. 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. I have yet to meet a good game designer who did not have total mastery of the machine on which he worked.

Technical expertise is a means to an end, but technical expertise alone does not qualify anyone to write good games. I know a number of brilliant programmers who have written wretched games. The best game designers are really artists at heart. Their games are an extension of their personalities. These people are intensely creative because they invest so much of themselves into the design process. They disdain copying other people’s ideas, for that would detract from the clarity of their self-expression. My advice to the beginning game designer is similar to the advice a famous writer once gave an aspiring young author: Write a game about what you know, not what you think other people admire — this is the third factor in successful game design. If all you know is ditch-digging, then design a game about ditch-digging. If you put your heart and soul into it, if you condense the human essence of ditch-digging into that game, people will like it. If you only copy an idea somebody else has already used, people will see it for the cheap copy it is.

The fourth factor in success with games is marketing. Don’t try to sell the game yourself; turn it over to a software house for royalties. If you are truly a good programmer then you are almost certainly a poor businessman. Let a good businessman handle the business aspects of the job.

There is, unfortunately, an element of luck in the marketing sector. Three years ago I pounded the pavement trying to sell my games to any of a number of software houses. Nobody was interested. Now I have standing offers from a dozen houses. I haven’t changed that much in three years; what has changed is my reputation. Three years ago I was just another unknown software author. Fame and reputation — these things can be arbitrary. Be patient and make sure your product is good. Keep pounding the pavement and your turn will come.

If you decide to go ahead and write that game, I suggest that you follow these steps:

First, toss the idea around in your head for at least a month before you begin any programming work. Think it through first! Don’t rush in and hack the program together. Make sure you know what you are trying to accomplish before you begin work. Ask yourself, 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. Graphics are assuming increasing importance in all games. Carefully plan the graphics and animation that your program will

use. Pay special attention to the input structure of your program. Most poor programs suffer badly from poor input structures that confuse and frustrate the user. Don’t let your game be ruined by clumsy or overly delicate input systems.

Third, lay out a memory map and stick to it. Decide how much memory your game will take. Less memory may reach a larger audience, but more memory will allow a better game. Allocate specific chunks of memory for specific functions. If any function needs more space, re-evaluate your entire memory map before allocating additional space to the function.

Fourth, develop the algorithms for critical functions of the game. Algorithms are the critical intermediate step between broad goals and specific code. Many beginning programmers leap all too quickly from concept directly into code without taking the time to properly frame their algorithms. If you think that you can write code without thinking out the algorithms behind it then you are either a great deal smarter or a great deal dumber than I.

Fifth, write the program. Are you surprised that writing the program comes so late? Are you surprised that I treat it so perfunctorily? If so, you are in for many more surprises when you do the game, all of them rude.

Sixth, playtest the game several hundred or even a thousand times. Enlist the aid of several friends to playtest it for you, and pay attention to their criticisms. Some of their criticisms will be bad; ignore those. Some will be good; implement them immediately and thank your lucky stars for good playtesters. How do you know the difference between good criticisms and bad ones? I don’t know; if you ever find out, please tell me.

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. Polish is the critical element, the final touch that turns a good game into a shining beauty. I have programmed four computer games now; every single one gives me pangs of guilt because I did not polish it adequately. Don’t repeat my mistakes.

Obviously, the process of designing and developing a computer game is a long and painful one. Now do you see why so few game designers are successful?