First Make It Right, Then Make It Fast
When you write a routine that needs to be blindingly fast, the first step is to get it working; then think about speeding it up. It doesn’t matter how fast your routine runs if it doesn’t do what you want: Reliability is not an add-on feature, but speed can be. The same considerations apply to squeezing a big program into a small space. If you have plenty of memory space for your program and you need speed, you can unroll loops (duplicate the code inside the loop the specified number of times) and use precomputed data. On the other hand, you can generate data “on the fly.” if you have plenty of compute time and need space.
Fail Fast (If Ever)
Tackle the hardest part of your program first and test it thoroughly before going on to the easy parts. This way you’ll know as soon as possible if your idea has some fatal flaw. For example, your entire concept might be unworkable because it takes too much memory or runs too slowly. It’s very discouraging to get all the easy stuff done just right and then discover that the “hard part” is really the “impossible part.”
Top Down and Bottom Up
Write your programs “from the top down” and “from the bottom up.” First decide what results you want and work backwards to figure out what you have to do to get them (“top down”). You may then discover that you can’t do exactly what you had in mind. but you might do something even more interesting if you’re willing to change your final goal (“bottom up”). Repeat the cycle until you reach results you’re happy with.
Sound Is Your Secret Weapon
Your game’s sound is as important as its graphics. (If you don’t believe this just try plugging your ears at a Star Wars film!) Everything that happens in your game should have its own characteristic sound. Sounds and music can set the atmosphere and make the exciting parts more involving! Plan the sounds early—don’t leave them for the last minute or the last 100 bytes.
Keep Your Sense of Humor
Video games are real-time entertainment, just as movies and the theater are. Performing artists learned long ago that if you constantly try to evoke a single reaction or emotion, people will tire quickly and stop paying attention. If the game is a tense shoot-em-up, you’ll need some comic relief from time to time. Don’t be afraid to be cute. On the other hand, if the game is a funny cartoon, you’ll need touching moments. A little contrast can heighten any illusion.
Make It Real
If you involve real-world physical principles in the design of your game, the unconscious cues from an accurate model of the universe will make the game much more realistic. On the other hand, it’s vitally important to make the game work on the gut level. If the physics doesn’t feel right. you might l have to compromise between the “real” way and the “fun” way in order to make the game exciting to play. In one of our games, we simulated the flight of an airplane and found a realistic plane is boring to fly. But before we could fix the problem, we needed to understand the physics involved to know what (and how) to compromise. Once we looked closely at the physics we discovered ways to make it even more exciting than we had hoped. And, of course, we were careful to make our new system consistent, simple and believable.
Make It Hard
Games need to be hard to be challenging, but the hard parts should be fun rather than frustrating. Don’t make the game difficult by making the controls difficult to use or the gameplay arbitrary; instead make the game difficult by making the tasks heroic. “I finally collected all 99 treasures!” is a lot more rewarding than “I finally got the joystick to work!”
Make It Easy
The program should be as easy to write, debug and modify as possible. Your time and patience are important commodities, so use the highest-level language you can get away with. If the program will work fine in BASIC, C or Pascal, then don’t bother with Assembly Language. Even if you need to use Assembly Language, it is often easier and faster to program the game in a high level language first, try out variations and improvements until you have it right, and then recode it in Assembler.
Make It Perfect
There is no detail too insignificant to merit careful attention in a high-quality game. People will spend hours and hours playing a good game, paying intense attention to it. If you took a quick-and-dirty approach, it will show. Glaringly. Make the universe of the game rich and detailed, defining it beyond the game itself. We have a friend who makes wonderful movies, and one of the reasons they’re so good is that he treats every little detail as if the fate of the whole movie depends on it . . . and he’s right, of course.
Don’t Be Afraid to Break the Rules
Rules are a way to say what is usually true. But if you understand what the rule is based on. then you will know when you can break it. For instance, the rule “point-of-view games don’t work” never sounded quite right to us.We think that what the rule is saying is there usually isn’t enough information (visual and audio) available for people to know what’s happening without some other help (like seeing yourself from be’ hind). So we provide better information and our point-of-view games are like being there!
One or Two More Things . . .
In addition to our ten tips, there are two things you’ve probably heard countless times. (This is probably because they are true!) The first is to make a backup of your source code before you make any changes in your working program. Keep copies of your last two or three working versions so you always have the option of undoing a change that didn’t go too well. The second is to document your program. You will read your source code 50 times for every time you change it. Taking a little time to write an explanation next to each section code will save a lot of time later. These two really aren’t tips at all; think of them as laws. And, oh yes—the most important tip—never type your program while taking a bath or shower. . . .