How I Failed My Way to Progress

Last year, I managed to build the worst ever Voice Over dialog pipeline. What started from good intentions and the drive to be organized, slowly deteriorated into an epic mess of versioning issues and inconsistencies between English text, localization and in-game text. It was, by every sense of the word, a failure.

The Backstory

When I started at Anki around May of 2015, I was given the role of “Script Coordinator,” and asked to act as the liaison between the writer, recording studio, game designers, and engineers. I had never before been in charge of an entire game script, but armed with a strong sense of organization and a hell of a lot of enthusiasm, I knew I had the tools I needed to move forward. I started off by creating a spreadsheet in Google Drive, tracking all of our soon to be lines, metadata, and status updates, kicked off to our writer, and sat back to watch our English script starting to roll in.

Almost immediately, confusion started to arise. Because of a tight production schedule, the design team and I felt it necessary to be constantly writing, reviewing and revising. It seemed to make sense, after all, since we could always have the writer and reviewers working in tandem. Also, because of the delicate balance between rolling deliveries and constant review, we decided to ask for all new or revised VO scripts to be delivered via offline methods. And between our writing, reviewing, and localization, the number of working copies of our VO script started to proliferate at a dangerous rate. Like bunnies on steroids dangerous. I kept telling myself, ‘It’s okay as long as I’m careful. As long as I copy and paste Voice Over lines accurately and keep track of different offline versions, I’ll be fine.’ But problems never stay isolated, do they?

Through this gradually emerging chaos, the shit finally hit the fan when we started working to sync the in-game Voice Over audio to in-game text (mostly in the form of subtitles). For this process, our engineering team created yet another Google spreadsheet, except this one had only a subset of the dialog text that appeared in our original document. So, not only was I trying to condense multiple offline scripts down to a single spreadsheet, but I was then copying and pasting a portion of those lines into the engineering spreadsheet that was directly translated to in-game text. And guess what? There were bugs! Loads of them. Most of them were the nasty, hard-to-trace kind that caused up to a half-day time suck for me. But we were out of time for new ideas and needed to make our current solution work. So, I worked long hours, staying up late checking scripts and fixing bugs, until we finally shipped a product that we were proud of.

 

Moving Forward

In January 2016, looking back at the failed mess from 2015, I decided that I was going to learn from my mistakes, and build a better solution. In talking to different department leads, I learned that we neither had the budget nor the time to create a custom solution. So, I started looking into off-the-shelf solutions. After a bit of forum reading and research, I thought I had my answer. (For delicacy’s sake, I won’t name it here.) Certain features of this program seemed amazing, and the drawbacks it had seemed inconsequential. Proudly, I marched up to the producers, shared my research, and got the budget approved for a few licenses.

Unfortunately, I was about to learn that this off-the-shelf solution would also turn into a failure. Initial installation along with early iterations of our new database were fine, but as soon as we started to really put this program to the test, it couldn’t hold up to the volume of work we expected as well as the customizability we’d thought we were getting. Working with this product became painful, as I tried to build band-aid solutions to problems manifesting left and right. But it felt worth salvaging, because after all, we paid good money for these licenses.

Eventually, I started see the mess for what it what was: a ball of spit and rubber-bands holding together yet another crappy Voice Over dialog pipeline. I had failed again. With a bit of a heavy heart, I scheduled a meeting with the same producers I had met with months before, and advised we shut down the use of our off-the-shelf solution.

 

A Pause for Reflection

How was it, then, that I managed to spend over a year creating crappy solutions to problems that seemed on the surface fairly straight-forward? Well, maybe that’s just it. Maybe they weren’t just crappy solutions, but rather the inevitable pitfalls needed to find a better solution? Upon reading my story, some might say that I didn’t think properly ahead or didn’t predict the outcomes of my choices. Or perhaps others might cite my lack of experience as the culprit of bad decision-making. But in all honesty, experience aside, what if finding the solution that perfectly fits our company could only be uncovered through failure? What if failing was a necessary step towards progress?

When I got to Anki, I was given a task that included a problem: how do we manage Voice Over writing, review, recording, localization, and implementation? I solved that problem it the best way I could, using educated decision-making and the tools that I knew I had at my disposal. But realistically, short from having been in that exact same situation before (which I hadn’t), I had no idea how any of my “solutions” would turn out. Did I make mistakes along the way? Yes. But did I do my best to learn from those mistakes and build better solutions? Absolutely.

Failure has helped me figure out which solutions don’t work for our team. It’s like I’m testing a system and failure is showing me the weaknesses in my planning. However, this doesn’t mean that everything I’ve done up until that point should be trashed. Instead, I have the ability to pull apart my solution, find the pieces that are actually working, and use that to create the next iteration.

Recently, I’ve learned an important lesson: the final Voice Over dialog pipeline that Anki creates will not be a silver bullet solution. Instead, it will be a balance between using the tools we have available, creating new tools where necessary, and learning about the way in which our team best interacts with the new systems we create. All of this, would not have been so clearly laid out if it had not been for failure.

 

Moving Forward, Again

In May of 2016, I picked up the dropped baton of creating a Voice Over dialog pipeline and tried again. Only this time, I created a system that was built from the mess caused by my first two failures. First, I went back to the versatility and flexibility of the earliest system: using spreadsheets in Google Drive. However, rather than try to write and review simultaneously, we are going focus on one step at a time. Second, once the lines are finaled, they will get copied into a github repository to ensure that everyone has access to only the master copy of our script. Third, we have created an automated process that takes everything from our github repository, publishes it to our localization web-based client, and then pulls it back when translations are submitted, diffing the new content against the old. Finally, we trashed the engineering Google spreadsheet and are instead pulling the in-game text directly from our master script in github, translating it into JSON format, and publishing it directly.

 

From where I’m sitting, our new pipeline looks pretty shiny. I see a lot of progress, improvements, and promise. I feel confident that when we put this system to the test, we will yield better results than we’ve had in this past. But ultimately, could this system still fail? Definitely. Does that mean it’s worth giving up? Hell no. Because at the end of the day, I’ll just pick up the broken pieces, find a better glue, and try again.

---