I'm getting ready to do a big redesign of the tired old Code Zone website. One of the things that's gonna be retired is the old Game Development Common Sense page. Since I think it still has a buncha valuable advice, I'm not in a hurry to let it disappear completely. Hence, I'm gonna post the entire contents here. That way it'll still have a URL if I want to refer to it again. If you've never read, enjoy!



Introduction

This work is a collection and expansion of various bits of wisdom from The Code Zone Developer Diary. It is meant to be a useful and interesting, but not in any way comprehensive, collection of advice for game developers. While aimed primarily at people starting in the industry, hopefully it will have a couple of useful ideas for professionals.



Design

Don't think that having a great idea is enough.

People who fancy themselves to be game designers because they play tons of games and have hot ideas aren't really sought-out commodities in this industry. Like it or not, the game industry is in the middle of a well-deserved 'correction', to use the stock-market vernacular. Literally thousands of titles are appearing every year, and only a few dozen are making money. To use a movie metaphor, for every Titanic, there are approximately ten Heaven's Gate's.If you plan to get a job in this industry, you'd better be able to do the following, and do it well, because publishers will expect it. . .

• Design a game, and write up a detailed design document that isn't abandoned immediately
• Write the code for the game
• Draw up the bits of art that you didn't/can't hand off to the artist.
• Work with a quality-assurance team to get your game bug-free
• Fix the bugs in the game
• Make changes in the game to match the market and your boss/publisher
• Write the manual for the game
• Submit your game to the proper legal authorities (lawyers, 'Made for MS Windows' seal, etc.)
• Communicate with the artists, so you don't end up with art/box/manual that doesn't fit the 'vision'
• Write an install program
• Drop a completed game on the boss's/publisher's desk that's ready to put on the shelf

If you're deficient in any of these skills, you'd better start working on it. Companies are far more interested in how well you can PUT A PRODUCT ON THE SHELF than how well you can code for DirectX, ModeX, WhateverX.Notice that, of the 11 skills mentioned above, exactly ONE fits the 'have a great idea' category. Sorry, but having a great idea is not enough!

One-man games can still be done, but not huge stuff. Know the limits (not just your limits).

This is something you can see in game development fora. Every other thread is something akin to 'I'm wanting to start writing games. I was planning to start out with'. . .followed by a description of a StarCraft or Quake clone, only bigger in scope.As an analogy, imagine for a second that you are a builder who wants to build something that's uniquely yours, so you decide to build the entire project yourself. No matter how talented and hardworking you are, you cannot build a shopping mall --it's simply too much for a single person. If you're good enough, however, you might be able to build a house. If you do manage to build a house by yourself, that's a feat which deserves respect, even if it's not a shopping mall.If you're planning to do a game by yourself, keep your sights lower than the top-shelf stuff. There can still be plenty of market for your product if you plan well. Large-scale stuff requires the effort of dozens, if not hundreds of people. You can't do all that yourself.

Look outside your genre.

If you're reading this, you're probably an 18-40 year old male, as that's the general profile of game programmers. Interestingly, it's also the intended audience for most of the top-shelf game titles. Computers owners, however, are not all 18-40 year old males. Computers are being used by 12 year-old girls, 60 year-old grandfathers, 30 year-old housewives, and toddlers. If you decide to write only games that you like to play, you might be missing a very good opportunity to sell some games in a more receptive market.Imagine for a second that there was very little variety in available cars --all cars are 4-door sedans. Everybody could drive them, but not everybody would be happy with such a limited choice. Parents with several children would rather have something with more seats. A student might want something smaller with better mileage. A builder might want something that could haul a load of lumber. Unfortunately, there aren't many cars like that, because the engineers design 4-door sedans. After all, that's the kind of car they like.Of course, that's not how things work in the auto industry. Engineers design cars that aren't necessarily made with them in mind.

Take an honest assessment of your skills. Know where you suck and where you're good.

If you can't draw your way out of a paper bag, hire out your art. If you have the grammar skills of a chimp, hire out the documentation or get a proofreader. If you don't have any QA skills, hire someone with QA skills to break your games. Cheesy art, bad grammar, or bugs will make an otherwise professional-looking title look like bad shareware.Conversely, if you're a terrific artist, make your game graphics heavy. If your language skills are top-notch, go for something with a lot of story. If you have a knack for writing stuff with zero bugs, consider writing libraries for other people.

You must follow a strict development methodology.

