Issue link: https://digital.copcomm.com/i/1538144
28 M PS E . O R G to get their most recent Final Fantasy projects to other platforms for one prominent example. These days I'm assuming anything I touch will be on every platform. I assume Atmos but try to build in a way that we can support Tempest (Sony's 3D audio solution) and Nintendo's Switch 2 spatial audio system. I know very little about the latter, as the system just launched a week ago as I write this, but I'm eager to learn more to make sure the work I do can support it. Headphones are the most used endpoint for our players, so I want to be sure we support that. It's also important to work and test on consoles as early as possible. This is something you will likely have little control over as an audio person, as some development teams focus on a specific platform (often PC) throughout much of production and then bring the console builds online later. Personally, I feel this is a very shortsighted mistake, not just for audio but development as a whole. It's harder to develop on a high spec PC and then cram all of that into a console later. It breeds inefficient dev practices across multiple disciplines. But, regardless, you should be an advocate for getting console builds working on projects you're on and, once they're available, someone on the audio team needs to be working on the consoles regularly and making sure things translate well. Mixing Gameplay and Cinematics How do you approach mixing gameplay and cinematics to ensure both feel cohesive but serve their unique roles? MK: It's important to note there are different types of events in a game that "cinematics" can refer to. There are pre-rendered videos, which are usually designed in ways very much like traditional linear audio post. Often this work is done by different people on the team, or even external vendors. Then there are in-game cinematics, which are moments where the player has limited or no control, but events are played out rendered at runtime in the game engine. I've seen these designed by both internal and external vendors, but they still have to be implemented using the normal audio pipeline in the game engine. When working in either of these scenarios, it's important to have a reference for what surrounding events sound like. For pre-rendered cinematics, you can capture the gameplay moments preceding and following the cinematic, then share them with the sound effects editors and mixer working on the cinematic so they understand what they're building and mixing against. It's possible that, if the core mix of the game or even the moments surrounding the cinematic change, that there will need to be mix adjustments to the cinematic to maintain the seamless integration, so I like to keep track of these and ensure we've always got the PT sessions to return to if needed. For in-game cinematics, I approach it in much the same way, building the assets in a DAW while using video capture of the surrounding moments to help us understand how the assets we're building will fit into the context of the moment. Then as you render out each sound, you've got something that should just work when dropped into Wwise at unity gain. Then you adjust as necessary. Reflection & Industry Outlook "To me, the idea of a sound designer who just makes sounds but doesn't do implementation would be the linear equivalent of a sound designer who makes sound effects then throws them into a folder for a video editor to sync up to picture." Technical Implementation as a Core Skill Something I've been seeing more often in job requirements is sound designers being asked to take on technical implementation. What's your Field recording trip, Mark Kilborn with Tom Todia and Frank Scheuring.