Part 1 served as an introduction to the microgame audio project. In Part 2, I discussed the scope of the project and laid out a plan for the upcoming weeks. Now, this blog post is all about the first milestone – the sound design for the project.
Workflow
Planning out the sounds beforehand was a huge time saver – I just had to open the prepared spreadsheet, go through the food groups and start to implement the sounds. For an additional challenge, I limited myself to (almost) only synthesized sounds. My DAW of choice was REAPER, and I used Vital and Pigments for the synthesized source material, as well as FabFilter, Arturia FX Collection and Sound Toys plugins.
As I designed the sounds, I regularly imported assets into Wwise, created appropriate events, implemented them and tested everything in Unity. This allowed me to work in small iterations and see what worked out and what did not. The sounds were designed and implemented in this order: Weapons, Enemies, Player Foley, Player Feedback, Item Sounds, Environment and Ambience.
The previous paragraphs imply that everything went smooth as butter … well, it did not! There are a few things which took me some time to figure out. And there were a lot of workflow improvements, which I’m going to share with you.
Learnings
- Work with rendered audio instead of midi data. As soon as you create a working synth patch, render it to an audio file. Why? First, you commit to it. If it does not work after a few hours break or the next day, scrap it. Second, handling audio files is much easier on CPU. Also, it enables you to think outside the box (pitch envelope, time stretch, pitch shift, etc.) which you might not do with a conventional midi item.
- Understand Unity Assemblies. I started working with Unity a few years ago, and I’m ashamed to say that I just learned about Unity Assemblies. In short, to use Wwise in a C# Assembly, you need to reference the Wwise Type namespace in the Assembly which will be using the AK.Wwise namespace.
- Weapon Animation in Code. I assumed that the animation of the gun’s fuel tanks were done with the Unity Animator. But oh, I was so wrong – it was done via script. It took me some time to find out how to fire the events only when the tank reaches the end position (firing it in the end position only lead to infinite event posts).
- SoundBank compilation removed already assigned Wwise Events in the inspector. This was very annoying. I think it had something to do with the GUIDs of the Wwise events, but I didn’t look into it in detail. I just continued to reassign everything, losing some time in the process.
- Place Rigidbodies, Colliders and AkGameObj on every game object which interacts with AkEnvironment. The gun sounds were always fired from the gun muzzle, which was a separate game object. This means, that the muzzle had to have a seperate AkGameObj, Rigidbody and Collider attached to it.
And finally, the thing you all waited for… drumroll
Workflow Optimizations in REAPER!
Challenging yourself with small projects like this one really sheds some light on your (flawed) workflow. During the process I realized that there were so many things I could improve. Here’s a list:
- Track Templates. I made a track template for Resampling with Vital and Pigments respectively. It’s just one track with the default patch, set to midi in and output recording. Setting up such a track from scratch takes about 15 seconds – with a track template only one.
- Custom Toolbars in REAPER. I created a custom toolbar in REAPER with common actions for media items: Channel Mode (Normal, Mono Mixdown, Mono Left, Mono Right), Volume-, Pitch- and Pan-Envelope. This saved me from some heavy menu diving!
- RenderBlocks from LKC Tools. Hands down, the best tool for quick asset iterations in REAPER. Go and get it! Render Regions are great, but RenderBlocks helped me to set up things much quicker. I just created the blocks and copy-pasted the already prepared filename from the spreadsheet. Also, I created a custom toolbar for RenderBlocks to access most needed actions.
- Use the Media Explorer to directly import your rendered assets into Wwise. Worked like a charm.
- Design with the final peak level in mind, and don’t normalize every single sound.
Wrap Up & Next Steps
Here’s the result on YouTube:
In the end of this phase, the Wwise project contained:
- 140 Media Items
- 16 Busses
- 56 Events
- 6 SoundBanks
- 1 Switch, 2 States, 5 Game Parameters
- 4 Attenuation Curves (just generic stuff), 3 Modulators
Next step: music composition and implementation! Stay tuned! 🙂
DEADLINES
24th April 2022 – Game Design (Level, Interactables, Enemies) + Setup (done)1st May 2022 – Concept, scope and plan for the project (done on 26th April 2022)15th May 2022 – Sound Design and Implementation- 29th May 2022 – Music Composition and Implementation
Deep Work Hours for sound design and implementation: 23