![](https://csdnimg.cn/release/download_crawler_static/10383846/bg12.jpg)
Before I talk about the code and game engine architecture, I want to let you know a little
more about what you are in for.
Programming games is fundamentally different from other kinds of programming. It‘s not
better or worse, just different. Most of the good aspects of game programming have to do
with the bleeding edge challenges you run across and the fact that sometimes you actually
see your name scroll across a credits screen. Games are cool, and everybody loves them. If
you meet a fan at a computer game store, that person is usually really happy to meet you.
You get to play with some great technology from console manufacturers like Nintendo,
Microsoft, and Sony. Software development kits from companies like Emergent, Havok,
Epic, Valve, and others are also a lot of fun to play with. They can give you a real boost in
game development, and can bootstrap your game from nothing to something cool in record
time.
The bad side of professional game programming involves the inherent unknowns that come
with your work. The sweaty underbelly of this industry can be blamed mostly on insane
deadlines and work hours, project management problems, ever-changing SDKs and
operating systems, and intense competition. Hopefully, I can give you some perspective on
the industry and at the same time show you the good, the bad, and the ugly aspects of
game development. I‘ll try to point out some things that I‘ve learned over the past few
years. Read this chapter, and you might be able to dodge a few of these problems.
The Good
Programming jobs in the games industry change fast. In fact, they‘ve even changed since I
penned the first edition of this book. Programming used to be a really broad activity
because there were so many problems to solve and there were so few good and
experienced programmers out there who could solve the problems. In the real early days,
game programmers did everything: code, art, sound, and game design. Now you tend to
see very specialized game programmers for niche areas of game technology: character
movement, network communications, database, physics, and audio are just a few. 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. In that
job I would have had 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. But if you know where to
look, you can still find them. The cool jobs still 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 because they are as much art as they are
science. When I wrote the first edition of this book, I put a lot of thought into why I found
game programming immensely satisfying even with all of the pressures and challenges. I
came to the following conclusion—I like blending the artsy side of my left brain and the
engineering side of my right brain, especially when I‘m in new territory. When I was on
Thief: Deadly Shadows, I got to work on character movement—talk about a tweak fest. I
had to look carefully at the character movement and understand why it ―felt‖ wrong. I
played tons of Splinter Cell to see how they solved some sticky problems. The ―art‖ involved
understanding how character movement was supposed to ―feel.‖ Once I had a clue, I had to
convert that feeling to a piece of code that fixed the problem—that was science, mostly
math. Two sides of your brain working together can solve some really cool problems. Even if
you understand the science, sometimes it‘s up to you to tweak it, like an artist tweaks a
smile on a portrait.