MPSE Wavelength

Fall 2025

Issue link: https://digital.copcomm.com/i/1538144

Contents of this Issue

Navigation

Page 27 of 123

26 M PS E . O R G an audio programmer. Not all teams have them! It's critical to have them as embedded as possible with the audio team so that they understand what the creative goals for the game's audio are, and how the audio team is moving forward to achieve those goals. They can obviously contribute lots of useful ideas from their experience, and they bring a level of implementation experience, both in scripting and in native code, that is likely unmatched. I love to have them involved in these discussions to help save us time and effort. As I approach technical problems, I try to evaluate them through a few lenses: • What is the goal? • What is the simplest way to achieve that goal? •What is the performance impact of that solution? •What is the long-term maintenance of that solution? I love audio programmers who approach things with a similar mindset because they can be tremendous allies Some problems need to be solved with native code solutions, and audio programmers are great for helping to identify those situations and executing on them. But those solutions also create a maintenance risk: You only have a limited number of people, maybe even just one, who can solve problems that may arise down the road with whatever your solution is. The solution will likely have dependencies on other things in the game that may break or change, so that audio programmer will then have to go back and fix bugs or refactor the solution they cooked up. What happens if that audio programmer is backed up with tons of work and can't get to it? What if that audio programmer leaves your team? So I generally try to avoid having an audio programmer create a native code solution for a problem unless it's absolutely necessary for practical reasons (meaning it just can't work in script) or performance reasons. But for the issues where those kinds of solutions are needed, there's no one better to do it. I particularly like them when they're very competent at scripting as well and can work in both areas of the game, as they can help the team avoid costly mistakes. Prototyping Systems Early What role does prototyping play in your workflow, and how early do you aim to get audio systems functioning in-game? MK: It's important and I try to get stuff working in-game as early as possible, not just for the benefit of the audio team but for everyone. From an audio team perspective, the sooner you can get your basic systems online, the sooner you can stress test them and start building content to support them. And you can often do this earlier than you think. I once worked on a first-person shooter project that was vacillating between different directions every few weeks: Is it online and PvP? Is it PvE? Is it single player or cooperative? Is it fantasy? Is it science fiction? It was a frustrating experience. The answers to those questions certainly mattered for some parts of our work, but the technical sound designer we had on our team at the time sat down with us and we analyzed what we knew: It's first-person perspective. We may have PvP. The player will be firing weapons, regardless of whether they're fantasy or sci-fi or modern. There may be automatic weapons, there will definitely be single- shot and loop-based weapons. So, we started building systems for weapons, movement, etc., that would support any of the unknowns. In terms of the benefit to everyone else, design needs to iterate. The most fun and successful games I've worked on have been projects where the design team gets to iterate the most and really find and refine the fun of the game. So, I view it as an important role for the audio team to support that iteration and give them whatever they need to find the fun. Sound can provide critical gameplay feedback (think of the sound in Call of Duty when your bullet hits a target, the shield warning sounds in Halo, etc.), so you need to be on call to support the design team with sounds for systems like that as they iterate. This involves throwing away a lot of work as they find the things that work and the things that don't, but this is the process of game development. You can't be afraid to throw things away. Hogwarts Legacy, PlayStation 5.

Articles in this issue

Archives of this issue

view archives of MPSE Wavelength - Fall 2025