Jected Audio
Setting up the Audio for a racing-stunt game hybrid
In this article we want to give you some insight into how we created and implemented the sound of Jected:Rivals. We, that is Audio Director Martin Wöhrer and Technical Sound Designer Manuel Eisl and together we have well over two decades of game development and sound design experience. That said at the beginning of the project neither of us have worked with neither Wwise or Unreal before so what we are presenting here are our ways to solve the problems we encountered but there might be other solutions.
In the beginning of the development we laid out some key concepts that we would focus our efforts on and that shaped most of our decisions. These were the festival, the vehicles, the characters, and a level editor that would allow the players to create their own maps. The festival with its pop-up and DIY character shaped the sound of the game the most. We intended to immerse the players as much as possible and give them an authentic experience. The vehicles should feel powerful, dynamic, and lively and colliding with the rest of the world should be thrilling. Both the commentators and the cast of drivers should be diverse, interesting and react to all sorts of gameplay situations.
The game was planned as an Early Access title and was also planned to have a Level Editor. Because of this we decided that we need to aim for easy expandability and to allow players to define ambiences in a simple way without burdening them with having to tag up levels.
We worked in Wwise and Unreal. We also used the Wwise plugins Rev, Convolution and the Mastering Suite
Vehicles
Source
As the vehicles were an important element of the game, we really wanted to make sure they are believable and given the room to shine. To get this right there were many things we needed to consider and play well with each other. For one we needed to source good vehicle recordings. Pole Position Production is an audio post production company with a long history of recording vehicles for games and movies and we got all our assets from their library. Most of their vehicle sessions provide a lot different microphone angles like engine and exhaust or passbys. Most crucially they also record acceleration and deceleration ramps for all the vehicles. This is important for vehicle models in games as one of the best ways to simulate an engine is with granular processing plugins that usually rely on acceleration and deceleration ramps.
Engine Setup
We decided to give each vehicle an engine and an exhaust sound oriented forward and backward respectively. Initially we used two separate REV instances for each of the sounds but that turned out to be problematic. It was difficult to have the same start and end point in the ramp which then could make them slightly out of sync on playback and cause phase issues between those two sounds. To solve this, we put the two ramps left and right in a stereo file and then created the REV model from that file. Manuel managed to figure out a way to split those two up again and place and orient them correctly on the vehicle. Here is a quick camera pan around our muscle car allowing you to observe the two different sounds:
Passbys
On top of the regular engine sound we also play a vehicle pass by sound when other players drive past us. That way we can highlight these moments as we generally mix the engine sounds of other players lower. It also gives us the opportunity to make use of the nice passby recordings and not just rely on the engine sounds played back with a doppler effect. We distinguish two type of passby sounds. A non-unique whoosh sounds for low speed passbys and car specific ones for high speed passbys. The underlying system, in very few words, works as follows. It regularly determins the closest point of passing to the player and how long away this moment is. If this point is close enough and would happen in less than 0.5 seconds we trigger the passby sound. The reason it is 0.5 seconds is that we cut all our passby assets so that their peak is after 0.5 seconds. Here is a video showing this behaviour. Left is the driving player and that game instance is muted. The right screen is the player that hears the passbys.
Tires & Chassis
Sounds like tires rolling and slipping over various surfaces are important feedback. Out of performance concerns we decided to limit each of these sounds to one instance per vehicle. We still track the underlying surfaces and slip values of each tire but only apply the latest and highest values respectively. Generally this works quite well there are just the occasional damaged roads that quickly change surface types and can sound a bit odd.
We further provide feedback on the terrain by monitoring the compression of the suspension and playing chassis sounds based on that information. In offroad terrain we also play an added layer of chassis rattling for heightened immersion. We also trigger an additional chassis layer on landing after the vehicle has been in air. We distinguish three different intensities of landing: Low, Medium and High.
Collisions
One of the most satisfying sounds to work on were the vehicle collision sounds. We decided to distinguish three impact strengths, low, medium, high, and created a huge variety of sounds for each of them. It was very important to create assets that sound distinct from each other to make continuous crashing feel lively. The visual damage setup for the vehicles is quite intricate and we needed to dumb it down a bit to be useful for audio. For example damage will propagate through a vehicle, meaning one impact could damage multiple vehicle parts. Since we are triggering a collision sound whenever a part gets damaged this could mean each collision triggers multiple sounds. We solved this by filtering out consecutive damage and only play sounds for the parts that were hit first. On the other hand having a detailed setup like this also allowed us to easily place the collision sounds on the affected parts. When a part gets destroyed we would play an additional sound like parts falling off. We also track if a vehicle is scraping along a surface (e.g. a crash barrier) and play matching scraping feedback.
Gadgets
Two of the most fun sound design tasks where the Nitro and the car ejection feedback. For the Nitro sound we took the intake sound of a Dodge Hellcat engine and added some rocket elements to it. Since, in theory, it is possible to have the nitro active for longer than the length of the intake recording we needed to “construct” a max level sound that we could loop. We did this by flattening one part of the sound and stretching it out with Paul Stretch to make the loop less noticeable. The ejection charge sound consists of three base layers (a mechanical one, a steam one and an abstract spinning sound) that change volume and pitch depending on the ejection angle. To emphasise the max ejection angle we added a guitar layer that fades in at higher values.
Music
Selection
It was clear from the start that we would require a lot of music to a) feature lot of different artists and to b) provide enough variety to keep the experience fresh over time. We licensed all the in-game music (about 100 tracks) from a music licensing service and this helped us to keep the cost low while delivering both on these aspects. In close collaboration with the marketing department we determined what music genres we would want to cover for our target audience and then searched through their catalogue to find the best suiting tracks. This was a very cost effective approach but naturally also comes with some disadvantages:
- Tailoring music to certain in-game events was not as straightforward as it would be with a having custom music composed for them. For these elements it could still be good to have a dedicated composer at hand.
- The mastering of those tracks varies a lot. It helped that we often play the music with a speaker emulation effect but when using this approach it’s definitely worth considering ways to unify the mastering somewhat. Many of the tracks also have the option of downloading stems which could give one the option to rebalance the music somewhat.
- It takes time. Databases of a music licensing sites can be extensive and not all musical genres are very homogenous which means one has to filter through a lot of tracks to find the ones that suit your game best.
Implementation
Get Martin Wöhrer’s stories in your inbox
Join Medium for free to get updates from this writer.
To cater to the event aspect of the game world we wanted to make sure to emulate the speakers that are placed all over the maps properly. The idea is that generally the music and commentary VO plays in 2D and once the players are close to a speaker the sound fades over to a 3D version emitting from that speaker. This 3D version also has reverb and distortion applied to it as well as the in-world reverb on top, so it will sound slightly different whether the speaker is placed next to an underpass or in an open area. This was possible thanks thanks to Wwise being able to play multiple clones of the same sound on multiple locations. It will still evaluate the distance to the listener for each location and therefore it’s possible to apply attenuation and distance-based effects. Thanks to a nifty setup from Manuel where each speaker assets will register with a central manager asset during the start of the game this was also really easy to implement. Just drop the “speaker manager” asset in the level and that’s it. Should the players wish to only listen to the 2D version of the music and commentary we gave them the option to turn this system off completely.
The World
As mentioned in the beginning there were two challenges with the world/ambience audio that we needed to solve. One was to support the festival feel of the game and the other being the ease of use for a potential level editor — even though it never was fully realised in the end. To achieve this we built a few systems.
Analyzing the World
When the players move through the world the ambience and the reverb should adapt to their surroundings. In many games this is achieved by tagging up the world, dividing the space up into areas of different ambiences and reverbs. Generally this is a great approach that allows the Sound Designers to create very detailed environments. It can also be very time consuming and late changes of the level layout can create mismatch between visuals and sounds. Since we are a very small Audio team we opted for a systemic approach. Conveniently this also provided us with an easy customisable setup for the level editor.
To analyse the environment surrounding the listener we used a “sonar inspired” line trace pattern. Each time the system is updated it would trace lines outwards from the current meridian and save the hit distances. The update frequency is dependent on how fast the listener is currently moving, so that in fast paced situations the values would be updated more frequently. After updating the values, we condensed the information in three parameters: room size, indoor amount and corridor amount. Those three parameters allowed us to seamlessly transition between different ambience sounds, as well as different reverb configurations. As mentioned before this would have helped tremendously with supporting players creating their own levels. In case a level would require more detail we also added the option to add volumes the old fashioned way which would allow us to override the systemic approach.
The Crowd
The audio for the crowd consists of a looping base layer of audience noise. This sound plays from the procedural crowd spawner volumes that are placed by the Artists and Designers around the map. Similar to the speaker system for the music and commentary one single instance of this sound is cloned and played from all of them. For all the stands we implemented a secondary layer of drumming and chanting. These are a variety of assets that are selected at random and often, when there are multiple stands next to each other, overlap. Finally we also have crowd shoutouts (like “yeah”) that randomly trigger when driving past a group of fans.
Props
The two standout props from an audio perspective are the fans and the moving platform. The fans can be both aiding the players in their progress through the level and can also be an obstacle. They will blow players away and depending on how far they are from the actual prop the force of that push is smaller or greater. So in addition to the fan spinning sounds we needed to add wind feedback when the player is affected by the wind cone. On top of that to make it feel more realistic we are using a volumetric sound emitter to play a soft wind sound from the wind cone so that the transition from outside the cone to the inside and vice versa is smoother. The moving platforms were quite a step up in complexity and not trivial to implement as they all derived from the same base class. They are varied and encompass moving boards, rams, a semi truck and an oversized version of the festival mascot Charlie. In addition that most needed custom sounds created for them they also have very different ways of moving and that would change what drives the audio. For example for the rotating platforms it is the angular velocity, for the ones moving on rails it is the velocity over ground and for the rams it needed to be triggers for the start of moving in and out.
Voice Over
Characters
For the characters we wanted them to be varied, colourful and with interesting backgrounds. They come from all over the world and therefore have all sorts of different dialects. This can be a challenge at times to find the matching actors but our vendors helped tremendously in that regard. One character that is dear to us is Andee the Crash Dummy. For them we experimented whether Text to speech tools would give us a good Android impression that also can be expressive. We settled with a voice provided through the Speechless VO tool and is usually intended to generate temp lines during early production. After we applied some “Android” processing their oddly timed humour and emphasis became very charming.
Commentary
For the commentary we looked at a lot at fun and interesting commentary like the 3Dbotmaker Diecast racing or the Marble Run videos. We wanted to have a duo with an interesting dynamic. Mel being the analytical, statistics focused one who maybe is a tad stiff and Korin the ex-Stunter with a relaxed attitude and makes fun of Mel from time to time. With Adonis Kapsalis and Nina Zenejas we found the perfect actors for these parts. We concepted them to give context to the world through banter and comment on what’s happening during a round. They are played back through the same speaker system as the music.
One interesting problem we need to solve was the fact that the same character can be present multiple times in a racing grid. The commentators referring to the characters by name could be confusing as it might not be clear which one they are talking about. To circumvent this we decided to assign a team name to each player that are based on mythical creatures. That team name then would be the players visual representation in the leaderboard and would be used by the commentators to call them out (e.g. when taking the lead). To reduce the amount of lines we needed to record we decided to stitch most lines that referenced the teams names. The alternative would have been to record a version of each line with each team name and that would have significantly increased our overall line count. We approached this by recording four variations of each team name with four distinct and consistent inflections from our two actors and then stitch them with the other lines. Early tests showed that it is best to have the team name either in the beginning or the end of a line. Stitching it into the middle of a sentence would have matching the various content and performing the line much more difficult.
What we learned:
- Taking this approach comes with a tradeoff, we saved on recording time but making the lines work well and feel natural required a lot of prep time from our side.
- Results varied a lot — to no fault of the actors or the studios involved mind you. Sometimes the stitching worked well but a few times it was impossible to make it work and we had to abandon some of the lines.
- We would recommend if you should ever decide to take this approach try to record all the content in the same session. Voices can be quite different from session to session (actors might just recover from a cold) so having everything sounding consistent helps a lot. Tools like Izotopes RXs EQ match can help but also have their limits
- Using Wwise as a middleware turned out to be a blessing as it would allow us to adjust the individual timings of the team names. That way we were able to conveniently customize the lines if needed and could easily compare the different variations.
Mix & Voice management
Mixing a game like this can be a challenge. You have a lot of big sounds fighting for the players attention and they should all be well balanced against each other. We decided that the centrepiece would be the music, overpowering when close to the speakers and present when further away. All the other sounds are mixed around the music. Commentary, characters and explosions are allowed to be louder. Everything else sits below to varying degrees. A few tricks and tools we used to balance everything well:
- We used the HDR integration of Wwise which in a nutshell allows more important sounds to duck away the less significant sounds. Pretty much all our sounds are being sent to the HDR bus. The exceptions are some UI sounds. Working with HDR can help creating a clean mix but also needs to be carefully balanced as every sound can influence the overall mix and it can lead to strange results if one isn’t careful. For example in our case the music is part of the HDR mix and when the players decide to turn it down the whole mix is affected. We highly advise to double check your HDR relationships in such cases. One future tweak we considered is taking the music out of the HDR and have it only ducked by side-chaining and auto ducking.
In almost all cases oneshots are given a higher level than the corresponding continuous sounds (e.g. starting the Jetwing gadget vs the continuous Jetwing whine)
Wwise also allows you to work very dynamically with the HDR and raising and lowering the HDR level of a sound based on the situation. For example are we lowering the HDR level of vehicles on low RPM values so the ambience can be a bit more present in these situations. - One thing we do a lot to clean up the mix is to distinguish between local player sounds and sounds from remote players and Bots. We do this to ensure that your own sounds (your own car, character and even collisions) stick out. To achieve this we are lowering the volume and adjust high- and lowpass filters of most remote player sounds. We also have sounds that are reserved for the local player, like added bass rumble when they collide with something or someone. Another thing we do is to try to somewhat limit the RPM range of remote vehicles. This is to help with phasing issues when someone uses the same vehicle. This especially a problem during the start of a race when there are many vehicles going full throttle in close proximity.
Distinguishing between remote and local players like that can cause problems with spectators as they can take the player perspective but the code usually doesn’t recognize them as the local player — meaning the vehicle they are spectating would lack presence. To circumvent this we came up with an elegant solution. Instead of checking whether a sound is played by the local player we are checking if it’s played from whatever target the camera is following. That way any spectator is given the same status as the local player.
- Side-chaining and Auto Ducking are very useful tools to give sounds the room they need. The former measures the audio levels on a channel and gives one some control over how nuanced those measured levels should be applied elsewhere. Auto Ducking on the other hand is either on or off independent of how loud the signal is. When using Auto Ducking you want to be careful with putting delays on sounds routed on Auto duck channels as the duck happens when the event is triggered and not when it is playing. For a while we had music ducking weirdly for a few seconds prior some filler commentary lines and that was because these lines had a random delay. When using HDR side-chaining can also be somewhat approximated by giving a sound a fairly high HDR value but then have the attenuation curve drop quickly. For example to allow the audience to overpower the music somewhat when close by but having it become part of the ambience once the player steps further away.
- Another tool Wwise provides that can help clean up the mix are the priority settings one can set for each sound and bus. The main idea is to limit the amount of sounds that can play at any given time and virtualising or even stopping the ones that are less important. Most commonly priority is a matter of distance, closer sounds have higher priority. In a game with third person camera this can be problematic as sounds that are between the listener and your vehicle would be considered to have higher priority. To avoid these problems we generally boost the priority of your own sounds a bit. The only exception to that is again in low RPM moments so that your own idling won’t cull sounds that could be of more interest in these moments.
- As some of the levels contain many props that also play sounds we initially opted to virtualise and pause their sounds when they are not in an audible range. That way it is ensured that the sounds will continue playing once the players are close again. The problem with this approach is that it still will use up processing power and if there are too many virtualised sounds that can become a problem. Because of that Wwise will actually output a warning when there are too many virtualised sounds and we got it a lot on a few maps when there were many props. To solve this we implemented an infrequently triggering sound-to-listener distance check in Unreal. This would check whether a sound was in range or not and would either en- or disable it.
Thoughts
This project had some interesting challenges we needed to solve and a lot of tech needed to be built from the ground up. The initial high developer-time investments in systemic approaches like the ambience systems worked in our favour in the end as it made setting up levels so much quicker. This of course doesn’t necessarily work for all kinds of projects. There are a few things we would have loved to refine a bit more and add more detail to but ran out of time — e.g. recording the whole team to crowd shouts was something we had on the list. We hope whoever played the game had a good time with it.
Acknowledgments
Even though the two authors of this article represent the core of the Pow Wow Audio department many others have contributed. Our stellar interns Lukas Schönwiese and Lukas Penz. Sofia Lissel our Narrative Designer who shaped the characters and the world, wrote many of the dialogue lines and helped tremendously with the casting of the actors. Maria Clevy for help with the characters in the early stages of the project. Our community manager Nathan Webb for helping out with writing commentary lines. Pole Production and Max Lachmann for great vehicle recordings. Pitstop for finding and recording tremendous actors and Speechless helping us out when we needed a slightly more artificial voice for our Android.
