The Good

When I accepted my first job in the computer game industry, my second choice was a job with American General Life Insurance. They wore ties. Their employees took drug tests. For that I would have the distinct privilege of working on a Beta version of Microsoft's C++ compiler, programming little sales tools for insurance agents. Did I make the right decision or what?

Face it; there aren't many exciting programming jobs out there. The cool jobs fall into a few categories: jobs you can't talk about, ultra high budget simulations and control software, and games. Everything else falls quickly into the "Did you put a cover sheet on your TPS report?" category.

The Job

Here's my bottom line: It's cool to work on games. Games are as much art as they are science. I think that blending both halves of your brain on the job is immensely satisfying. Let's assume you are working on a difficult path finding algorithm. Path finding is well researched, but your implementation of it requires analytical thinking to apply the published solution with the particulars of your game. Once you get it working you may discover that it isn't aesthetically pleasing. Your algorithm might be technically correct but simply "look" wrong. It's up to you to tweak it, like an artist tweaks a background that is a little too dark.

It's great to take a game design discussion with you to lunch. You can have a heated debate on whether the master zombie characters come from outer space or originated here on earth—the result of some tragic experiment. You get the weirdest looks, as someone screams, "Damn it, everyone knows that it's better for the zombies to come from space!" I have the most fun coding, especially when things are going well. Game code is usually pretty difficult stuff, and you frequently have to break some new ground here and there. This is especially true when you are playing with new hardware like the latest video cards. It's also true when you figure out how to implement a customized version of a classic algorithm, so that it runs fast enough to be in a game instead of a textbook.

Probably the best part of game coding is starting from scratch and allowing everything in your libraries to be refreshed and rewritten if necessary. At the end of a project you can't make drastic changes, and you are forced to live with some annoying hacks and hastily designed objects. When the project is done and you are starting the next one, there's nothing better than throwing off those shackles. Re-factoring, reorganizing, and rewriting an older system so that it really shines is extremely rewarding. Games probably offer more freedom than other types of programming projects because game code doesn't usually last longer than about two years. The state of the art moves pretty fast, and as a game developer you'll be pedaling as fast as you can.

The People

If you work in the games industry people want to know about your company and your projects. They talk to you about your job because it's high profile. They want to know when they can play your game. Every now and then you find someone that played a game you worked on, and enjoyed it. It's great when fans get a buzz going about a game that's still in the design phase, or they start talking about the next version before you're back from vacation. They set up websites devoted to your game and argue endlessly about stuff that even the development team finds minor.

A Tale from the Pixel Mines

Never wear development team tee-shirts to places where nutty fans will hang out. I happened to be wearing an Ultima VII "Development Team" shirt when I walked into CompUSA to pick up a game. As I was browsing, a little nerdy guy walked up to me and started talking to me about gritty details of the game design. I'm pretty patient about this kind of thing, so I tried my best to steer the conversation to a close, where any normal human being would simply say, "Well, gee it was nice to meet you! Thanks!" and walk away. Fifteen minutes later I felt as if I wanted to chew my own arm off and give it to him, in the hopes I could make my escape! This person is a good example of why it's good to take a break from games and go outside, find a girlfriend, or even read a book.

Another category of people you come into contact with is the hopeful would-be game programmer. I enjoy these folks and I do everything I can for anyone who has talent and is willing to increase his or her skills. With today's mod scene and increasingly savvy hobbyists there is also an increase in amateur developers. These developers are taking things a step beyond the more casual hobbyist level to create things that are intensely interesting. Some even graduate to cult status, or better yet to the professional ranks. The best revenge is being able to tell your parents that playing all those games actually did you some good.

A Tale from the Pixel Mines

One of the best programmers I ever worked with started out as a dedicated amateur. This guy was so dedicated that he rewrote a large portion of Ultima VII on his own time and actually made a fantastic graphics engine that had Z-sprites before I even knew what they were. He showed us a demo that had the Avatar sink convincingly into a solid castle wall. We hired him.

The best people are those closest to you—the development team. By the end of a project they're like your family. Certainly you've seen them more than your family, and I've even seen teammates become family. Programmers, artists, designers, audio engineers, composers, and testers make an odd mix of people. You wouldn't think that these people could all hang out and get along. Somehow they figure out how to work together in varying degrees of success.

Most of your interactions in game programming are with other programmers. One big difference between the game industry and more boring jobs are that there's a significant portion of programmers that are self-taught in the game industry. That's not to say these folks are slackers by any shake of the stick. Instead, they tend to be absolutely brilliant. One difference between the self-taught hackers and the programmer with Bachelor's degrees is the hackers tends to design and code things before they realize that someone has already solved the problem and posted the code on the Internet somewhere. Sometimes you'll catch them describing a cool data structure they just came up with and you'll realize they are talking about a B+ tree. Their strength comes from their amazing ability to see right to the heart of a problem, without worrying about how hard it is. One of the most brilliant programmers I ever met never graduated high school.

