The Tools of the Trade

Making sure a team has what it needs to get things done is everybody's job

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.


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.

More stories

Former Supercell devs raise $5m for new studio Bit Odd

Finnish studio aims to develop games "not based on data but on feeling"

By Marie Dealessandri

Quebec devs fear new language law will hurt local games industry

Bill 96 requires immigrants to access government services only in French after six months, business to draft contracts in French

By Brendan Sinclair

Latest comments (2)

Andrew Watson Tools Programmer 6 years ago
+1 for workflows. Definitely something that a lot of people overlook, but good or bad workflows can really affect development times a lot more than you'd realize. Consistency is also something to keep in mind, especially if you use a lot of in-house tools, since consistent tools (i.e., similar keyboard shortcuts and menus, similar icons, similar layout, and so on) help people who have to jump between tools a lot.

Every time I make a tool or work on an old one I end up learning a bunch of new stuff, whether it's how to structure a big tool better or faster, or what the key things are that users want to be able to do (hint: it's finding things!)
1Sign inorRegisterto rate and reply
Amen! Tools tend to get the short end of the stick most of the time and most often the reason is that "We're too busy trying to hit Milestone X, to spare people to do tools work." It's a viscous circle.

Back in the early days of mobile phone games, I once developed a set of tools that hooked into a database of hundreds of models of phones, their specs and peculiarities. From this I could automatically generate build configurations, pull in the correctly scaled sprites, track bugs against each build for each device, and generate pretty accurate emulators for all of our devices to save deployment time. All when the current workflow was to manually configure all builds, track bugs in an excel spreadsheet and "deploying" a build, meant manually copying it to a shared network drive. It never got approved for wider usage, because there "wasn't enough time" for other devs to evaluate it. It certainly made my life easier though!
1Sign inorRegisterto rate and reply

Sign in to contribute

Need an account? Register now.