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?

Middleware companies sell complete packages for AI, physics, UI, animation, you-name-it, but what constitutes a “complete package” anymore?  What a lot of middleware companies deliver seems no where near complete, even for the subset of game development technology of which they are supposed to be the leading industry experts.  They release new versions monthly that game studios have to integrate to get lastest features and bug fixes.  Are we game developers, or simply beta testers for middleware companies? 

Many of these companies have great customer service.  They offer support tickets so developers can submit bugs and feature requests, but at this point, they’ve gone from middleware provider to service provider.  They customize a solution intended for the masses to the needs of individual companies, when what they should really be doing is applying the effort spent on maintenance of the current version on developing the next version.  After all, once a few games have shipped on the current product, its viability has been proven.  STOP DEVELOPMENT!  Give us what you have right now and put your development effort into making the next version that much better.

Sure, those companies that shipped games probably needed workarounds.  And the other companies out there with games in development have workarounds too.  Some of the currently supported features have unexpected results, or just don’t give you what you want. But do you really want to wait around for the “fix” anyway?  Waiting around holds up your production.  You have to remember that you are not their only customer.  It may be months.  It may never come.  It could be the fix that breaks everything else in your game.

You can’t rely on it.

So what can game developers do?  Well, the next time you’re shopping for a middleware solution for your project, and the salesperson tells you about the cool new features coming in the next or upcoming release, don’t plan on getting them in your lifetime.  If you can live without a feature, design your game without it.  If it isn’t there now, and you really need it, shop for another solution.  I don’t want to be a beta tester any more.  Neither should you.

Often, tools are created and maintained by a very small group, so any loss to the tools department can cause widespread problems down the road when new features are needed or bugs are found.  Often, the person responsible for a certain aspect of the tool chain is the only one who fully understands it, and the implications that may arise from making certain changes.

The problem is that (most) game companies don’t make money from tools, and the ROI of keeping tools developers around is less apparent than keeping the developers actively working on game projects.  There are also times when the need for tools development wanes, and maintenance is all that is required.  It is tempting during those times to reallocate tools developers to game teams, but this rarely works, as the crossover knowledge between the two is minimal.

So what is the solution?  The key is to know exactly how many tools developers are needed when tools development is at an ebb.  That’s the number required for basic maintenance and bug fixing.  Additional development can be farmed out to a contract company that specializes in game development tools.

Such a company can take the weight off the shoulders of developers so they can concentrate on making games.  Maintenance and full documentation (design docs, user docs and source code documentation) can even be included in the contract.  Expertise is maintained, and even expanded as the tools developer gets a birds-eye view of the industry by working with multiple game companies.  An influx of new ideas and problem solving techniques is injected into every new contract.   

A company that specializes in tools can become an invaluable partner in achieving success for your future projects.  Cultivating such a relationship becomes the contractor’s motivation to deliver high quality work that exceeds the demands of the tool’s end users, while your own company reaps the rewards of happier, more productive employees.

For more information on the benefits of using a tools development contractor, read my whitepaper entitled Build or Buy? Finding the Right Tools Solution for Your Game Company.