I wish I were a better artist. This is a skill that I admire to the point of wide-eyed wonder. Even better than admiring the raw skills, the creative insight that artists conjure up makes working with them so fantastic. Don't get me wrong; many of them are completely insane, opinionated, temperamental, and ultra-perfectionists. Come to think of it that sounds exactly like most of the programmers I know. Probably the weirdest thing about working with artists on computer games is that you realize that artists and programmers are the same kind of people working on different sides of their brain.

The Tools—Software Development Kits (SDKs)

The most widely used SDK is DirectX from Microsoft. It provides APIs useful for creating game software. There are many more: SDKs for physics, SDKs for rendering 3D graphics, SDKs for audio, and SDKs for networking. One of these days there'll be an SDK for fantasy role-playing games or flight sims. You can't make a professional game without SDKs. You don't need all of them, but most certainly you'll use one or two. They boost your development schedule and give you some confidence that your graphics or audio system has been well tested.

When I first started writing this section it was in my "The Ugly" section at the end of this chapter. I felt a little guilty about giving SDKs such a bad rap. After all, if they were really useless why do I use them on every project? The truth is that SDKs give you a huge leg up. They can also be a huge pain in the ass. SDKs are widely used, so they can't appeal to the odd needs of every developer. Some of the expensive ones come with source code, but any customizations you perform might be invalidated by their next version. Most of the time you have to be satisfied with begging and pleading. Perhaps the SDK engineers will take pity upon you and consider your request.

What I like most about dealing with SDKs is having to spend a week tweaking a game when the new SDK doesn't support the same APIs as the old SDK. To give them credit, DirectX's use of COM does alleviate this pressure. I think COM is ugly as sin, but it does function well in an SDK that changes as fast as DirectX has changed for the last few years.

The Hardware

Games run on cool hardware. Well, most games do. I can't say that the Bicycle Casino project I developed for Microsoft exactly blew the doors off the hardware requirements, but the Ultima games I worked on sure as hell did. Many of the big budget PC titles are created on hardware that has yet to reach any serious market penetration, which means that the hardware manufacturers are constantly sending you the latest greatest stuff and even a tee-shirt every now and then. I used to return from a trade show with a whole other suitcase of hardware: video cards, audio boards, controllers, joysticks, and even virtual reality goggles. I think those days are over, but an established developer can still call any hardware company out there and get on their developer program. You don't exactly get truckloads of free hardware, but you do get a few boards to split amongst the programmers and the test group. That can save your ass if you find that your game crashes on the hottest video card—you can't fix the bug just by hoping it goes away.

A Tale from the Pixel Mines

The developer programs offered by hardware manufacturers are a great resource. Most of them have special developer websites and prerelease hardware programs. They also have dedicated engineers that can help you with a specific problem. An engineer at ATI verified a particular bug on one of the Microsoft projects I worked on. They had a new driver ready in a few days. Of course, I was happy to have the big gorilla named Microsoft standing behind us, but most hardware companies are really responsive when it comes to diagnosing driver problems.

The Platforms

There are a wide variety of gaming platforms, and they never stop growing. For many years we only had to deal with consoles and desktops. Since 2001, games have popped up on handheld devices like the Game Boy Advance, Palm systems, and even cellphones. Even weirder, your digital cable set top box (STB) has the equivalent power of older desktop computers. I've heard that folks in Germany can play networked Doom over their TVs. A group in England just released an entirely new (albeit retro) Tomb Raider game over a STB.

At the time of this writing, the big consoles on the market are Sony's Playstation 2, Nintendo's GameCube, and Microsoft's Xbox. Right now this battle is being won by PS2 which dwarfs the units sold of GameCube and Xbox. My analyst friends tell me, however, that the other systems are doing well-enough on their own so we'll likely see another round of new hardware before someone blinks. In the end it will probably be the company that puts out the best games and the that can hang financially. For best games, Sony and Nintendo take the Xbox easily. Microsoft isn't going out without a fight—and everyone knows that they have huge cash reserves. It's truly exciting to be part of such a slugfest. Imagine the Rumble in the Jungle with Foreman, Ali, and Fraiser in the ring at the same time!

Sony is making a big deal lately of adopting Linux as the development environment for the PS2 and future Sony game consoles. This is fantastic because I like stable, dependable, and standard development environments. Linux is exactly that, and will serve Sony well in the future. Developing software for the Xbox is almost exactly like developing for the PC. It's almost like developing under a cleaned up Win32 and DirectX 8, something desktop PC developers wish for every day. The best part of developing on the Xbox, or any other console, is the fact that you'll never have to worry about supporting a hellish grid of operating system and hardware configurations that are guaranteed to change at least twice during your development cycle.

Table 1.1 lists the various platforms that are leading the pack today. When you look at the hardware comparison, it seems pretty obvious that programmers will have the most fun on the Xbox. Not only is this platform the most familiar, but there is plenty of headroomin the CPU speed and system RAM. The graphics and audio chips support a wide variety of hardware accelerated features, and the stock hard drive and Ethernet ports are nice additions.

