Ghost of Yōtei

Project Goal: In a 3 month turnaround, work with the audio team to implement sound propagation systems for every structure and location in the open world for Ghost of Yōtei.

In such a tight schedule, I needed to be careful with my time management to onboard to internal standards of file organization and workflows, and also rig every location and asset in a AAA open world. Although there were several roadblocks from other teams and departments (discussed below), I was able to meet the deadline, and leave time to fully document the process, as well as tackle any last minute bugs discovered by QA.

Structure examples from the Ghost of Yōtei gameplay trailer

Creating the Pipeline

The audio team was lacking in the Maya skill necessary to make the rigs for their new sound propagation system. As the first and only person dedicated to this task, I had to create the workflow and pipeline myself, communicating with teams like Programming, Environment, Architecture, and Layout in order to determine how I could non-destructively author these sound systems.

For a high level overview, a standard asset would require me to get an understanding of its internal space and variations from procedural systems. If a building is wood, a volume is needed to encompass the space the player can occupy to alter the soundscape realistically. If a sound happens just outside the window, this shouldn’t have the same reverb and attenuation as a sound inside a building, though it should be diminished so that it spatially sounds like it comes from outside the window. WWise has a similar system that goes deeper into it here.

This grey model shows the basic idea. The yellow volume represents the internal space the player can occupy, and the red volumes are what connect two environment soundscapes together to simulate the gaps in the structure. This would make a good first pass before getting into asset specific challenges.

Management of my nodes was crucial to avoid confusion by people on the Environment team. I worked with the Layout team to come up with standards for naming conventions and hierarchy placement to make my work as unobtrusive as possible.

Cross-Team Procedural Roadblocks

The Environment and Layout teams had a custom procedural modeling solution that complicated Maya assets, where a building can have upwards of dozens of variations. For downstream teams like Audio, the rules for procedural creation and management were unknown, so I needed to investigate these tools myself. Working with Architecture, Environment, and Layout, I learned the process of creating and modifying iterations of structures, and used internal tools to keep track of them all. If a modification to a building could result in a window having shutters closed, I would need to make my sound rig procedural as well so that sound would no longer travel through that window in that given instance.

In a simple example, there could be two uses of the same asset, one with a shuttered window and one without. A bulk of the work on my end involved determining all the possible variations of a structure in order to slot in my sound rigging to take advantage of the proceduralism. By modifying the environment team’s methods for my own, I avoided having to individually rig every instance of a building, as well as future-proofing the asset as the game world continued to populate.

Along with the hundreds of structure assets, I was responsible for applying similar rigging strategies for outdoor enclosed locations as well.

Bugs and Documentation

In the final stages of my contract I needed to be on call for any bugs that arose from my spatial rigging. While I conformed to the standards of the procedural workflow, some issues like last minute hierarchy reorganization or renaming would ultimately break references to my sound rigging, and I needed to be quick to problem solve on a case by case basis. I identified these shortcomings in my post-mortem documentation, brainstorming in meetings with other teams how the modular system could be improved to account for downstream teams in future projects. I also wrote extensive documentation outlining all the best practices for this role and common pitfalls I encountered, should someone else need to fill a similar role on the next game.

I love being able to optimize and work with tools between teams in order to translate the needs of one artist to another. I find communication in video game productions, just like any creative team project, to be paramount to its success and efficiency. These are skills I intend to carry on into future projects.