Portfolio Larian Tech

Hello! Here are some of the audio systems and generally technical sound design work I have been doing.
Unfortunately, much of my latest work is still unannounced and unreleased so I can only show things in very general terms.
I have also put together a reel with my latest work on already released projects, please check below.
Feel free to have a look, you can ask me any questions here: contactme [at] javierzumer.com

See CV here

Complete Audio Codebase Refactor
Supermassive Games Central Tech - UE4/5 - C++ - Wwise API

As boring as this may sound, this was a crucial process for the future of our projects. My role was to bridge the gap in knowledge between audio and engineering, providing deep knowledge of the Wwise API and the audio team’s needs.

With the upgrade to UE 5.3 & Wwise 2023.1, it became clear that we needed a big series of refactors across our whole audio codebase. This included runtime and editor classes, pipeline tools and package building code. During this process, it was critical to ensure all our audio features and pipelines were correctly migrated. (as we have projects in dev)

I performed meticulous testing and dived into code to give the programming team as much information as possible about bugs, possible improvements and deprecated features that needed to be cleaned out. There was a particular emphasis on decoupling code from the Wwise plugin so future updates are much easier to do.

Audio Emitter Culling
The Dark Pictures Anthology - UE5 - C++ - Wwise

Given a more ambitious project with bigger levels and more exploration, we needed a system that makes sure only relevant audio emitters are audible and active.

The system uses an octree structure to keep track of emitter positions in a very efficient manner. It also takes into account attenuation distances, particular gameplay states and emitter types to make decisions about which emitter should be active. Additionally, I created a caching feature so emitters resume playing looping audio once they become active again.

The drawing to the left should give a simplified view of how this works. The blue square represents the area where we consider emitters should be active, with the listener at the centre. The circles are emitters where the circle radius is the attenuation distance.

The green emitter would be deactivated at this point since its centre is outside the square. On the other hand, the purple emitter would be active, as its centre is within the square. The red emitter presents a different case. Even though its centre lies outside the square, its attenuation radius is still enveloping the listener so this emitter wouldn’t be deactivated yet.

This system allowed the audio team to add much more detail and positional information to environments without sacrificing performance. On busy levels, we went from about 900 total voices to 150.

Enemy AI Driven Music System
The Dark Pictures Anthology - UE5 - Blueprints - Wwise

Our goal was to make encounters feel engaging and exciting, using musical feedback to drive the player’s sense of threat and bridge the gap between cinematic and exploration gameplay.

I created a system that drives music layers based on the enemy AI state. The level of awareness of the player itself is also taken into account and this is used to drive extra music stems based on the player’s vision, hearing and position.

The system can also be used by more proficient players to gain an advantage, as subtle musical cues are played when enemy awareness is increasing.

The whole system has adjustable parameters like response and cooldown times and I also included some useful debugs that showcase information in real-time so the audio team can adjust and make the music implementation perfectly fit every encounter in the game.

The enemy dialogue system and overall game mix also piggyback off of this information so the whole audio soundscape reacts as an enemy encounter progresses.

Door Partial Occlusion System
The Dark Pictures Anthology - UE5 - Blueprints - Wwise

While using the Wwise spatial audio system, we realised we needed a more advanced way to propagate audio through portals beyond just opening and closing them. Wwise 2022 or higher offers the option to specify occlusion and obstruction values per attenuation share set but unfortunately we didn’t have access to this version at the time.

So I built our own solution based on the concept of leaving the portal always opened and applying a normalised RTPC to mimic occlusion. Since doors open and close using an animation timeline, I used the progression of this animation as the RTPC that would indicate how opened a given door is.

The system is also useful to model a door that, despite being completely closed, still lets some audio go through. This could be because the door has a hole, a broken window and maybe is just a particularly thin door. To achieve this, we can just make the maximum RTPC value be less than 1.

That value is then fed to ambience beds and audio emitters that the user can specify on the door actor. I went for this more manual approach because we needed the ability to precisely choose which audio should be occluded and this use case was only needed on very key moments but nevertheless infrequent.

The diagram shows how this would roughly work. If the listener is in the red room and the door is not completely open, we apply the RTPC to the desired actors, which the door itself is aware of. in this case, these are the green room bed and a 3D emitter. We apply this RTPC on initialisation and then also as the door state changes.

Additionally, I added some quality of life features to the system. Firstly, this is opt-in so by default doors would behave the expected way with portals that follow the door state. Secondly, the ambience beds and emitters the user can choose are actually soft references which are cast into hard ones on initialisation. This allows the user to refer to audio actors that are not necessarily on the same sub-level as the door actor. Lastly, I included additional debugs that print on screen the door states and RTPC values.

Audio Event Instances Allocation System
Drop Dead: The Cabin - Unity - C# - FMOD

Since this game was aimed to be released for Meta Quest headsets, we needed to be very careful with voice usage to keep CPU light. The vanilla FMOD emitters create an audio event instance every time you try to play said audio event. This is inefficient for short events that play frequently which is the case for an action game like this one.

I created a system that allows you to set, for each audio event and emitter, a max polyphony value which would determine how many event instances are created for the emitter to use. If we then try to play beyond the maximum polyphony, voice stealing occurs and the user can choose different different ways to do so like oldest, furthest, quietest or based on priority. All of this information is set on an scriptable object audio event wrapper class (see screenshot).

A different use case for the system is relatively infrequent sounds that never play concurrently but are abundant in the game world. For example, in this VR game you can grab many types of objects. Every object has an emitter and an assigned event that plays when you grab it and is exactly the same for many objects of the same type. By default, every single object would be creating its own audio event instance to play this grabbing audio event. This would be wasteful, since the player can not grab many items in a short period of time. For this situation, I added an option where a set of instances (determined by the polyphony value) can be shared among different emitters, preventing the creation of many audio event instances that would barely be used.

Additionally, there is also an option to create the audio event instances beforehand (usually during a loading screen) or just before they are needed (useful for infrequent sounds). Conversely, there are options to determine when these instances are released and cleared which helps keeping the C# garbage collection system at bay. This allowed us in the audio team to strike a balance between CPU and memory usage and deliver the game with excellent audio performance.

For demonstration purposes, I re-built a new rendition of this system, revamping everything from the ground up and re-thinking many of these concepts in a more general way that would fit any type of game. For example, this time I don’t have a scriptable object asset for each FMOD audio event but a new notion of “Event Configuration” which would be defined as “a particular way of using an FMOD audio event description”. Although unfinished, this should give you an idea of what I was trying to achieve. You can have a look on GitHub here. The most relevant classes to check out are EventConfiguration, FmodEventInstanceProvider, AudioManager and AbstractAudioEmitter.

Kinematic Velocity & Doppler Improvements
Personal Project - Unity - C# - FMOD

FMOD includes absolute and relative velocity built-in parameters and also a plug and play doppler effect. The only issue with this is that it only works if the game object in questions has a rigid body AND it is moved using that rigid body. Since the doppler effect is all about the difference in velocity between the emitter and the listener, the latter also would need to be moved via the rigid body. Often times this is not the case in games which makes these features unusable in practice for most users.

I fixed this by adding manual kinematic velocity calculations on both emitters and listeners and sending this information to FMOD myself. I have published a thorough explanation on my blog on how to achieve this, including GitHub links with all the necessary code.

Sound Design Reels

You can hear here my latest technical sound design work. This includes systems I have built using Wwise, Unreal, Unity and FMOD.