Avoiding Mistakes as a Game Programmer
You can make about 10 billion general mistakes when you write a game and an other 100 billion technical mistakes. Here are some common mistakes that span the spectrum of game development.
Making a bad deal
(If you’re writing, financing, distributing, marketing, selling, and testing your game in-house, this particular advice doesn’t apply to you.)
Chances are good that you’re going to involve one or more other parties in the development of your game. Maybe another party is going to finance it or distribute it. Regardless, don’t let yourself be exploited. This is easier said than done, but in the end, a bad deal makes everyone unhappy.
If your game is going to take 15 months to make, then you need 15 months; that’s all there is to it. If you need $50,000 or $1.5 million, then that’s what you need. If you make the game in a shorter time frame or for less money, it’s guaranteed that the game will be awful, it won’t sell, and everyone will point their fingers at you! So when you make any kind of financial deal — marketing, sales, or distribution — make a good deal or you’ll be sorry!
As a rule, a 2-D game takes between six and nine months to complete and costs about $100,000 for commercial-level quality. A 3-D game has an unlimited upper boundary, but 15 months and $750,000 is the absolute lower limit for any quality game.
Forgetting to back up your work
You have 1 million lines of C++ code in 50 modules, and it’s all sitting on one hard drive. You worked on it for 6 months and — bang — there’s a fire, a robbery, a crazy one-time significant other, or a hard drive crash that destroys it all. Although the probability of these events happening is slim (except maybe for the one involving the crazy former significant other), one in a million is still too much of a chance for you to sleep peacefully. So make sure that you back up your work daily onto tape, Iomega ZIP disk, CD-ROM, or a remote server.
If you’re going to write a game that is going to be released any time during the latter part of the year, don’t miss Christmas. Your best bet is to have the game finished by October or November at the very latest. If the game is shareware, the time of release isn’t that important. However, people always seem to be in more of a spending mood around the holidays, so don’t shoot for Arbor Day or some other less-than-profitable time.
Failing to test properly
You’ve just written a killer game, and it works great on your computer. Well, so what? You had better test it on a number of different machines — and let other people test it, as well — because you’re probably (unconsciously) too easy on your game when you test it.
If you make a game that has one single problem, people will blow it out of proportion. A single pixel out of place turns into “a bad video driver” on the Internet within 24 hours. Therefore, make sure that you beta test your game on a number of machines with different configurations. If you don’t have access to 20 to 30 computers (like anyone does), then take your game on a disk or CD to the nearest computer store and try the game out on their computers. If someone asks you what you’re doing, just tell them that you’re thinking of buying some computers, and you want to see if this game is compatible — unless, of course, you want to use this response: “I’m a store shopper. If you play your cards right, I won’t write you up.”
If you don’t like pretending to be James Bond, a local school’s computer science lab will probably allow you to try your game during off-peak hours. But pretending to be James Bond — or Jane Bond — is more fun.
Using old technology
We’re not all millionaires, but using old technology and old ways doesn’t pay. Try to keep up-to-date as much as possible. Even if you can’t afford to get the latest C/C++ compiler or the best 3-D modeler, at least you know that they exist. Maybe you can ask the company for a demo version or an evaluation unit. However, all excuses aside, game development is a high-tech business, and you have to be as up-to-date as possible.
Writing for DOS
DOS is so dead; it has been dead for ages. Game programmers used it because a better alternative wasn’t available. If you’re reading this article, you know that Win32 with DirectX is better. If you are making a professional game, don’t even bother writing for DOS. However, if you’re creating a shareware game and you want to use a simple design, then DOS is okay. DOS is good for learning purposes but, if you can, write for Windows. If you want to make a DOS version for older computers, feel free — but Windows has been better for game programming since DirectX came into the picture.
Lying to the public
The public is brutal. One minute they love you and see all your movies; the next, all the work you can get is in an ad for chewing gum. Don’t lie — exaggerate, but don’t lie. Better to hold back and blow the socks off the public and the critics than to hype your game to the point that everyone’s expectations are too high, and they’re going to be let down.
Neglecting to advertise
If you’re a former employee of Atari, please read this carefully: Products do not sell themselves. If you want your game to sell, you need to advertise in some fashion. If you’re marketing the game yourself, set up a simple Web site and get some interest going. When you’re about one to two months from release, start sending out betas to game sites. When you’re finally ready to release your game, go all out. Upload it to hundreds of sites manually or with an Internet spider or bot to put the game all over the place and at least let people know that it exists.
Allowing too many cooks in the kitchen
For some jobs, more is not better. When you need help from others, don’t involve too many people. Don’t add people to the project because they’re friends or they think game development is cool. Only bring in talented, dedicated people whom you trust and who want to work on the project. And the fewer people working on game code, the better the game will be.
Omitting comments in your code
Working with code that’s insufficiently commented is a nightmare. Comment your game code with at least one comment per line. Hardly anyone can program as fast as he or she can type for any sustained period, which means that you always have time to add comments. And if you ever want to license or make a new version of your game, you won’t need a Vulcan interpreter to figure out what you were doing with the original code!