Audio programming is a service job. As an audio programmer, you know you’re doing it right when the rest of the audio team is fast, efficient, and happy with the work they’re doing. Sometimes you need to make tools to make that happen. This requires stealing some social skills from production, a little user experience thinking from design, and efficient use of resources from engineering. Here’s a handy walkthrough to help approach the task of making a tool for a member of your audio team.
1: Do you need a tool?
This is the most important step in good tool crafting. Sometimes, a team member comes right out and says they have a less-than-ideal workflow and need a better way to do what they’re doing. But that’s the exception. For a variety of reasons, team members may not speak up if they’re doing something repetitive, error-prone, or overly complicated in order to do their job. It’s your job to spot those pain points and bug risks and find out how to fix them. It’ll take a little bit of social effort. If your team doesn’t already encourage it, make sure to have regular one-on-one discussions with each person on your team. Grab coffee, lunch, or a drink and let them talk about what they’re excited about, what they’d love to do, and what’s frustrating them. This is your opportunity to learn how you can help.
Example:
You just joined a project where the sound designer is creating new voiceover events every time a new situation arises in the game. You then need to write some new code to fire off those events specific to each combination of game state. The whole process is taking longer than you expect, and when the timing of some sounds need to be tweaked, you have to be a part of that process. But the sound designer has given no indication that this overhead is unexpected. It’s time to ask some questions. After talking, you find out that the workflow was put together in a rush to get a new feature out the door, and since it worked, it’s never been questioned.
2: Where does it hurt?
Once you’ve identified that there’s a problem, your next job is to find out as much as you can about it. Ask lots of questions. What are you trying to do? How are you currently doing it? Does it work? Is it difficult to do? Is it particularly prone to human error? Is it repetitive and boring? Does it interrupt the creative process? Have them walk you through their process in person. This is where you begin finding the path to a solution, but pause for a moment before jumping right in to making something. There’s more information to gather before you can make a good plan.
While you were talking, you find that creating all these voiceover events is pretty labor-intensive. About half of the sound designer’s total time spent on new VO is spent setting up this structure for you to hook up. It’s also error-prone, due to the ease at which an event can be missed in implementation, and since it’s low-priority VO, sometimes nobody notices it’s not working. You’re also doing a lot of repetitive work yourself, and the overhead of iterating between the two of you is using up a lot of time.
3: What’s your ideal workflow?
After you’ve identified what’s wrong and why it needs fixing, find out what your teammate would rather be doing. Again, ask lots of questions. What’s your ideal workflow? What would be the easiest way to get this idea from your head to the game? If time, budget, and technology were unlimited, how would this work? Taking a blue sky approach now means you have a clear picture of the ideal situation, and you can later subtract from that based on your constraints. Now is a good time to set expectations. It may not be necessary based on your relationship with your teammate, but it’s important to state that you’re aiming high now in order to reach a compromise later. On the other side, if you bring in the constraints too early, you could miss opportunities to make their job a pleasure to do.
While you’re talking about the problems with this workflow, the sound designer wonders if there’s a way to unify the VO events for this particular class of trigger. Each event is being created based on some combination of game state data. What if they could just build a single event with some state logic, and have the correct VO play based on you setting that state in code? That would let them handle special cases and you might even get some new functionality for free down the road.
4: Is there a better workflow?
Because you’ve followed the information-gathering steps up to now, you might have ideas on how your teammate could improve their workflow without the need for additional tools. Maybe the project can be reorganized to make their job easier. Maybe they’re unintentionally doing it the hard way, and there’s a simple way to do what they want to do. Your job may stop here, and that’s great! Remember, your job is to solve workflow problems. That doesn’t necessarily mean you have to write code to do it.
You might realize that the audio system you’re using already supports setting states or switches based on game logic. Then all that’s required on the sound designer’s part is to restructure all of those one-off events into a tree under a single event. You could then change the code-side implementation to query the game state, set the switches, and fire off the unified VO event. When new game states are added or special cases arise based on certain combinations of game states, most of the time the sound designer can just update their switch tree and it will work. Other times, you might have to add support for an additional switch, but that’s all.
5: Has someone already done the work?
The next step to making sure you’re doing your job efficiently is asking yourself, “has someone already solved this problem?” Maybe there’s a tool out there that you can integrate into the workflow. Most of the time, buying a third-party tool is far cheaper than the cost of making it in-house. Need a way for sound designers to define time-based triggers? Will MIDI files work? Need to process a bunch of audio files before importing? How about downloading a batch processing tool? Again, it’s your job to solve the problem. That doesn’t mean you have to solve it from scratch.
You realize that your audio system doesn’t currently support switch logic. But there are third-party audio middleware solutions that do. You can find one that does what you need, and then determine how long it would take to switch the project to using that. Be sure to weigh the short-term implementation time fairly with the possible long-term efficiency gains.
6: What’s the shortest path?
If you’ve determined that you do need to make a tool, and no one else has already made it, then you’re on to deciding how to make it. Are there multiple components that could independently improve the process? Do them separately, and see if one or two of the components are enough. Is there a quick hack that isn’t particularly risky? Try that and see if you need to go for the robust solution. Work in small pieces, and move to bigger ones only when you need to.
If implementing a third-party tool to do the switch logic is out of scope for the project, then it’s time to break down the problem into smaller pieces. You already have code that’s selecting which VO event to play based on game logic. You already have a mechanism for triggering those events. The sound designer is editing a text file to map the events to sound files. You realize that it’d be fairly quick to extend the parser for that text file to let the sound designer define switch logic, then move your event selection code into a general system for selecting sound files based on those switches.
7: Does it work?
So you’ve made your tool and proudly presented it to the team. They rejoice, buy you beers, and cheerfully get back to work. You’ve still got work to do to make sure you’ve actually done a good thing here. Watch them work afterward. Are they faster, more efficient, and happier? Or is there still a problem with the workflow? Check in periodically and find out how they’re feeling. Go back to step 1 in this process. Maybe something new will shake out, or maybe they’re still having a problem with this workflow.
You check in a week later to see how the sound designer is liking the new system. They’re happy with how fast they can get new VO in the game, but they’ve been running into issues where the wrong VO is playing, or none at all, and they can’t figure out why. Because you’ve been working in that system, you already know that there’s not currently a way to validate what they’re putting in that text file, and you also know there’s no way to debug it from their end. Now you might have a better argument for that middleware!
Keep it up, and you’ll get the opportunity to see some really amazing work from your teammates.