Interview with Irrational Lead Programmer Chris Kline
6 May 2005 -- This Week at Irrational with Meredith Levine
Interview with Irrational Lead Programmer Chris Kline
Chris Kline, Lead Programmer on SWAT 4 took time out of his very, very busy
schedule to speak with me about his work. Chris took a leading role during the
beginning of SWAT and also led (with Rowan Wyborn in Australia) the code-sharing
effort that helped make development of both SWAT 4 and Tribes: Vengeance go smoothly.
What is the overarching role of the lead programmer in game development?
The lead programmer is responsible for overseeing all aspects of the game's
technology development process. At a high level, this means I'm the guy who
gets his butt kicked if the tech team doesn't deliver. But on a more day-to-day
level, it means that I do the boring stuff so that my amazing team of programmers
doesn't have to deal with it and can focus on building the cool parts of the game.
Ideally, if I do my job right, the tech team will be able to deliver the
features that the other teams need, on time, without having to work overtime.
What do you on a daily basis? Describe a typical day.
Well, over the course of the project it could include any and all of the following:
Making sure that all the crazy ideas the artists and designers are planning can
actually be achieved from a technology standpoint. I try to explain what our tech
can currently do, what it might be able to do if we devoted some time to it, and what
we definitely will not be able to do. Sometimes I'm the good cop, and sometimes I'm
the bad cop (people at my last company used to call me "Dr. No").
Building a 2-year task schedule for our 7-person programming team, to ensure
that pieces of technology come online before they are needed by the rest of the
team, and monitoring/updating this schedule on a weekly basis.
Building the Technical Design Document, which outlines the "big picture"
problems the game will have to solve, defines possible approaches, and enumerates
the risks and risk mitigation plans for each problem.
Working with the lead artist, lead designer, and project lead to solve problems
as they arise, to keep the team working at maximum efficiency.
Working with Rowan, my counterpart lead programmer in the Australian office,
to coordinate technology shared technology development.
Working with the programming team to help them solve problems they are encountering,
such as software design conundrums, scheduling issues, and sometimes even interpersonal
Coordinating with the QA team, triaging bug reports, and making sure the game
remains as stable as possible during development. Managing code development branches,
cross-integrating changes, and releasing both internal builds and external (milestone)
builds of the game.
Occasionally doing little bits of coding. This is usually really boring stuff, like
fixing bugs, or implementing little features that I forgot to put in the 2-year schedule.
Are certain types of projects more or less desirable from a programming standpoint?
Definitely! I'd rather clean the floors of all the Orange Line trains with
my tongue than write a cell-phone game.
From a purely geek-chic standpoint, every programmer has their own preferences as
to what's a desirable project and what isn't. Some of the guys on my team would love
to optimize low-level microcode on the PS2, and some enjoy high-level systems
architecture. Others geek out on developing tools in the latest scripting language,
and still others are all hot for the [unmentionable hardware capability] in the
[next-gen console which may or may not exist]. Personally, I'm in it for the visuals--
if I can work with talented artists to make a game with beautiful 3D graphics and
animation, then I'm sold.
But in the end it's the game itself that ends up on the shelves, so the most
desirable projects are the ones that allow us the chance to focus on making a
great game. These are the projects in which the technology requirements are very
challenging but achievable, the visual aesthetic is distinctive, and the gameplay
is innovative, fun, and open-ended. That pretty much describes every project
Irrational Games has ever undertaken.
Can you talk about how the programming team interfaced with the artists and
designers to get SWAT 4 done? When does the programming team come into the planning
process of a game and how do you as lead programmer run the process, figure out
what to delegate where, etc.?
Sure. SWAT 4 was a great project because we had a clear vision for it from the
beginning, and from the very start of the project the programming team was involved
in all aspects of the design.
The first thing that happened was that everyone on the team played SWAT 3 at
work if they hadn't already played the bejeezus out of it on their own time.
Then the entire company brainstormed about what aspects of SWAT 3 were great,
which ones sucked, and how we wanted to take the SWAT concept and "make it our own".
In the end we decided that we wanted to take most of SWAT 3 and improve it with
better AI, better graphics, an improved command interface, the feeling of being
immersed in a dark, gritty, miserable world.
Paul Hellquist, our lead designer, worked with the design team to create a
very thorough (120 pages at last count) Master Design Document that explained
every feature in the game and how the design team thought it should work. I then
broke that down into a schedule of tasks that I then assigned to individual
programmers based on a variety of factors:
-How soon did the feature needed to come online?
-How important it was to the core game experience?
-How closely did the feature match the skill set of a particular programmer?
This included both technical and interpersonal skills.
-Was a similar feature needed for the project in the Australian office (Tribes:Vengeance),
and could we share the technology?
-How much did a particular programmer want to "own" a particular feature?
Once the high-level tasks (e.g. "build a weapons system", "implement room
clearing for AIs") were assigned to programmers, those programmers were responsible
for working with a designer or artist to gather detailed requirements (e.g. "weapons
use ammunition, which is stored in clips, which can be reloaded", "AIs need to be
able to aim in all directions while moving"), break the task down into sub-parts,
and begin implementation. Usually we did features in multiple "passes", where we'd
try to implement the major components of each feature (e.g., , "bullets cause damage
when they hit things", "AIs can move through doors in a coordinated fashion") first,
and then later on iron out the smaller, less important details like "when you turn
on the flashlight, the tiny texture on the weapon that represents the flashlight
needs to glow".
During development the programming met every Monday afternoon for about two hours.
During that meeting each programmer would talk about what he accomplished during the
previous week, whether he was ahead of schedule or behind schedule, and what kinds of
problems he was encountering. Based on that I would adjust the programming schedule
to make sure that the most critical tasks got done first, and try to get the programmers
the resources they needed to finish their tasks. We did a lot of "discussion" (read:
arguing) in those meetings, but they were instrumental in making sure that each
programmer knew what his colleagues was up to, and helped ensure that the system that
one programmer was building would meet the needs of the other programmers who had to
How does one end get into programming as a career?
What made you decide that this was the right path for you?
There's a thousand different ways to get into programming as a profession. How
did I end up in game programming? Well, it's a long and convoluted story.
I was a bit of a pasty-faced geek when I was a kid (I'm still a geek, but a
little less pasty). Sometime in the early 1980s my dad brought home a Franklin Ace
1000 computer (an Apple II+ clone), and he and I taught each other to program it.
Dad worked the night shift, so while he was asleep during the day I would program
and leave it for him to see; then when he came home he would program while I was
asleep and leave it running for me to see. We would continually try to one-up each
other, which was a fun way to learn. My pi?ce de r?sistance was an interactive tour
of the Earth's crust, with music, written in BASIC, that I did for my science project
in 4th grade. Let me tell you, that was a big hit with the ladies.
In junior high I got bored with computers and didn't touch them for a couple years.
In high school I started programming again, teaching myself Pascal and C at the same
time, and graduated to an Apple Macintosh. During that time I worked in a Macintosh
computer store as a technician supporting their high-end graphic design and pre-press
customers. This introduced me to graphic design -- a profession for which I have great
interest and absolutely no talent -- and got me excited about the intersection of
computers and art. Then, mostly because I had no idea what else I wanted to do, I went
to Cornell University to study computer science.
I got really disillusioned with plain-vanilla computer science during my undergraduate
years, and was almost ready to quit until I discovered the magic of "independent study"
classes. I took a computer graphics class, nearly failed it because I'm slow at math, and
then somehow convinced that professor (
Dr. Bruce Land, an amazing man) to take me on as
his research assistant. He encouraged me to follow my interests, and I ended up spending
a few years working in 3D graphics and virtual reality (remember that?). Then one fateful
day in the fall of my senior year I realized that I needed to take several
"engineering-related" classes in order to graduate, and on a lark I signed up for
Neurobiology and Behavior because my friend Greg Pass was taking it. As it turns out,
this was one of the most interesting classes I had ever taken. To continue working in
that area I started an independent study project wherein I attempted to study the role
of reproductive sharing as it relates to cooperation among female wasps by trying to
simulate them in a computer and evolve them using genetic programming techniques. It
didn't work, but it was a hell of a lot of fun.
At this point I still didn't know what I wanted to do with my life, but I knew that
I enjoyed working on computational animal behavior models, so I ended up going to the
MIT Media Lab to work with Dr. Bruce Blumberg
in the Synthetic Characters Group. This
research group was attempting to study models of animal behavior by building simulations
of actual embodied animals. The idea was that by building artificial animals and observing
why they didn't behave like real animals, you could learn something about the nature of
thought and behavior. This was the period of my life where I learned a lot about artificial
intelligence, computer animation, and traditional animation.
After MIT I went to a small startup company called Nearlife, where I got to work on all
sorts of cool projects involving artificial intelligence, computer animation, computer
vision, and human-computer interaction. I worked on the giant interactive Virtual Fishtank
that is in the Boston Museum of Science, an interactive children's playroom called the
in London's Millennium, and
giant interactive touchscreens in the Museum of Science and Industry in Chicago.
Finally, after leaving Nearlife I ended up at Irrational Games. All the skills I had
learned in the past -- animation, A.I., 3D graphics, simulation architectures, interaction
techniques -- were the same skills needed in the games industry, so it seemed like a
good fit for me.
So, to answer your question: how did I decide that game programming was the right path
for me? Basically, I didn't. I just followed my interests and somehow I ended up in a
challenging, fun, and rewarding job. Pretty lucky, eh?
What kind of educational/work background is desirable and/or helpful for the job?
Is a degree necessary?
Probably the easiest way is to study computer science in college. A degree is not
always necessary (a few programmers on our team never finished college), but it is highly
advised. Not because a C.S. degree will teach you how to be a good software engineer,
because it won't (dirty secret: computer science is actually about mathematics, not
computers!). But if you go to a good school and study C.S. you will learn something more
important than how to program -- you'll learn how to approach, analyze, and solve problems.
What skills are useful for the position?
I would say that the following are the most useful skills:
Math: Game programming is becoming increasingly more math-intensive. So don't fall asleep
in math class, like I did, because then you'll just have to learn it all over again later.
Pay special attention in Linear Algebra.
Art: Take as many art classes as you can. Study animation, drawing, acting, and music.
As a game programmer you'll have to work with artists all the time, and the more insight
you have into their profession, the better you'll be at designing systems to make their
artwork come alive.
Communication: As a game programmer, you will need to be able to communicate clearly,
both in person and on paper, and also work well with other people. Especially smart,
quirky, opinionated people.
Passion: If you don't love making and playing games, you won't do well in this industry.
So experiment with things on your own -- build your own games, then rip them apart and
make them better. Learn what you like and dislike about games, and be able to discuss these
Don't be a dork: Don't spend all of your time in front of a computer. Get a hobby.
Make friends. Exercise. Read non-technical books and study non-technical subjects.
Become an interesting person.
You are a relative newcomer at Irrational, how does IG's development process
differ from your previous experiences?
I've been at Irrational for 3 years now. The fact that I'm still a "newcomer"
says a lot about the company and our team!
I would say that there is a lot more exploration in our development processes here,
and a lot more opportunity for every individual to contribute to the final product in a
unique way. That's because it's almost impossible to define what makes a game "great" or
"fun" before you start building it. The best you can do is start with a talented team and
a good idea based on a lot of experience. From there the process is iterative, and at any
point in time *anyone* might come up with that one idea that really makes the game shine.
Making games is not like stamping widgets. I like the idea that we know roughly what
kind of game we're building, and when it will be done, but it's a giant mystery as to
exactly how or when it will stop being a piece of technology and start being a game, or
why it will be fun. Every day when I walk in the door someone could say "hey, come look
what I did" and show me something amazing and unexpected. It keeps me motivated.
What do you find most satisfying/enjoyable about your job?
I love working with the people at Irrational. All of them are smarter, funnier, and
infinitely cooler than me. It's exactly the kind of place I want to work, because it
keeps me on my toes.
I also really enjoy the development process, seeing a game go from concept to completion
in little tiny stages. That first time your own game makes you laugh, or jump in surprise,
or sigh in amazement -- that's magic.
What do you find most frustrating?
Eventually you have to finish the game and kick it to the curb. And no matter how good
it is, there's always that one little feature, that little bit of polish that could have
made it in the game if you'd only had a day or two more to work on it.
--- Meredith Levine