The computer gaming industry (yea, the entire computer industry in general) is very young, and is dotted with tons of rags-to-riches stories. There are garage startups that made it big (that 'Gates' company that's name escapes me), and there are ones that disappeared (too damn many to mention). One thing that's an absolute necessity if you intend to grow is to abandon the garage mentality. That means adopting formal development methodologies, project management techniques, and accountability for time. You've gotta lose the attitude that following a formal method is betraying your garage-programmer roots in favor of Dilbert-world.Yep, that also means that college is necessary. Kids in the game development fora will insist that college is not necessary to succeed in the computer games industry. Sorry to tell you this, but you're gonna need to know more than good ModeX techniques if you wanna succeed in this business.

Game development is not different!

That's right. Game development is not different from developing financial, database, or text-handling applications. Anyone who tells you otherwise is being too lazy to learn or is being dishonest with himself. Game development requires development plans, design documents, project management, schedules, resource management, design reviews, and all that other stodgy suit-stuff that you thought was irrelevant because you're gonna write games.Once again, the problem is that developing games is the most seductive part of programming. No high-schooler has grand visions of writing the next great financial report generator, and the industry is plagued by folks who think that because they know how to optimize fill-rate, that they're ready to release the Next Big Game. Trivial things like how to write a coherent development plan, how to manage a project, how to write a design document that doesn't become obsolete immediately, and how to schedule are viewed as being much less important than the ability to write code and pitch your grand vision to a publisher.Game development is only art if you don't plan to make any money. If you've got a publisher funding your product or you plan to pitch your product to a publisher, then you're not an artist. The era of 'Hey Mr. Publisher. Gimme a million dollars and I'll give you a great game sometime next year!' died in 1999. Learn to live without it. Programming

Use mature code libraries for as much stuff as possible.

No game developer starts off a game development project planning to write their own operating system, memory manager, window manager, input manager, multitasker, and graphics subsystem for their game. For virtually all of those pieces, programmers choose base OS services that are already written. These services are, for the most part, very well tested, mature, and better than anything you could write. There is, however, no reason why you need to stop your search for services with the ones that the operating system provides. There are lots of good libraries out there to handle high-level graphics, sound, database, and video services. If you can cost-justify buying a library (and you probably can if you budget your time at more than $2 an hour), you probably should.There are several arguments people usually have against purchasing libraries. . .

Using somebody else's library will just make my game look like everyone else's

This is the old 'stock footage' argument. People feel that using libraries for look and feel will drain the 'soul' from their game, just like using stock footage in cheap movies can cause weird lapses in continuity. Remember, though, that computer games are not movies. Consistency between applications make users more comfortable with your product and means that they'll need less time with the manual or the tech-support line.I can probably write something better
Maybe, but can you write something in the time required to justify the cost? For example, you can get a decent 3D scene/graph library for $200 nowadays. If you budgeted your time at an entry-level salary of $15 per hour, that comes to 13 hours of your time. I guarantee that you can't write a decent scene-graph library in 13 hours. Budget your time and figure out the library's worth in hours rather than dollars.

Why should I pay for a library if there are free equivalents out there?

There are several excellent free libraries out there. There are also some group projects that are as stable as a house of cards. If the tech support for your graphics library consists of a mailing list or a group of kids who are supporting the library in their spare time, you probably shouldn't base a mission-critical project on it. If paying for a library obliges the programmer to help you out when your game is crashing, it's easily worth the money.

In short, find a mature library that's got the bugs fixed, and use the heck out of it!

Comment your code as you write it!

You certainly don't have to make your code-weight 50% comments, as is common in college courses, but it is important that you comment the tough spots and interesting bits. Much as you won't want to, you will have to revisit your code later during the coding or debugging process. If you're smart and you comment the trouble spots well, your life will be made much easier later. When I'm in the process of writing something really hairy (like a recursive search routine or a loop several levels deep), I like to pseudocode the whole thing in comments first like this. . .

// loop through every enemy
// first, check to see if a player's bullet has hit the enemy
// if the enemy is hit, remove him from the list
// otherwise, see if he has a bullet available and can see the tank
// if he can, fire the bullet
// check to see if the enemy is at an intersection
// if so, turn or go straight
// finally, update the enemy's position
// and move to the next enemy

Then, write the code to perform each step under the comment. For example, the code above is pseudocode for the enemy-update loop in the game Think Tank. It took about 150 lines of code to actually do all of the stuff mentioned. If the code was written top-to-bottom without a plan, it probably would've been more code and time to do it.Comments not only provide a way to see what you were doing later, they can be used as a planning aid for getting stuff done. They don't increase the ultimate size of the compiled code, so take the time to document your code as you go.

As far as user-interfaces go, just because you can do something doesn't mean you should

Just because you figured out how to write to the title-bar of your window does not mean that you should. Just because you figured out how to launch a URL from your app doesn't mean that you should add your own hotlist-bar. Just because you thought up a really cute control doesn't mean you should use it.If you need a scroll-able field in your game, use a plain old scrollbar rather than an esoteric slider that mimics the look of your game. If you need the user to click something to continue, use a plain old rectangular button. Forcing the user to learn an entirely new user interface right after he's figured out the user-interface of his computer is just rude.As far as interface goes, here are some rules of thumb. . .

• Whenever possible, use native controls (button, scrollbar, checkbox, etc) or controls that mimic the function of the native controls. Users already know how to use 'em, and that'll make it easy.
• If you've got a particular function that doesn't fit with native controls, try to make it as simple as possible. Don't automatically mimic a real-world control (like a round volume knob) thinking it'll be easier. People don't interact with the real world with a keyboard and mouse.
• If you've got an idea for a terrifically cute, yet useless, interface element, and you feel like you're gonna pop if you don't add it, at least give the user the ability to shut it off.
• If it slows things down or is going to cause tech support problems, dump it. It's just not worth it, no matter how cool it is.
• Don't add gratuitous colors and bitmaps to buttons, thinking that it'll make things easier.
• Finally, use words! Your users know how to read. The old adage 'a picture is worth a thousand words' works in some cases, but not all.

Examples of good and bad interface are available at the Interface Hall of Shame.

Publishing

Get on the phone!

Programmers, on the whole, are phone-phobic. They'd much rather do all their correspondence by email or by a mailed submission to the publisher. Unfortunately, though, that's not how most buyers work. If at all possible, try to get a phone-relationship with a buyer before you send in your submission. At best, the buyer will be eagerly expecting your product. At worst, you'll know the legal guidelines for product submission. There is no downside to talking to buyers on the phone.

Don't feel that publishers owe you something

They don't. Just because you made a game that you feel deserves to be on the shelves doesn't mean that publishers are gonna buy it. Publishers use lots of factors in evaluating your game, including timing for the market, requests from the retailers, and requirements for packaging, shelving, and tech-support.Ask the publishers what they're looking for. If you've got grand plans to get your game on the shelves, you must either already have a deal with a publisher, or you must have a game that they want. Never assume that you know what publishers want.

Don't think that just because you sent your product to the parent company that the sub-companies will see it

For example, if you want Origin to look at your game, don't just send it to Electronic Arts and hope it'll filter down to 'em. Many of these companies are merged in name only, and their business units are completely independent. That might require sending multiple product submissions to a company, but it's worth it if it ensures that the right people get your product.

Business

The object of a small business is not necessarily to become a large business

A fine example of this would be my father, who's been working as a manufacturer's rep for about 25 years now. In that time, he's gone from one employee to two employees (around 1980 he added my mom, who handles the orders). He's never gonna be on the cover of Forbes, but he does quite well and enjoys what he does. If you intend to grow, work towards it. If you wanna stay small, work towards that end. Don't assume that you've gotta be big to succeed.

Products are cheap, time is expensive

This is a plague for garage developers, that they budget their time at zero. There have been many times that people have ignored potentially useful hardware or software because they can 'get around' needing to use it. If 'getting around' a useful utility requires that you spend a lot of extra time that is better spent elsewhere, then you probably made a bad decision.The same can be said for computers. If it can justify your time to get a better piece of hardware, get it. A good piece of hardware might look expensive, but if it's reliable and doesn't need to be replaced immediately, it's probably worth getting.On the other hand. . .

Don't go hog-wild just because you got some cash, and don't fall in love with stuff

This is a problem for several high-profile shelf developers. Many companies, often with no successful products on the shelves, decide that they're stars and deserve some great digs and a truckload or chrome and glass. While penthouse offices are cool and look good in magazine articles, they probably aren't the best idea for startups, no matter how well-funded they are. Low-cost office space can be just as productive as high-cost office space if you make things comfortable for the developer.The same can be said for computers. Reliable machines with respectable, but not top-notch, speed are available for very low prices nowadays. Many, if not most of these machines will be quite capable for developing and testing your games. Before you decide to drop $3000 for the best box on the market, consider purchasing some much-needed utilities or books, or spreading the money out over two or three machines. You could then use one machine for graphics/email/documentation and another machine for testing under various OS's and graphic/sound cards.In short, before you decide to drop a pile of cash a chrome and glass penthouse office or the Ultimate Computer of the Universe, figure out if it's really worth the extra cash. If the extra money could be better spent on the purchase of some useful graphics tools, a compiler upgrade, or some books, it might be better to spend the money there.

Don't be unprofessional

Yeah, it's fun to sneak little personal digs, videos, and easter eggs into your code, but it's not professional. The game industry has a well-deserved reputation of being staffed by immature programmers, and that reputation hurts everyone. Developers will be kept on a short leash by publishers and bosses if they're not viewed as trustworthy.Despite appearing to defeat the ad-hoc spirit of hidden tricks, it is important for you to document all of your little undocumented tricks, cheats, and double-entendres for your publisher. If you've got your initials in a texture somewhere, or the 'about' box shows a picture of your girlfriend if you click in a certain spot, let the management know about it. They probably won't mind, but if they do, it's better that you know now before the CD hits the shelves.Needless to say, putting little extras in your game that can get you in legal trouble (like a defamatory image of a person or a picture or sound that's a copyright violation) is just plain stupid and will probably get you or your parent company sued.