NOW AVAILABLE!!!
MAKING FUN:
How to Score a Career in the
Video Game Industry
2012 Edition
By
Steven Coallier
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.
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.
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 interest...play 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.
Experiment
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 Amazon.com)
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.
Workload
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!
Responsibility
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
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.