Advice for Would-Be Game Programmers


How to Score a Career in the
Video Game Industry
2012 Edition
Steven Coallier

iBook Format

Kindle Format

Nook format should be available soon!
Thank you, and enjoy!

This section of my site doesn't offer much to the general public (apart from recruiters, of course) as my own personal job history, so I thought I would add something more to it. People ask me, from time to time, how I got into the field, or what classes they should take, or some other bit of advice about how they can best get into the industry.

How I Got My Start

I have played video games since they first appeared, starting with Atari's classic Pong (which, incidentally, is still a very fun game). It's also a good idea to experiment with programming. Always the early adopter, I begged and pleaded and got my first computer for Christmas when I was 13 (that was in 1978). My parents will tell you that they hardly ever saw me again.

Actually, a lot of my earlier programming was not done on that first computer, which was a TRS-80. For one thing, it was incredibly limited. Only 4K of memory, and pixels as big as yer head! So I started out with TRS-80 BASIC, fiddling with graphics and maze games and simple adventure games and just generally trying to make the machine DO THINGS. The limits were too stifling, though, so I soon began to use the computer as a terminal instead, and accessed the power of the Macomb Intermediate School District's mainframe computer, an IBM 360-compatable Magnuson 80/32. Along with many other students from that district, I begged, threatened, borrowed, and pleaded for space on the system to write programs, and that space was eventually granted.

Within that space, there were a number of projects I worked on. I was part of a group that maintained SPB (SPace Battle), a multiplayer text-based action game based on the television series Star Trek. That game taught me the value of good gameplay and proper game balance. On my own, I developed DragonSlayer, a massively-multiplayer (up to 32 players, I think) text-based RPG game. I had played a game called Wizards (or something like that) on another system, and it had gotten shut down. I reached the system administrator and asked them for a copy of the source, so I could put it up on our system, and he refused. So I wrote my own! It was my first rewarding game programming experience - I did it all alone, and it was a big success among my peers.

Things You Can Do To Get There Too

Play Games
To begin with, you must enjoy games if you want to make them. Actually, this applies to any career - if you want to live a long, happy life, find work that you might do even if you didn't get paid. So...and this will probably not be too hard for you, if this is your games. Buy whatever games you can get your hands on. Play games you don't have at friends' and relatives' houses. Play games at the nearest video arcade. Ask yourself as you play them: How are they doing this? Why is this fun (or not fun?). What works here, and what would you do differently? These are questions that good game developers ask themselves all the time.

It's not enough to just own a computer - any couch potato can operate one these days. You must program it. Visual BASIC is a good way to start with the PC, and the Internet is filled with code examples to work from. For the most part, I have learned to program by reading and tweaking examples of working code. This is not to say I've never written any of my own - I've written millions of lines of code - but there is no way to better understand something than to take it apart, tweak it, and try to put it back together. When you are eventually ready to apply for an industry job, you will get extra credit for having done some programming on your own time.

Stay In School, Kids!
Sadly, the days where you can become the hot new programmer at a game company without a college education are pretty much gone. Most companies are looking for at least a Bachelor's degree in Computer Science, Software Engineering, or Computer Engineering. As far as coursework, you'll want to learn C, C++, and assembly language (also Java for those of you hoping to work on games online); plus specific courses in 3D graphics, artificial intelligence, computer simulation, and (if you're lucky enough that your chosen school has it) game theory.
It's also important to learn things that don't seem to be about games. After all - games are about something, from football to history to space to psychology. Learn anything and everything you want to learn - the more you know, the more you will be able to tackle any situation, whether you're in the game industry or not.

Stay Informed
You also need to keep up to date on the industry. As with any potential job, you'll have a better chance of looking smart, in-touch, and on-the-ball if you know that Hornblower Software is two months late shipping their Liesure Yacht Simulator product, or that MicroCorp is putting Wesson video cards in their upcoming game console. This will help you figure out what you need to know in order to make games in the current market, and it will tell potential employers that you care. Attend the Game Developer's Conference if you can. It's not what it used to be, but it's still the industry standard insider conference and it can be informative and also entertaining. Sorry, it ain't cheap!

Recommended Reading (with links to
Besides reading pretty much anything you can get your hands on (because it's good for your brain, dammit!), I recommend the following titles as part of your permanent game development shelf.
Writing Solid Code - This is an excellent book to read after you learn how to program, so that you can program more effectively. It teaches how to structure your thoughts and your programming practices to avoid as many bugs as possible before they happen.
Game Design Secrets of the Sages - This may seem like a plug, because I actually contributed to this book, but my part isn't much help I'm afraid. Instead, plow through this book for insights and wisdom from dozens of the game industry's real leaders, like Sid Meier. I should note that this is not a book on programming, it's a book on design, but programmers should stay well aware of design issues, because you can bet they'll have to deal with them. Unfortunately, this book seems to be out of print.
Going from C to C++ - As is obvious from the title, this is a useful book for learning C++ from the point of view of someone who already knows C. I read this and was able to instantly make progress on a C++ project (Wing Commander III for the Playstation) without any prior experience. Unfortunately, it's also out of print.
You'll want to subscribe to Game Developer Magazine. It's filled each issue with information ranging from useless to useful, and it can be yet another way of keeping your finger on the pulse of the industry. You do not have to be a member of the industry to subscribe.

Links (more eventually as they occur to me)
Amit's Game Programming Information - A Stanford Student's good list of multipurpose links that have to do with game programming.
Gamasutra: The Art and Science of Making Games - Comprehensive site listing game industry news and jobs, also has articles on game development.
Fatbabies - A game industry insider rumor-mongering site. Sometimes brutal, beware! And don't believe everything you read there...I know for a fact that at least some of the stuff about EA is not true.

Things You Can Expect Once You Get There

Generally speaking, computer game development is fraught with extremely long hours. For example, when I was working on Wing Commander III for the Playstation, our deadline - which we ended up missing - required us to work 100+ hour weeks for nearly eight months. Which hours you work is usually up to you, provided you get all your work done and are successful in working with others on your team. Now, I should point out that all that overtime is a sign of problems with how you approach the project. We nailed Knockout Kings 2000 for the Playstation out of the park in six months, starting from scratch! The difference was how the project was managed. I do my best to manage the teams I work with so that there's a minimum of overtime, but the truth is that the computer game industry is very deadline-conscious (NCAA March Madness, for instance, obviously can't hit the shelves in April or it's going to affect sales - and if your sales are lousy you'll eventually either need to get a day job or quit making games). In any case, expect hard work!

The cool part of working on games is that nothing in a game happens without a software engineer making it happen. The difficult part of working on games is that nothing in a game happens without a software engineer making it happen. What you eventually become responsible for depends on you, and it depends on your company. I like to let people find their own level of responsibility. Generally, you'll have some say in game design, for instance - but definitely not the final decision, unless you work very hard and get to the point where your company will let you become the chief designer for your own game. This is something of a Holy Grail for a lot of game programmers, so be aware that it may never happen.
There are currently a number of common specializations in game software engineering: Graphics & rendering, artificial intelligence and gameplay, physics, animation, user interface, platform specialization (Playstation, XBox, Gamecube, Windows, etc.), high and low level audio, high and low level networking, and development tools.
As far as scope, I generally give my engineers more scope as they become able to handle it. If they have trouble writing one routine, I'm not going to put them in charge of a module; if they have trouble with a module, they won't be assigned a subsytem; and if they can't manage programmers working on a subsystem they're certainly not going to lead an entire project. Of course, not everyone wants to, which is good, because you can't have a tribe with all chiefs and no Indians.

Compensation varies widely in the game industry across time and even across some large organizations. I believe that in general, game programming pays slightly less than other types of engineering, even though I think it's more difficult because good games tend to push the hardware to its limits. Game companies are as yet untouched by unions, so you'll be responsible for your own negotiating (remember, at any company typically if you don't ask for it, you won't get it). The benefits are usually pretty good. Some companies will occasionally go way overboard with salary offers in order to try to attract people - beware of this, I've found that it's usually a sign that the company will be in trouble later. Stock options are another form of compensation at public companies, and of course how good this gets depends on how well the company does. My options from EA have served me very well. Some companies, even ones that aren't public, offer some form of profit sharing. Remember that other than your salary, any of this compensation may or may not be there (even if it usually is), so don't count on it. The largest companies will have a 401K program, which I encourage you to participate in. EA also has an Employee Stock Purchase plan that guarantees at least a 15% return on your investment.

Work Environment
The game industry is generally filled with people that are a lot of fun to work with. They're intelligent, they're creative, and they're interesting. So, even though the work can be stressful (and consequently, the people can be grumpy) during crunch times, it's still generally fun. Game companies - at least the ones I've heard of and worked for - tend to be very casual, with no dress code. You can usually talk to executives without fear of getting fired (well, okay...only at some companies, but Electronic Arts is one of them). I would actually rate it up with the top ten work environments I can think of (the environment for a Lifeguard is a bit hard to beat).
There is no dress code at any game company I've ever heard of (oh, except I guess at some of them there's a fairly strict requirement that you wear shoes). Most companies have their development teams in cubicles which (where there haven't been any lawsuits) you can decorate to your hearts' content. If you're allergic to flourescent light, you many want to consider working in building construction instead.

Partners in Crime
Besides Engineers, the typical game team is made up of Producers and Artists. Sometimes there will also be a game designer - if not, then that slot is most commonly filled by a member or members of the Production team and less commonly by Engineers or Artists. Lastly, during the later phase of your project you'll be interfacing with Testers.
Producers generally handle any financial or legal details that have to do with your product - acquiring licenses, making sure contractors get paid, reviewing the product for submission guideline compliance. They sometimes also do some of the data work involved in games - I've worked with Producers who do level design, statistics compiling, AI tuning, and many other tasks that are not quite programming but can certainly be essential for building a game.
Artists obviously do the art. Some Artists will work mostly in one area - 3D modeling, or texture painting, or interface art, or animation - but others have more than one skillset. As a general rule, the stereotypical artist is not very technical (which is fine - the stereotypical Engineer isn't very artistic either), so some of Engineering time will be spent making it so that the artwork for the game doesn't require any special technical ability or helping the Artists when some tricky part can't be avoided for whatever reason. Art teams are generally carved up into disciplines - 3D modelers, 3D texture artists, Animators, 2D artists and more, for instance, depending on the size of the team.
Testers are generally mistreated entry-level or temporary employees. It sounds like a fun job - play games for money! However, you aren't necessarily playing something you like, the whole time you're playing it it's broken (which is what you're there to point out), and as soon as it's not broken you don't get to play it anymore. Add to that the fact that developers tend to take bugs personally (how dare you point out their mistakes!), and the long hours, and it ends up hard work. If you get a job in game development, please be kind to your Testers - without them, nothing would ever be worth shipping. On the negative side, Testers can be a bit weak at communicating effectively, which doesn't work very well since communicating what is wrong with the software is sort of the whole point of their job.

Being a programmer is all about getting the computer to do stuff. If you're making games, it's about making the computer do cool stuff.

Back to the Career Overview.