The Tools of the Trade

Despite the fact that games don't magically make themselves, tools and workflows are generally underappreciated in game development, and have been for a long time. We all know intellectually that the faster you can iterate, the better the results are, especially in a field that is as hard to plan as games. Tools that are fast, easy to use, and that make it easy to avoid or correct mistakes lead to better games.

But work on tools is an exercise in delayed gratification: it is always one step removed from working directly on the game, and so when push comes to shove and we have to sacrifice something, we tend to favor stuff in the game (features) over meta-things like working on how we actually make that game.

Here are some tips and arguments to help you push back against that tendency.

Think beyond just tools

At the start of a project, you may go "Tools: Unity, 3DS MAX, check" and think you're done, but in fact the tools themselves are only a part of the situation. I find it better to focus on workflows - how tools are used together, and in which order - rather than on the tools themselves. "Tools" focuses the attention on a magic application that you buy or build. "Workflows" focuses more on getting things done using multiple steps and programs. After all, the important thing is that your team can work effectively and efficiently: the tools are just the means to do so.

Looking at workflows means you can prevent nasty problems like "We have to go back and forth between these programs too often and it's slow" or "When the character is in the game and we can see what it looks like, we can no longer go back to our modeling tool to make changes because we would lose the skinning data". Or "Our engine doesn't work well with our revision control system." Revision control - using Perforce or Git or Subversion - is a big part of modern game development workflows, and there's a lot that can go wrong there. By focusing on what people are actually trying to achieve and how they do so, ideally before deciding what you need to buy or build, you are more sure to catch these kinds of problems.

Think about all the workflows

"Everyone on a game team is there to contribute to that game. In other words: everyone has work to do. And yet, when we talk about tools we tend to primarily talk about art, level design, or audio tools"

Everyone on a game team is there to contribute to that game. In other words: everyone has work to do. And yet, when we talk about tools we tend to primarily talk about art, level design, or audio tools. But in fact, everyone has workflows, and therefore everyone's productivity can potentially be increased by paying attention to how they work.

Artists need art programs and Wacom tablets. Programmers benefit from faster CPUs and SSDs, but also from linters, Visual Studio add-ons, continuous integration servers, or pair programming tools. It is conceivable that Excel is not the only tool for systems designers. Narrative designers and localization people will certainly thank you when they don't have to use Excel to work with text. Testers need to enter bugs - have you ever thought of improving their workflow? One company I worked at wrote their own bug database. It was an unconventional choice and their tool definitely wasn't better than what was on the market, but testers could press a controller button to generate a bug report with the player's position, current level, and game version already filled out. The tool also automatically took a screenshot, and allowed you to draw on it, MS Paint-style. Those few improvements made a big difference in productivity.

"Everyone needs to quickly get to the situation they're working on inside the game. Everyone benefits from quickly finding out they did something wrong"

Localization is a workflow I am intimately familiar with. How do you find out if a text is too long in Italian? How do you know if the translators screwed up some technical formatting issue? Testing it by hand? Can you be sure you've seen every text in game? It usually takes less than a day to write a program to test this automatically, allowing your testers to focus on catching bigger fish. Producers and project managers need to know where everyone is at with their work. That's a workflow, and you can optimize it. Marketing people need pretty screenshots - do they have the tools to make those? Is developing those tools in your schedule?

Everyone needs to quickly get to the situation they're working on inside the game. Everyone benefits from quickly finding out they did something wrong. Everyone benefits from rapid turn-around times between editing and evaluating. But I have not seen many companies where these questions get considered for everyone. I have often had to fight for testing tools, or to implement localization tools myself. I am not saying everyone needs the best and shiniest tools imaginable, but if you don't consider every workflow, you won't be able to make the right trade-offs.

Paying attention

Maybe you have recognized some of these issues and you may wonder what can be done. I recommend sitting down and thinking about workflows during pre-production. (In fact, I recommend sitting down and thinking about a lot of things in game development. It's harder than it looks!)

Who needs what to do their job? Which data gets added in which tools? When can people see the result of their work? Can that be optimized? The shorter the iteration cycle, and the fewer other people who need to be bothered, the better. When you have a bigger team, pay particular attention when workflows go across disciplines. Integrating the work of people from different disciplines is one of the hardest things about game development. Looking at workflows forces you to recognize when work involves multiple disciplines.

"Whose job is it to think about tools and workflows? Responsibilities differ between companies, but I have an easy answer. I think it's everyone's job"

Does that sound complex? Good, because it is complex! Imagine if you'd left all of that to chance.

Tools and workflows are everyone's job

Whose job is it to think about tools and workflows? Responsibilities differ between companies, but I have an easy answer. I think it's everyone's job. Anyone in production and management is responsible for making sure production runs smoothly, meaning everyone can do their job and obstacles have been removed. That includes bad tools and workflows.

It's the responsibility of leads and directors that the people in their teams can work effectively and deliver the best quality in time. For programmers, there is always someone on the team who is their client, even if it is their future selves. Given that they're writing a program for someone else, it is inevitably their responsibility to do as good a job as they can to satisfy the requirements of their clients within the given resources and constraints. That means taking into account how their code will be used, how it is part of a workflow.

Even if someone is not a lead, they still have the responsibility to do their job effectively and efficiently. This includes trying to improve how they're doing things, and to try and solve workflow problems, for instance by signaling problems and inefficiencies to the appropriate people and working to design and test solutions.

Conclusion

If you haven't recognized any of the bad situations described above, please let me know in the comments! I'm sure there are companies out there putting a lot more effort into tools than what I consider typical. But I have personally seen and heard of enough project-threatening horror stories related to tools to know it's a big problem that is not easily solved by installing another fancy program. If you have your own war stories, I'd love to hear those too.