Scribd
Upload
151 views3 pages

Avoiding Mistakes As A Game Programmer

This document outlines common mistakes made by game programmers, including: making a bad financial deal that doesn't allow enough time or funding for development; failing to properly back up work which can result in losing all code and assets; and neglecting to advertise a game sufficiently, meaning it may not sell well. It recommends allowing adequate development time and budget, daily backups, advertising one to two months before release, and commenting all code for future reference.

Uploaded by

Patrick Marvin Plagata Villar
Copyright
© Attribution Non-Commercial (BY-NC)
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
151 views3 pages

Avoiding Mistakes As A Game Programmer

This document outlines common mistakes made by game programmers, including: making a bad financial deal that doesn't allow enough time or funding for development; failing to properly back up work which can result in losing all code and assets; and neglecting to advertise a game sufficiently, meaning it may not sell well. It recommends allowing adequate development time and budget, daily backups, advertising one to two months before release, and commenting all code for future reference.

Uploaded by

Patrick Marvin Plagata Villar
Copyright
© Attribution Non-Commercial (BY-NC)
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 3

Avoiding Mistakes as a Game Programmer

By André LaMothe

You can make about 10 billion general mistakes when you write a game and another 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.

Missing Christmas
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!

Read more: http://www.dummies.com/how-to/content/avoiding-mistakes-as-a-game-


programmer.html#ixzz0xJkdz0jM

You might also like

pFad - Phonifier reborn

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy