01.18Tools Programmer Fundamentals - by Jeff Ward
A while back, after a talk I gave at our local IGDA chapter meeting, I got an email from a recruiter at a local game development company. He was looking to fill a position for a tools engineer and wanted to know what he needed to look for. I never got back to him (sorry!) mostly because I didn’t know what to tell him. What makes a good tools engineer? More importantly, what’s going to make someone want to take a position in tools development over a position in, say, game play programming, or AI programming, or graphics programming? Is there a distinct difference?
I really wasn’t sure of the answers to these questions until recently, and it made me think a lot about… well… you’ll see.
The Fundamental Trait
During my thinking, I think I identified the fundamental trait that makes a good tools programmer, or at least a programmer that would rather be in tools than any other field of game development: the desire to fix things.
This is different from most programmers who enter the game industry. Most game programmers want to create things. They want to point at a portion of a game and say “You see that? I did that. I made that happen.” As tools programmers, we can’t really say that. I worked on Oblivion and Fallout 3, on the game team, but there’s nothing I can specifically point to in the game that I really created. The closest I can get to is that I can point at the models and say “You see that model? I made the tool that made that model more memory efficient on the 360.”
Game programmers want to create, and, in my experience, when you talk to people both inside and outside the industry and say you’re a game programmer, the first thing they’ll ask is “So what did you do on the game?” expecting that you’ll be able to point to something specific. Gameplay programmers can say “I made that system work.” AI programmers can say “I made that person move.” Graphics programmers can say “I made that thing render and look good.”
Tools programmers can really only point at the team and say “I made that work better.” And honestly that’s how we want it. We take joy in oiling the machine.
The problem with the fundamental trait is that it’s not the trait that makes people enter the game industry. A programmer that takes joy in oiling the machine can do so in almost any industry, and, unfortunately, the game industry offers some of the worst hours, worst pay, and worst return on emotional investment of any programming industry. So, the only people you’re going to get looking to be tools programmers are going to be those that are attracted to the game industry in the first place, and the problems that it stands to solve. In my experience, this means creative people.
The Fundamental Dichotomy
Because you’re working with creative people, game industry tools programmers not only want to oil the machine, they also want to take part in its construction. Like most good programmers, good tools programmers want to constantly try new things, learn new technologies, and generally broaden their knowledge and hopefully find a way to improve your tool chain as a result.
The dichotomy here is that, at some point, you need to stop these creative people from being creative, and earlier than you would the rest of the game team. They need to stabilize their tools for use by the team, and therefore they enter support for code a lot sooner than the rest of the team, and support is the one thing creative individuals dread. It means the end of creative solutions, and the start of debugging drudgery. Keeping a balance of both is tough, but necessary, to keep the best tools programmers on your team.
Achieving the Balance
In my opinion, there are a few things you can do to help keep this fundamental balance between oiling the machine and constructing the machine. It boils down to the fundamental roles of your tools team during the different phases of a game’s production.
During pre-production, give your tools programmers some time to be in full construction mode. Allow them to try new things, new pipelines, new technologies. Let them look into converting the build system to Erlang, rewrite your Win32 tool in C#, or improve the interface on many tools. This is a prototyping phase, and should be labeled as such. Things made during this time do not necessarily need to be working, just prove that something will be more efficient than what is already available.
During code production, you should select the prototypes that make the most sense to implement and implement them. Here, your tools programmers are working very closely with the other teams to make sure all of their needs are going to be handled. They’re constructing the tools and letting out creative energy, but the tools now have clients (the team) and the client’s needs have to be met.
As the game enters production, the tools team needs to transition to support and minor improvements. At this point you’re mostly looking at bug fixes, but all of your tools programmers should be researching how well tools are doing “in the field” and look for ways to improve interfaces and save other team members time, either now with minor changes or during the next phase. When code lock down occurs, this should include tools, and the team has entered support mode.
However, once code lockdown occurs, the tools programmers, provided they have time, should be already entering pre-production on their new tools. Now is the best time. The problems of their technologies are fresh in their mind, and if they can fix them now, when more of the core team moves on to pre-production they can start being productive immediately with new tools.
This cycle helps keep your tools programmers creative, and helps them really point to the whole process and say “I made that work better,” which is exactly what they want.
What do others think?
As an aspiring tools programmer, I’ve asked myself the same question: Why do I keep wanting to do one of the least glamorous programming jobs in the industry?
The article hit the nail right on the head. By nature, I’m compelled to fix things and make pipelines as slick and automated as possible. The most rewarding part of my career is when some process that used to take hours suddenly gets reduced to 10 – 20 minutes.
Something else I’ve noticed, is that Tools Programmers get to interact with more people throughout a studio. It seems as though tools programmers get to work with just about every single discipline. This can offer some refreshing variety during projects, but requires a person who can communicate with all kinds of people.
All in all, very nice article!
January 18th, 2010 at 11:48 am
I have also asked myself that question, and for me the answer is a little bit different. I really enjoy helping people. I also really enjoy making processes work better, but in the end the important part is helping people.
I used to tell people that if people in the game industry were rock stars, I was really a roadie. It was my job to help people get their work done. I loved it when I could take a process and automate it. I loved it even more when I could take that eleven-teen step manual process that took one person two days to do and turn it into a mostly automated 3 step process that took that same person 10 minutes. That meant that the person I just helped could spend the rest of that 2 days doing something else, like making the game even more awesome.
I also enjoyed talking to designers and artists (who do in fact speak a different language than programmers do).
Really, everything I loved about being a tools programmer revolved around helping people, and getting direct feedback on how what I did was helping.
January 18th, 2010 at 1:56 pm
I really enjoy being a tools programmer. But I don’t think I would limit us to a single fundamental trait. I think we’re a lot like our tools, there’s usually a lot of things that go into making us tick.
I would also add:
0) I agree with the ‘helping people’, trait. It is one source of the desire to fix for me.
1) The jack-of-all-trades.
2) Can handle criticism, because hes going to get a lot of it.
3) Wants to understand / identifies with his audience.
The pattern I’ve started to develop for tools developers is that they are very skilled / masters of a generic technology; and mad GUI skills. (.Net/C#, STL/MFC/wx/C++).
To go along with this generic mastery is a high amount of interest spread over many different areas. They know something about rendering, animation, physics, networking, gameplay, sound, databases…etc.
The result is someone who can understand enough of the problem he needs to solve in almost any situation very quickly. Very much the jack of all trades.
Being able to handle criticism, should be obvious.
The other part about identifying or understanding their users is a developed skill I think, but still very important. Here is an example scenario that expresses what I’m getting at.
This isn’t necessarily true, but if you’re a physics expert, I bet your physics tool will be very accurate with lots of scientific terms expressing (if I was also an expert) very correctly the parameters they tweak. I bet it will have tons of options. And I bet every artist / level designer / gameplay programmer will hate you for creating it
Unless you are paying attention to your audience, you can make the tool for someone like yourself, an expert. These kinds of tools usually have a lot complaints universally starting with the phrase,
“Look, all I’m trying to do is…”
If you’re not thinking about it, it’s very easy to forget the user in the hunt for “the fix”. When in the end, “the fix” may have a terrible workflow, brittle, difficult to understand as a novice in the subject matter.
So it’s pretty fundamental that in your search for “the fix” you don’t lose track of who you’re doing this for. I can only best express this trait as, someone who understands / empathizes with their users.
January 18th, 2010 at 11:18 pm
I’m a bit different again – I’ve put a lot of effort into and have enjoyed writing tools for the past 20 years. Firstly because I couldn’t afford to buy 3D studio (this was before MAX) and later because I enjoyed it and the creative freedom making your own tools brings.
I’ve been employed as a graphics programmer, artist and as a tools programmer; in the early days, all three at once. All in all, I find tools programming the most satisfying as it brings everything together.
You need to have some artistic sense and actually use the tools yourself, or you’ll find it harder to understand the artists’ needs. Knowing graphics programming is also a must for the sort of tools I make, so I get to use those skills too.
On the other hand, you need to be thick skinned (the other guys get requests and complaints on forums, tools people get them all day, all the time) and be prepared to put in your crunch when everybody else is going home on time (and then probably again when they’re crunching).
I’d say it’s a little less like being a roadie, more like being a bass player. You might not be at the front all the time but you sometimes get to set the rhythm.
January 19th, 2010 at 1:09 am
I personally happen to think that *empathy* is one of the most important traits of any programmer, not just the “tools” programmer. Everyone including those who design low-level systems need to consider how what they do will affect the end-user who will eventually use the code in one way or another to try and build a game.
Also, the distinction of “tools” and “systems” programmers is unhelpful and probably leads to the mess of crappy tools so common in games development. All programmers need to take responsibility for the whole stack — low level to high, front-end to back-end. Otherwise there’s bound to be disconnects and the systems programmer might end up solving problems that don’t exist, and the tools programmer might need to invent another layer of abstractions on top of the low-level abstractions just because the low-level abstractions are incomprehensible to end users.
January 19th, 2010 at 4:47 am
I am certainly no expert but i agree with many of the comments. You must be a good listener and an even better observer to best improve productivity. A lot of time can be lost working on low priority features.
February 11th, 2010 at 9:23 pm
[...] But it is true that tools programming is rarely a position of high visibility. As Jeff Ward recently wrote in an excellent post over at the IGDA Toolsmiths SIG: [...]
July 26th, 2010 at 7:46 pm