How to record a giant mech: Recording sound design with War Robots

Hi all, I'm Ilya Viktorov, Audio Lead at Pixonic (MY.GAMES). I’m responsible for overseeing the sound design of War Robots. Some time ago, I shared our approach to recording sound effects for our game. This time, I'd like to go deeper into the sound design process itself, highlighting the challenges we’ve faced and the solutions we implemented. So, whether you're just starting out with sound design for your game or looking for inspiration – this article will provide valuable insights and practical advice.

*

Interestingly enough, sound design wasn't a priority for War Robots until the fourth year of development, around 2018. In fact, back then, mobile games didn't pay much attention to sound in general, instead relying upon pre-made assets and basic engine functionality.

And when we finally decided to take sound design seriously, we inherited a large legacy of existing content – making the prospect of revamping it all quite the daunting task.

When crafting the sound design, we faced several tasks dictated by the specifics of a mobile project:

Related:Reworking War Robots' prize system with style and user-friendliness

The FMOD audio library is an industry standard, but at the start of our project, we decided not to use it. (We tried to implement it later, but it was already too late.)

Because of this, we were faced with the need to reconfigure and check a huge number of content units and thousands of prefabs. Even with automation, this would have taken a lot of time and human resources – not to mention the fact that we would have needed to stop the work of other departments while all this content was being processed. So, how to proceed?

Our five approaches to audio production

The first approach is using ready-made assets and libraries. We prefer to use subscriptions rather than buy ready-made huge libraries (the old-fashioned way), where several assets are used, while the rest of them are simply not utilized.

Here, as our main services, we use Soundsnap, Splice and Soundly (which is also a very convenient manager for the audio library). Additionally, when working on weapon sounds, we sometimes use the Weaponizer plugin from Crotos and its accompanying nice library of weapon components.

Krotos Weaponizer

The second approach is sound recording – sometimes faster and more effective to record a sound ourselves rather than searching for an existing asset. This approach is particularly useful when we need a specific sound that's not readily available or doesn't match the exact feel we're looking for.

However, recording realistic sounds for giant robots and other massive machinery can be a challenge. Even if you need some close approximation from real life, it will be very difficult for you to somehow record real heavy machinery. To do this, you’d need to negotiate to be allowed into some industrial area, and there would definitely be some accompanying noise and reverberation. So with this in mind, to get the desired results much smaller devices are used, and then the sounds are specially processed.

In fact, the sounds of mechanisms in games and movies are really things like screwdrivers, coffee makers, door locks, printers, or blenders. A classic example from pop culture: the iconic blaster sound from Star Wars was obtained by just recording the sound of a Slinky toy with a contact microphone. In our case, the largest object whose sounds we used was a garbage truck unloading containers.

Our third approach is synthesis, which is ideal for creating sounds for energy weapons, magic effects, and UI elements. We rely on wavetable synthesizers like Serum and Vital with custom waves, as well as modular systems like Softube Modular and granular samplers based on NI Reaktor.

Softube Modular

NI Reaktor

For simpler sounds like bleeps and sweeps, we prefer to use external synthesizers. My go-to tools include the Novation Mininova, Behringer Neutron and the Minimoog Model D clone.

Sometimes, unexpected solutions arise from experimentation: for instance, we discovered that the retro Yamaha RM1X groovebox has some extreme arpeggiator settings that can produce fascinating glitchy sounds reminiscent of classic interface sounds!

Behringer Neutron

Our fourth approach to audio is taking advantage of neural networks. NNs are a relatively new and exciting area of audio production. While still imperfect, they offer interesting and unexpected results.

We've started using the ElevenLabs generator to create simple sound components, which we then combine into more complex assets. Although we currently can't generate final-quality effects, we can assemble something intriguing from a dozen individual layers. Mechanical and magical sounds, in particular, benefit from this approach.

We also use the Sonic Charge Synplant 2 plugin to create sound variants based on reference files. This plugin analyzes audio files and synthesizes similar sounds, which can then be edited later. Magic effects and energy weapon shots work particularly well with this technique.

Our fifth approach is randomization; this allows us to generate an infinite number of sounds from a small set of source materials. For instance, we can take a few dozen clean "mechanical" sounds, load them into the NI Battery sampler, and randomize the start point, pitch, and volume for each. We can then use a keyboard or arpeggiator to generate more random sounds, from which we select the most interesting ones.

This approach can be combined with synthesis, where we set random values in synthesizers or add a layer with the Synplant plugin. Additionally, we’ve also developed a custom sampler for Bitwig, which loads energy shots from our libraries into layers – low, punch, snap, and tail – and randomly switches between them.

All in all our approach is really a combination of the previous five methods in various configurations. That said, typically, we use the first four approaches for different layers, which we then combine using randomization.

NI Battery

Implementing audio assets

As previously mentioned, we faced some limitations with the basic capabilities of Unity Audio, which led us to develop creative solutions on the fly. To maintain control over sound levels, we categorized the audio into several types: Player, Guns, Mechs, Abilities, Ambient, Music, UI, and Voice. These categories were then routed to two main buses — Music and FX — managed through the settings menu.

The sounds produced by the player's robot are channeled through a separate audio stream, which is prioritized above others and set to be 10% louder. In instances where multiple identical guns are equipped on a robot, only the sound from one gun plays while the others are muted.

To streamline editing and avoid the complexity of managing numerous prefabs utilized by various team members, we isolated sound assets into separate prefabs. For each scene, ambient sounds, music tracks, point sources, and reverb zones are organized within their dedicated game objects, positioned at coordinates 0,0,0. This setup allows for easy editing without impacting the overall scene. A similar approach is taken for all weapon sounds.

This method not only simplifies the editing process but also enables rapid reuse of existing audio assets, eliminating the need to create new sounds when unnecessary. For instance, if a game designer is developing a new weapon similar in functionality to an existing one, they can easily utilize the corresponding audio prefab.

Given that War Robots has been around for over a decade, the volume of content, including audio assets, has significantly increased. This expansion posed challenges in terms of library size. To mitigate this issue, we implemented stronger compression for sounds that are less affected by it (such as certain explosions and hissing effects), minimized the reliance on unique sounds for remodels, and prioritized the use of existing audio assets. This decision was difficult; players expect new, unique sounds for new weapons. However, it was necessary to manage the overall size of the audio library effectively.

Mistakes that developers often make

Not using middleware in Unity. The most common and fatal mistake, which later costs even experienced teams dearly. Some explain this by the fact that the sound in the project is very simple and can be done with standard tools, but this is far from true.

Even in the simplest match-3 game with a dozen sounds, using FMOD, you can save a lot of time and achieve high-quality and interesting sound without unnecessary code and keeping the build size to a minimum. The situation is a little different with Unreal Engine, it has very powerful built-in capabilities for working with audio. They have especially expanded with the appearance of Metasound in the fifth version, but for AAA projects they are still few, so it is better to use WWISE.

Start working on sound too late. Even experienced developers still have the opinion that sound is the least important part of the game, and therefore it is given a minimum of resources and only at the end. As a result, this leads to dissatisfaction of players and the need to redo everything in a working project. It is necessary to prepare all the necessary sound infrastructure at the very beginning and fill it with placeholders.

Not turning to specialists. In small and especially mobile projects, work on sound is often entrusted to one of the game designers who use ready-made assets from public libraries, connecting them in the simplest way possible. This leads to low quality of the sound picture, a drop in productivity and the need to redo everything at some stage.