Table 1.1: Comparing the Top Platforms for Game Developers.






733 MHz

294.9 MHz

485 MHz

Graphics Processor

250 MHz

147.5 MHz


Maximum Resolution



Up to HDTV





Controller Ports


2 (4 optional)



4x DVD-ROM (3.2–6.4Gb)

5x DVD-ROM (3.2–6.4Gb)

3 in DVD-ROM (1.5Gb)

3D Audio Support

Dolby 5.1

DTS in gameplay, Dolby 5.1 for DVDs

Dolby Pro Logic II

Audio Channels




Hard disk

Yes - 8Gb




10/100 Ethernet Port

Optional modem /broadband

Optional modem/ broadband

DVD Movies




Console development in general is pretty specialized. Developers that get approval to make projects for these platforms must either jump thorough some amazing hoops or they must have standout intellectual property. If you happen to have a favorite uncle on the board of directors of Electronic Arts, you'll be in a great position.

Handheld devices include the Game Boy Advance, cellphones, Palm, PocketPC, and a few others. With these devices, game programming is returning to its roots: clever game designs and efficient implementation. Back in the mid 1980s, classic Williams games like Robotron, Joust, and Defender were technological marvels and the game designs were a blast. The handheld devices today actually have more processing and graphics power than those old stand up machines, and programmers and designers are making games that return to these classic designs.

Screen sizes vary significantly. The GBA supports a palletized 240x160 display, Palm devices are 160x160, and cellphone screens are all over the road. CPU speed and hardware capabilities are also extremely variable. These limitations force you to return to the basics. Far from having a huge development team and server farm for pre-rendering action shots, if you work on these platforms you'll be able to fit your whole development studio in a minivan. It does have a certain appeal, doesn't it?

Desktop development gives you the very best hardware. After all, you can't find CPUs topping 2Ghz in the console world, and you won't find any TV sets that can support a 1600x1200 display at 80Hz. Desktops are always ahead of consoles for raw processing and graphics power. The console programmers will try to tell you that this stuff makes you lazy. They'll say you don't have to be efficient when you have a few gigabytes of virtual memory, and you don't have to be careful if you can publish a patch over the Internet. They'll look down at you and at the same time quietly wish like hell they had all that power.

This awesome capability doesn't come without a cost. The dizzying array of hardware and operating system combinations makes compatibility a serious problem. You'll spend a serious amount of time chasing down some crazy bug that only happens on some version of Windows, like Windows ME, and a particular video card that hasn't been sold in three years, like the 3DFx VooDoo 2. What a hassle!

You also have to find ways to support old legacy hardware while you make your game look good on the bleeding edge gear. The CPU delta can be nearly 10:1, and the graphics delta is worse. It's pretty impossible to emulate a pixel shader on an old Matrox Millenium card. That means your games need tons of configurable options so that players with crappy computers can turn off everything to get some decent frame-rate. Let the flamethrowers turn on multichannel MP3 decompression, full dynamic lighting and shadows, ultra-high texture and model density, stereo 1600x1200x32 displays, and quasi-telepathic AI. Each of these options deserves separate testing paths, on all the hardware configurations.

It makes you glad you can send patches over the Internet.

The Show

The game industry throws awesome tradeshows and parties. Find out for yourself and register for the Electronic Entertainment Expo (E3), usually held in Los Angeles in May. You have to be part of the industry to get registered, so if you don't have a game job launch a game review website and call yourself press. Everybody else does. The second most important thing to do at E3 is play the latest games and dork around with the latest console gear. E3 is a show for the retail buyers—the folks that decide what ends up on the game shelves at Wal-Mart and other retailers. Most of the games at E3 will be on the shelves for the Christmas season, but not all will make it. The show floor is where the game companies pull out all the stops to attract attention. You've got to go see for yourself. It's unbelievable.

Best Practice

Throughout this book, I'll be including a number of "best practice" tips from my years of experience as a developer. I couldn't resist including this one for your first "best practice" dose. The most important thing is to scam party invitations from the in-crowd, and talk your way into the "by invitation only" areas. A friend of mine that worked for Dell was able to get into virtually every private area of the show just by showing up, flashing his Dell credentials, and talking like he was someone important. Almost everyone bought it. It's all good fun.

If you want to learn about game development, go to the Game Developer's Conference in San Jose, held in March. It's brutally expensive, but you'll find the cream of the game development crop telling willing crowds some of their secrets. Before you sign up for any of the workshops, roundtables, or sessions, it's a good idea to do a Google search on the speakers and get an idea of what they've worked on recently. Choose the sessions that have speakers with the most game industry experience, and subject matter you're ready to hear—some of them are fairly advanced.

Game Coding Complete
Game Coding Complete
ISBN: 1932111751
EAN: 2147483647
Year: 2003
Pages: 139 © 2008-2017.
If you may any questions please contact us: