Interview with Steve Theodre, TD at Bungie Studios

Tech-Artists.org would like to present our first interview, with Steve Theodore, the Technical Art Director at Bungie Studios. He goes over his history and experience, where the tech art field is going, and gives advice to aspiring technical artists. Thanks to Adrian Walker for conducting the interview and Steve for being a great first interviewee. Look for more interviews every couple weeks.


Adrian Walker: Thanks a bunch for agreeing to be interviewed! To get things started, why don’t you provide us with a few tidbits of who you are?

Steve Theodore: I got into computer graphics about 15 years ago. I was a grad student in, of all things, Roman History. However, I used to make money on the side by teaching graphic artists how to use Macintoshes – grad students always need money – and this ended up with me helping out a company that had a laser slide printer, which in 1992, was the height of high tech. Those guys got a magazine called Computer Pictures, which was pretty much the only source of information about computer graphics in those days.

Amazing stuff was going on in those days – one month you’d see the first application of skinned models, the next you’d see about this hot new idea called “bump mapping”, and so on. I got really into reading up on this stuff while I was waiting for the laser slide printer to crank out slides, and I started hanging out around the university graphics lab playing with their text-based rendering system.

After a while I was spending a lot more time on ray-tracing than I was on the Romans. I dropped out of grad school and started my own studio doing anything I could do in CG. I did a lot of architectural visualizations, some TV commercials, and a lot of side loops for trade show kiosks. What I really wanted to do, though, was animate, and there just wasn’t enough animation work for a little studio.

I headed off to SIGGRAPH hoping to get a job at ILM or Pixar (this was when Pixar was still a graphics geek cult thing, way before Toy Story), but ended up with an offer from FASA Interactive in Chicago, where I went in 1995 to work on MechCommander. I started off building giant Mechs (every boy’s dream job) and helped out with the animations in the cinematics. The big drawback to that job was the fact that those cinemas used to take 10 - 15 minutes per frame to render, so I spent a lot of time reading BattleTech novelizations and playing Quake.

I went to Valve in 1997, where I was really excited to work on real-time characters. I came on to Half-Life pretty late, so I had a very random set of jobs to do. I did most of the player weapons, for example, but also the big yellow loader robot from the opening train ride and some incidental creatures. My favorite job was animating scripted sequences, which at that time we did on Biped (in those days that was the only interactive IK tool you could get. The IK animations for that loader robot had to be calculated off line – you’d set up the IK targets and twiddle some knobs and then wait 5 minutes while the animation was “solved” for you. Yuck.)

I started getting into the technical art side while working on Team Fortress Classic. Like everybody else we suffered a lot from the “candy wrapper” twist artifacts in our character shoulders, and I wanted to solve it by adding extra deformation bones. Nowadays this is completely standard, but back then it was very mysterious – it was particularly hard to do because Bipeds didn’t play very well with anything else in Max, but it taught me a lot about the basics of 3D math and character rigging.

We wanted to move the Team Fortress team from Max to Maya but we couldn’t convince any of the engineers to write us an exporter, so I learned MEL and wrote a text exporter. That was probably the moment I really started to think like a tech artist – I started doing things like scripts for mapping Maya materials onto the Source engine shader system, or automatically updating a character’s animation list. In 1999 or 2000, though, there wasn’t a recognized label for technical artists in games so most of this was spare time work rather than my day job – I was mostly a doing character models and animations, particularly for Team Fortress and Counter-Strike.

By 2002 I was really interested the big knot of problems that connected character rigging and in-game animation. I was invited to join RAD Game Tools, where I helped out with the Granny animation middleware system. It was a real education in the nuts and bolts of graphics, as well as a great opportunity to do demo art. The only drawback was the fact that I was the whole art department – I really grew to miss working with a team and shipping games.

After three years at RAD I was recruited to help Zipper Interactive make the transition from PS2 to PS3, so I helped them get to grips with the new realities of high-res models, fancy shaders, and high detail environments. Partly because of that experience, I was tapped to be one of the founders of a startup a couple of years later, which came agonizingly close to a deal but didn’t pan out in the end. Luckily for me a friend at Bungie wanted to get together for lunch, and quite by accident the lunch visit turned into an all day interview and a day later I found myself in my current job, which is Technical Art Director at Bungie. I was there for the last seven or eight months of Halo 3, and since then I’ve been doing a big overhaul of the Bungie pipeline.

AW: You mentioned how back in 1999-2000 the position of technical artist didn’t really exist. Nowadays technical artists are seen in many of the top studios around the world, and are finding their way into even the smaller ones. How do you picture the role of the technical artist continuing to evolve as we move into the future?

ST: I think there’s two main ways the tech art positions will develop. As content gets more and more complex, a lot of energy is just going to go into taming the creation process. I expect you’ll find that studios’ toolsets will be diverging more and more as our tools get more sophisticated – the Max or Maya of a racing game studio may be barely recognizable to somebody coming over from an RTS studio or vice-versa. It’s going to be tech artists who drive that evolution, since they know both the technical skills you need to make those tools but also the workflow and artistic issues that are important for making good tool designs.

On the more interesting side, though, I also think you’ll see some tech artists evolving into procedural content authors. Consider the differences between a really good rigger and an animation programmer… who really knows what the right approach to posing a character is? Is it the guy with the knowledge of C++ and “engineer” on his business card, or the guy who spends 50 hours a week designing systems for posing characters? Just as there’s already a whole class of game designers who are really writing code – just not in compiled languages – on the design side, there will be a whole class of content people who make content procedurally – shaders, procedural textures (check out the latest software from Allegorithmic if you want some inspiration), systems for building procedural geometry, and animations. None of the procedural stuff will ever displace “real” artists – you want it for filler, for quick rough outs, and for enabling open worlds and open ended gameplay. But it’s going to be very important. Not to plug too ham-handedly, but I did a talk for Microsoft Research’s academic program this year that goes into a lot more detail on this subject – it’s at http://www.academicresourcecenter.net/curriculum/pfv.aspx?ID=7296

AW: What about being a technical artist attracted you to the field?

ST: I think most of us have a common personality trait – a bizarre combination of restless energy and complete laziness. A tech artist is the sort of person who looks at a busted way of doing things and says, “This is ridiculous, I shouldn’t have to spend 5 minutes on this every time” – so he turns around and spends 5 hours writing a tool to get around the 5 minute bottleneck. When I run into one of these things that seems really pointless and time wasting I take it really personally, and I want to beat it into submission.

AW: Throughout your career you have worked on a number of very popular technologies and games. Do you find the love that gamers have for these games to be a huge draw for you to push the envelope, in addition to your desire to just “beat the technical bottlenecks into submission”?

ST: Well, mostly I’ve been insanely fortunate to work with such great projects and people. Lots of folks do really brilliant work that goes completely unrecognized because they are on unlucky teams or ill-fated projects – being on a l33t project, including the ones I’ve been on, involves a large element of luck. That said, being on a good team and a good product really is inspiring – it’s a multiplier on everything you do – it makes you willing to sacrifice more nights and weekends just to see something great become amazing. If you’re stuck on a project that’s clearly going nowhere, on the other hand, it’s sometimes a real drag just showing up for work in the morning. So I’m constantly grateful to be where I am, and I work my butt off hoping that I can sort of deserve the great good luck I’ve had in the form of my teammates.

AW: When in your career did you discover that working as a technical artist (as compared to a more ‘pure’ artist or programmer) was what you wanted to do?

ST: I think it was partly the fact that I worked on some very small teams (TF and Counter-Strike) where nothing would ever get done if you couldn’t be more productive than a more manual, craft-oriented artist. That really changed my way of thinking.

AW: Could you tell us a bit about some of your favorite tools and technologies that you enjoy working with / make your life easier as a technical artist?

ST: Lately I’ve been doing a lot more “real” programming, mostly in C# – which sometimes makes me impatient with the limitations of MAXScript and MEL. We’ve been working hard to avoid duplicating effort between our Max and Maya tools, which gets to be a big hassle when you need to support both.

AW: C# really seems to be gaining more and more momentum in the games industry for tools development. Python seems to be pretty hot as well. What has drawn you to C# over Python?

ST: C# and Python are both great. For Bungie, we do a ton of application development in C#, so it makes sense for us to do as much of our art pipeline that way as possible. C# also has really good, standardized dev tools and a whole boatload of really excellent standard libraries. Since it’s compiled there’s a slight performance edge over Python too, but I don’t think it’s such a blowout that you shouldn’t think about Python, especially when PyMEL matures enough to make Maya into a really robust development platform. If you’re a Max or MotionBuilder house in particular Python is an easier route – people who are interested in that area should check out some of the talks and master classes Jason Parks has done for Autodesk over the last few years.

We’re about 75% Max / 25 % Maya, so Max’s .Net support outweighed Maya’s Python commitment for us. We’ll probably end up doing a .Net host inside of Python and getting the best of both worlds. However I’m always worried about the classic tech-artist personality trait of perfectionism – if you chase the technically correct solution to every problem you’ll end up supporting 10 languages and 4 art packages and you’ll spend all your time applying patches and downloading updates instead of actually making tools.

AW: What advice can you give students who are looking into finding jobs as technical artists in the future?

ST:Scripting is the first requirement – you need to be able to convince both fellow artists and engineers that you can do most of the light or medium duty tasks in script, without involving engineers (except, especially at the beginning, as mentors for good programming practice). The tech artist’s number one job is to be able to take an idea that is done by social engineering (“remember you always have to name it like this and set the two sided flag on!”) into something done by a tool (“click this button to set it up for export”).

The web is full of scripts, some pretty awesome and some really poor – poking around on the forums of Highend3d or CGChannel is a great way to see how other people do things. Maya gurus like Ryan Ellis or Brian Ewert, or Max gods like Bobo Petrov are also really useful for inspiring you to see what’s possible.

After that you should look at both character rigging for animation and shader writing – ideally you’d pick up both, but they’re very different skill sets and it’s hard to excel in both at the same time. The transition from scripting to rigging is probably gentler than from scripting to shaders.

One thing I always stress, though, is you can’t be a great technical artist unless you’re at least a competent production artist too. If you haven’t got a good eye and some personal understanding of the ups and downs of working on a game, it’s hard to really help line artists – and that, after all, is what tech artists are for. A stint as a working animator or modeler or effects artist is really valuable down the road. This does mean it’s hard to focus on tech art early, so it’s a good idea to be clear with potential employers about your goals.

This is one place where the “neither fish nor fowl” part of tech art is tricky, because landing that job as a half-artistic, half-techie noob competing with other noobs who are, at least, specialists is a tall order. One useful trick is to do art which complements your tech specialty – if you’re a rigger, do some creatures that really benefit from clever rigging; if you’re a shader artists, do work that showcases your shaders. But always judge the work as art – if you think it looks like a tech demo, the interviewer will too.

Last but not least, learning a good modern language like C# or Java will teach you a lot about the guts of “real” programming (MAXScript and MEL are very powerful but they’re also pretty odd ducks as programming environments, and it’s good to get an idea of what the big kids play with even if scripting is your main tool).

AW: Thanks a bunch for your time! I’m sure everyone visiting tech-artists.org will enjoy reading this.


Please tell us what you think of the interview, and who you’d like to see interviewed in the future! And if you liked what Steve had to say, you can read more of him in his Pixel Pusher column in Game Developer magazine.

_

Thanks Steve! Great content and wonderful suggestions - esp the python and C# part.
:nod:

ST: I think most of us have a common personality trait – a bizarre combination of restless energy and complete laziness. A tech artist is the sort of person who looks at a busted way of doing things and says, “This is ridiculous, I shouldn’t have to spend 5 minutes on this every time” – so he turns around and spends 5 hours writing a tool to get around the 5 minute bottleneck. When I run into one of these things that seems really pointless and time wasting I take it really personally, and I want to beat it into submission.

I love it when you read something like this and find yourself nodding in total understanding. :D:

Great article.
I too will quote:

ST: I think most of us have a common personality trait – a bizarre combination of restless energy and complete laziness. A tech artist is the sort of person who looks at a busted way of doing things and says, “This is ridiculous, I shouldn’t have to spend 5 minutes on this every time” – so he turns around and spends 5 hours writing a tool to get around the 5 minute bottleneck. When I run into one of these things that seems really pointless and time wasting I take it really personally, and I want to beat it into submission.

Too true.

Good article! Its always enjoyable to hear a veteran of the industry speak of their experiences in their early days.

[QUOTE=Rob Galanakis;1186]
ST: I think most of us have a common personality trait – a bizarre combination of restless energy and complete laziness. A tech artist is the sort of person who looks at a busted way of doing things and says, “This is ridiculous, I shouldn’t have to spend 5 minutes on this every time” – so he turns around and spends 5 hours writing a tool to get around the 5 minute bottleneck. When I run into one of these things that seems really pointless and time wasting I take it really personally, and I want to beat it into submission.
_[/QUOTE]

I’m sure like most technical artists my motivation to learn came out of necessity to eliminate repetitive tasks, such as Steve mentions here, that could be automated down to single button presses. I’m really a stickler for removing any process that involves me trolling through deep directories to save, load or export files. Its rather easy to remove situations like that from your workflow.

[QUOTE=Rob Galanakis;1186]
ST: C# and Python are both great. For Bungie, we do a ton of application development in C#, so it makes sense for us to do as much of our art pipeline that way as possible. C# also has really good, standardized dev tools and a whole boatload of really excellent standard libraries. Since it’s compiled there’s a slight performance edge over Python too, but I don’t think it’s such a blowout that you shouldn’t think about Python, especially when PyMEL matures enough to make Maya into a really robust development platform. If you’re a Max or MotionBuilder house in particular Python is an easier route – people who are interested in that area should check out some of the talks and master classes Jason Parks has done for Autodesk over the last few years.
_[/QUOTE]

We’ve been getting into developing more of our tools here with Python. I enjoy the language and I have done quite a few things with it. My tools are no where near as advanced as some of the other guys but I utilize it when it is necessary.
After taking some Python and C classes, given by some of our Programmers here at the studio, I’ve been getting into C# more. I have to say i’ve really been enjoying the flexibility and ease of use of C#. I’ve been mostly working in XNA trying to get an understanding of the core of game development as well as trying to implement some game-side animation ideas. I’ll likely continue working with both hopefully as a hobbist and professionally.

Also, as a fan of “Half-Life”, I have to say the scripted animation sequences were some of my most memorable moments playing the game.

This is a great interview, thanks to Rob and Steve for putting in the time on this.

I’ve been thinking about transitioning into more of a Technical Artist role than my current AD/LA path. So I’m hoping I’ll get some time soon to learn more about scripting and tool-building, to that end Steve’s tips and insight are much appreciated.

I’ll also echo that “lucky to be in this, so working my balls off” sentiment. So true.

I just did the formatting and posted it, Adrian Walker conducted the interview.

I’ve been thinking about transitioning into more of a Technical Artist role than my current AD/LA path. So I’m hoping I’ll get some time soon to learn more about scripting and tool-building, to that end Steve’s tips and insight are much appreciated.

I remember I always thought you were a TA before learning you were an AD… you seem very knowledgeable about technical things (though maybe it is a technical understanding rather than full-fledged TA skillset?).

I know firsthand studios will hire technical people as TA’s sometimes without uber scripting experience (especially for leadership positions… I guess this makes some sort of twisted sense). I’m personally not sure what I think of this (at my last job, the ‘TA’ was a total hack, and here, the Lead TA that came before the current one left us some… mediocre… stuff. And if you need any help while learning MXS, feel free to bug me over MSN, you’ve been a great help to the community and it’d be the least I could do (and besides, I need more MXS people to bug over MSN).

On topic though, I have always gotten jealous looking at Steve’s resume- MechCommander, Valve (Half Life, TFC, CS), RAD’s Granny (my fav middleware), Zipper, then Bungie… no turds there, not even starting out! And like any good modest successful leader, he attributes it to “luck.” :stuck_out_tongue:

He definitely bears the standard for TAs/TDs, that’s for sure. If you ever get the chance to sit down and talk to him just about anything, i definitely recommend it. I don’t think i ever have a single conversation with him where i don’t learn at least 2 things or pick up a new way of looking at something. . .great guy to work with, definitely.

I think we’d end up talking about Roman History. I read much more of it than research papers.

Oops, I totally missed Adrian’s byline in there, Adrian thank you!

You got it right Rob, I think I have a technical mindset but I’ve historically been pulled into the AD/LA role which has been fun too. Anyhow I think I’ll take you up on that offer, once my plate clears a bit.

No problem! With him being such a well, prominent figure for technical artists, I figured he’d be a great guy to interview. I am working on some other interviews that I’ll hopefully get posted up within the next couple of weeks.

It’s good to see I’m not the only one who feels this way whenever Steve and I get a chance to chat.

I consider Steve the patriarch of our field. His early GDC talks were great overviews of the main concepts behind rigging characters.

I’d recommend attending any talk or roundtable he participates in at GDC or Siggy and flagging him down in the conference halls whenever you can because he’s an intriguing, friendly conversationalist.

“One thing I always stress, though, is you can’t be a great technical artist unless you’re at least a competent production artist too.”

Well pooh, that kind of blew me out of the water. I am still trying to find out where I fit in the games industry and I was looking at the tech-artist as a possible option. What attracts me to this is the ability to use art tools (I am a fanatic of 3d art packages) and the ability to utilize my technical side. I’m interested in 3d animation, programming, and environment art. But I am not sure that my art skills would ever be good enough to be a “competent production artist”. Doesn’t mean that I can’t get there still, just may have to approach it differently.

[QUOTE=Ephod;6414]“One thing I always stress, though, is you can’t be a great technical artist unless you’re at least a competent production artist too.”

Well pooh, that kind of blew me out of the water. I am still trying to find out where I fit in the games industry and I was looking at the tech-artist as a possible option. What attracts me to this is the ability to use art tools (I am a fanatic of 3d art packages) and the ability to utilize my technical side. I’m interested in 3d animation, programming, and environment art. But I am not sure that my art skills would ever be good enough to be a “competent production artist”. Doesn’t mean that I can’t get there still, just may have to approach it differently.[/QUOTE]

Don’t worry, Ehpod- I fundamentally, positively, wholeheartedly disagree with Steve about that. Ultimately I don’t care at all whether someone is an artist or even cares about art.

Doesnt that just depends on the company?

I think competent in this case doesn’t mean you’re the type that the team goes to for visual inspiration, more that you have enough experience in art that you have a good understanding of how artists approach their tools & pipeline.

Because ultimately your tools are there to ease their workflow, the artists/animators/designers are your ultimate clients. Also they’re your students, TAs often need to teach best art tech practices. My thinking is, if I can’t relate to how artists work, how can I help them work better?

More thoughts on the subject… Technical Artist job description at your company.

It does.

When I worked at Grin the TA team did quite a bit of art production, basically any special item like cloth and destruction on assets created by the artists. There was always the option to sent the asset back to the art team after set-up of course, but that usually took longer to get it finished in the end.

Here at Black Rock I don’t do any art creation at all.

Thanks to Rob, Adrian and Steve, it’s always enjoyable to read through a good interview, keep up the great work! Like a lot of the others I really liked the quote below, it’s something that was brought up at this past GDC as well. I think it’s great to see how broadly it holds true.

[QUOTE=Rob Galanakis;1186]
ST: I think most of us have a common personality trait – a bizarre combination of restless energy and complete laziness. A tech artist is the sort of person who looks at a busted way of doing things and says, “This is ridiculous, I shouldn’t have to spend 5 minutes on this every time” – so he turns around and spends 5 hours writing a tool to get around the 5 minute bottleneck. When I run into one of these things that seems really pointless and time wasting I take it really personally, and I want to beat it into submission.[/QUOTE]

Caring about art and caring about the usability of your work/tool/software are 2 different things.

I guess it will depend on how your team is structured and the overall degree completeness of the technology your content creation team is using (ie: the amount of new tools to implement for the artists to do their job).
However I still strongly believe the people designing the UI of new tools should understand what is the work-flow they will implement their tool into. Otherwise you just take a risk of getting out a product that may most definitely technically do what it is supposed to do, but in a way that’s not really useful to the user of that tool.
The key is having the tech artists/programmers and the users communicate all along the creation of the tools so work-flow concerns are raised long before the tool is finished and hopefully addressed before it’s too late and jeopardize the structure of the underlying tech.

It really depends on the company and how your team is structured.
As a TA I definitely found myself modeling and animating in a lot of cases, even if it was just for proof of concept it still had to stand up in quality.

Think it goes without saying that at the very least you need to know first hand how and why your tools will be used in the production process. I see many good tools being delivered to the floor that are missing some basic functionality, thus making sure no one uses the otherwise feature full powerful tool.