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 conflicts.

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 use it.

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 KidsRoom2 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 things intelligently.

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