Futureworks Degree Show - 14/06/19

Yesterday I attended the Futureworks degree show, and had an absolutely fantastic time!

View fullsize

My banner and stand at the Futureworks degree show, just before doors opened at 4! I presented my audio showreel alongside my Honours project, a full audio re-design for the Unity 3D Game Kit that uses both Unity’s audio engine and Audiokinetic’s Wwise.

It was a really great experience talking to the various recruiters and developers who attended the event, as well as a being a good opportunity to catch up my very talented coursemates and see all the amazing work and projects they’ve completed over the past three years.

While it’s sad on one hand that our time studying together at Futureworks is coming to an end (save for graduation ceremonies), it’s of course very exciting to see where everyone from our year goes from here. With the high level of talent and string work ethic on show yesterday however, I’m sure the 2019 graduates will go from strength to strength and find really cool opportunities in the industry in no time. Hurrah!

Dry Ice Recording Session - Futureworks 07/06/19

Brrr…I had a really fun (but chilly) recording session yesterday with Alex Larumbe and Adam Whitehead recording a variety of dry ice sounds in the Futureworks dialogue booth.

We recorded a whole bunch of great sounds with the dry ice by manipulating it in differernt ways - e.g. crushing it in our (gloved) hands, scraping it with metal objects, and dropping it into hot water to name just a few. It was quite amazing to hear the range of sounds we could produce just through these simple techniques alone; squeezing and crumbling the ice by hand produced subtle creaking and cracking effects, touching it against metal props made a variety of shrieks and squeals and submerging a whole block in hot water produced quite possibly the best bubbling magic cauldron sound I’ve ever heard! I’m looking forward to playing around with these recordings in Reaper to see how I can manipulate them further…once my hands have warmed up again of course!

View fullsize

Dangling this metal chain onto the dry ice sounded cool, but tightly wrapping and squeezing the chain against the ice block sounded even better!

Futureworks: Year 3 Complete

Wow, I’ve finally done it! I’ve handed in all my assignments for the year!

Looking back, I can’t believe how fast the past three years have just flown by. It feels like such a cliche to type out, but it’s true; I feel like I only just started the course yesterday. How time flies when you’re having fun!

Now I’m in that rather anxious phase of anxiously waiting for my final marks to be published. However, regardless of how everything turns out results-wise, my time at Futureworks studying game audio has been absolutely amazing, so I thought it’d be a fitting moment to express a couple of important thank yous to the people who have made my time on the course such a happy and joyful experience.

I feel extremely grateful and very lucky that I’ve had the opportunity to get to know and work with such an awesome and lovely bunch of folks over the past three years. Joe, Josh, Nathaniel, Alex, Adam, Aaron and James; if you’re reading this, you guys are the best! Cheers for being a bedrock of support, love and humour, even to a weirdo like me from the ‘wrong’ side of the Pennines! It’s going to feel really strange not catching up with you all weekly in room 201 going forward, but it’ll be fine because we’ll keep in touch via our various daft exploits on The Forest, PUBG and Sea of Thieves instead! I seriously can’t believe how quickly our time at Futureworks has come and gone. Here’s to many more years of friendship, and all the best to each and every one of you as we make our way into the industry.

The Game & Interactive Audio class of ‘19! From left to right: Moi, Josh Hindle @JHindleSound), Alex Larumbe (@Pheryl), Joe Foulds (Foulds_Joe), Aaron Turner, James Balshaw, Nathaniel Fox (NathanielAudio) Adam Whitehead (@AdamRWhitehead) and Joe Shorrocks. (Photo by Josh Hindle)

I also want to say a big thank you to my personal tutor Joe Shorrocks for his help, guidance and support from day one of the course. You opened my eyes to all the possibilities of game audio and the exciting places it can go, and catalysed my interest and passion for audio implementation. This massively helped to set me on the path to developing into a capable and confident sound designer, and I’m grateful for all the knowledge and advice you’ve passed onto me and my course mates these past three years. Thank you! :)

Here’s to the BGIA class of 2019, and I wish us all every success for the future!

Honours Project MU3401 - Week 21

Unity GUI Attributes

Learnt how to use attributes in my Unity scripts to make them easier to parse. This was initially thanks to seeing Mahesh Athirala’s recent tweet on script headers. I then followed this up with more searching about the topic to find this handy article by HolletGaming and also this helpful YouTube tutorial by GameGrind.

Aside from helping to visually de-clutter my scripts, I can also use attributes to make my scripts easier for myself, and potentially other designers to use. Bearing in mind Cormac’s feedback about demonstrating how the work I do as a Technical Sound Designer makes the implementation process easier for less technically-inclined sound designers on a team, I decided to try and include tooltips on the important parts of my scripts. This is so that a designer can just hover their mouse over a section of the script and get a pop-up text tooltip to remind them which audio assets should go where , without them having to open up the script and go rummaging around in big chunks of code that they might struggle to understand.

Unfortunately however, when trying to set up tooltips for Wwise-type objects, the tooltips don’t seem to be working. I’ll keep trying to work out how to get them to work, but in the meantime I have managed to get the [TextArea] attribute to work, which would allow me to write instructions and details into my scripts in a more overt albiet less elegant way.

View fullsize

Original Footstep Switcher Script

View fullsize

Header Attributes added into C# Script

View fullsize

Footstep Switcher Script with Header Attributes

No Footstep Switching for Enemies?

Still having no luck with setting up a decent footstep sound switching solution for the enemy characters. Either all the chompers get set to the same footstep material (which is too general), or just the one specific chomper game object that enters the collision box has switchable footsteps and all the rest do not get affected by collisions at all (which is too specific). Will keep puzzling out a solution, but in case I can’t work out something suitable in time, I might just go with having switchable footstep sounds being a feature of the player character. I don’t think this would be too immersion breaking, as the enemy characters aren’t humanoid in design, and therefore would have believable in-game reasons for having consistent footstep sounds. For example, the grenadier’s metallic footstep sounds could be realistically uniform regardless of surfaces due to the character’s sheer size and presumed weight. The chompers and spitters could have similarly believably limited footstep sounds due to their slimy, gooey look to their skin, which could suggest that wherever they walk their footsteps could sound plausibly wet all the time.

Sam Casey Composer Meeting

Had another meeting with Sam Casey, the composer for my Honours project, to check in with how the music is progressing for the project. Sam has agreed to deliver to me 2-minutes of the ambient theme (presumably for Level1?) and 30-seconds of the music for the Grenadier boss encounter for next week (Week 22, commencing 11/03/19).

I am growing slightly concerned however, that Sam isn’t following the brief directions that I set out for him to follow. I reminded him of the details and specifications I need the music files to be in, in accordance to the Music Design Document I provided him access to at the start of his involvement with the project. Upon trying multiple times to clarify exactly what I need in terms of music assets - base ambient and combat themes for each level, with separate stems for each enemy type - Sam wants to have a go at writing a self-contained ambient music section, and then a separate boss combat theme for the grenadier section. As I have enjoyed the music drafts he has supplied me previously, I am willing to indulge his wishes for now, as his musical additions would be of great benefit to the project. However, if he continues to not follow my design instructions, then I might have to consider alternative options for the score.

My big worry is that he doesn’t seem to grasp the flexibility of design the score needs to have. Transitions between ambient and combat themes need to happen instantaneously, and not work according to linear time measurements. I want to make the best use of his skills as a composer, so rather than have him write an 8-minute track for one section (that the player might only hear 30 seconds of) I’d rather he focus on making shorter, more modular, looping assets for all the sections/encounters I need, as I laid out in the Music Design Document.

I shall await to see what materials he delivers to me next week and I’ll make a decision as to how I should proceed from that point.

Mark Kilborn - 2015 GDC Audio Bootcamp Talk: Technical Sound Design

Watched Mark Kilborn’s excellent 2015 GDC talk on the role of the Technical Sound Designer. This talk was very useful in terms of clarifying what the role of a Technical Sound Designer actually is, and reliving in the sense that it validated the work I’ve been carrying out for my Honours project in the 3D Game Kit. In particular, during the closing section of his talk where he outlines actionable steps for budding Technical Sound Designers to pursue, my Honours project is absolutely helping me to achieve the first step - learn game engines and middleware.

Talk Notes

• Technical sound design is the “Grey area between sound design and audio programming.”

• “Technical sound design is becoming more and more important, especially in larger-scale games like Call of Duty and other big franchises.”

• “People that are technical sound designers are generally [in]… hybrid roles…a person who can do programming that also can make sound effects, whereas a sound designer might make sounds and just put them into the world…”

• The technical sound designer is the guy you go to with a really complicated audio problem - e.g. in Call of Duty, when needing to change footstep sounds in relation to the water height in a room.

• Some studios have the technical sound designer as an isolated/dedicated role, but sometimes it’s just a skill you have to focus on wherever you are working, especially on smaller projects.

• Technical sound designers don’t do a lot of sound design, but do design some sounds.

• They tend to deal with problems that are a little more challenging than just basic sound hookups.

• Considered the “audio equivalent of a gameplay programmer”.

• TSD does not do low-level engine programming, but does do some programming/scripting and helps build systems.

• “Implementation is half of the creative process.”

• “Rendering your WAV file out of Pro Tools is not the end of the process, it’s the beginning of it.”

• “Attaching a C# script to an object in Unity is considered scripting rather than programming, although they are both kind of the same thing.”

• “Scripting is really really powerful.” You can do a lot with scripting.

• Scripting allows technical sound designers to program features that non-audio programmers will not have thought about. It means that you don’t have to rely on others to design a feature/system for you.

• Regular use of a script throughout a game might lead to its eventual conversion into a code feature of the audio engine. Script feature > Reuse > Code feature.

• Scripting allows the sound team to write their own tools - e.g. audio editing interfaces, functions that normalise files, or sample rate/bit-depth convert them.

• How to be a technical sound designer? Learn game engines and middleware and learn how to program.

• Learn how to use Unity, Unreal, FMOD and Wwise; these resorces weren’t available 10 years ago! Think about how to implement sound so that it is dynamic, and that the player can interact with it.

• Dissect existing games, try to break their audio systems during gameplay to figure out how things work.

• Learn programming; learn C# with Unity, learn PureData.

• “[Learn] C++ if you’re really adventurous, although I wouldn’t necessarily start there.”

• “You don’t have to have a computer science degree to do [technical sound design]…You can kind of hack your way through it.”

• IMPORTANT POINT FOR HONOURS WORKFLOW - “[At Raven Software] before anything complicated, before we even design a sound, we’ll actually go implement it first.”

• Printing text/string messages to console gives the team a better idea of how they actually need to build assets to then implement them into the system.

Ellen Staff Swing Sounds Implementation

• Implemented placeholder sounds for when Ellen swings her staff into the PlayerController script.

• Reminder that all sounds in the PlayerController script have to be played back using hard-coding, because Wwise-type object selectors will not appear in the inspector once compiled.

Applying Script Changes via Prefab Updates

Learnt how to apply changes to the underlying prefab for a game object. This means I can apply global changes to all assets of the same type simultaneously (e.g. all the chompers, all the destructible boxes). This means that rather than having to plug Wwise events into the Wwise-type selectors in the Unity inspector for every single game object in a level, I can simply add them to one instance of a prefab, hit apply and then those changes are automatically applied to every similar game object. Brilliant!

View fullsize

After changing the name of the Wwise variables in the Damageable script, the Wwise box destruction event was reset from all the destructible boxes I’d previously set up in the level. Rather than having to tediously reapply my sounds to every individual box in the level, I just re-implemented my sounds on one destructible box, and then hit apply in the Unity inspector to re-implement the Wwise event to apply the change to every other box in the level. What a time-saver!

Ak Ambient Script + Environment Layer

Encountered another annoyingly unique issue of the Unity 3D Game Kit. Ak Ambient Scripts did not function properly if the game object it’s attached to is not set to Environment. I struggled for ages trying to figure this out when implementing the sound for the staff aura; eventually I stumbled across the solution by checking the details and differences of the Ak Ambient script between one of the crystal door switches and the body of the staff pickup.

SOLUTION - actually, this problem had nothing to do with which layer an object is currently part of, and in fact was much simpler fix. By comparing my LoadBank script to the default Ak Bank script on the WwiseGlobal game object, I noticed that my script was set to load the Main soundbank on game start, and not on awake.

View fullsize

Comparing the differences between my LoadBank script and the Ak Bank one helped me to identify that I was initialising the load-in of Ak Ambient emitters incorrectly.

As Ak Ambient sounds need to be initialised before the game actually starts, this is why they were inconsistently playing back. I’ve now edited my LoadBank script so that it loads the Main soundbank on the Awake function, rather than Start.

Original LoadBank Script (Loads on Start Function)

using System.Collections;
using System.Collections.Generic;
using UnityEngine;

public class LoadBank : MonoBehaviour {

    public AK.Wwise.Bank soundBank; // This creates a dropdown menu in Unity editor for soundbank

    // Use this for initialization
    void Start () 

        

    

    // Update is called once per frame
    void Update () 
        
    

New LoadBank Script (Loads on Awake Function)

using System.Collections;
using System.Collections.Generic;
using UnityEngine;

public class LoadBank : MonoBehaviour {

    public AK.Wwise.Bank soundBank; // This creates a dropdown menu in Unity editor for soundbank

    // Use this for initialization
    void Start () {

    }

    void Awake () // TB - Added this so that Ak Ambient Scripts load properly
    
       
    

    // Update is called once per frame
    void Update () 
        
    

Progress Loss

Unfortunately, while attempting to set up the source ambience for the acid pools in Level 2, I appear to have irrevocably broken my game build. I’m not entirely sure what happened, but it occurred when trying to place multiple emitters for the acid pool sound’s Large Mode. In attempting to drag out multiple emitters from the acid sound’s game object, I appear to have dragged and moved the floor/collision map of the level instead, and believing I had just placed a second emitter correctly (and not just completely fucked up the floor of the game), saved my project. While this in itself should have been just a minor setback, I then regrettably discovered that the most recent backup of my work was from approximately 2-weeks ago, which means I have lost quite a significant amount of work. I tried in vain to fix this no-floor problem myself, but no matter what daft ideas thought of (lots of desperate clicking and dragging lots of game objects around in the game world), there was nothing I could do to save my build.

I’m absolutely furious with myself for enabling this setback to occur, as I usually pride myself on making regular timely backups of all my work to prevent this exact scenario from happening in the first place. I think the reason I dropped the ball and forgot to do routine backups of my work is due to the fact that I’ve been on a bit of a roll progress-wise these past few weeks, and I got so swept up with the speed and momentum of the latest advancements I was making to the project that it just slipped my mind in and amongst all the other tasks I have to complete for my other modules.

While this development is sickening, I only have my own hubris to blame. I’ll have to re-implement the majority of the scripts and sounds I spent the past two weeks working on, which will take some time. Hopefully this won’t set back my overall progress on the project too much. I will ensure I make far more frequent backups of my work for the remainder of this project.

Ellen Shield State Switch Setup

Created a new Wwise state group called ‘EllenShield’ which corresponds to whether the player character’s shield is active. If the player receives damage, then the player becomes temporarily invulnerable for a few seconds, and a blue forcefield material is applied to the character model. When the player becomes vulnerable to damage again, the material is turned off to let the player know that they can be hit and receive damage.

View fullsize

The WwiseEllenShield script with On and Off functions, attached to the Ellen game object.

To help reinforce the player’s awareness of this important gameplay system, I have written a new C# script, ‘WwiseEllenShield’ (attached to the Ellen game object) which calls two functions, ‘ShieldActive’ and ‘ShieldInactive’, which in turn control two states, ‘ShieldOn’ and ‘ShieldOff’. At the moment, I’ve set things up in Unity and Wwise so that when the ShieldActive function is called, the Wwise Master Audio Bus gets a flanger and an extreme high-pass filter effect applied to it, to aurally imply to the player that the character is currently closed off from the outside world and not affected by enemies once their shield is on. When the ShieldInactive function is called, the flanger and high-pass filter are removed, to imply that the player is once again vulnerable to attack from the enemies in the world.

using System.Collections;
using System.Collections.Generic;
using UnityEngine;

public class WwiseEllenShield : MonoBehaviour {

    public AK.Wwise.State EllenShieldStateOn;
    public AK.Wwise.State EllenShieldStateOff;

    public void ShieldActive()
    {
        Debug.Log("Shield On");
        // AkSoundEngine.SetState("ShieldOn", "EllenShield");
        // AkSoundEngine.PostEvent("ENE_GRE_FOO_EVE", gameObject); // Shield Activation Sound
        EllenShieldStateOn.SetValue();
    }


    public void ShieldInactive()
    {
        Debug.Log("Shield Off");
        // AkSoundEngine.SetState("ShieldOff", "EllenShield");
        // AkSoundEngine.PostEvent("ENE_CHO_DIS_EVE", gameObject); // Shield De-activation Sound
        EllenShieldStateOff.SetValue();
    }
}

To ensure this state group resets properly to ShieldOff when the player restarts the game, I have also added a state reset line of code to the LoadBank script, so that if the player quits the game while the player is still invulnerable and then immediately starts the game again, the EllenShield state group isn’t still set to active when the new game initialises.

using System.Collections;
using System.Collections.Generic;
using UnityEngine;

public class LoadBank : MonoBehaviour
{

    public AK.Wwise.Bank soundBank; // This creates a dropdown menu in Unity editor for soundbank

    // Use this for initialization
    void Start()
    {

    }

    void Awake() // TB - Added this so that Ak Ambient Scripts load properly
    {
        soundBank.Load();
        AkSoundEngine.SetState("EllenShield", "ShieldOff");
    }
}

Engines and Middleware MU3410 - Week 14

Assignment Submission

I’ve submitted my Engines and Middleware assignment! On the day, I was a bit of a stressed mess, and I was rushing to get a few final little tweaks and finishing touches done for the deadline, but on reflection, I think that overall things went okay. I don’t think I managed to fully get my mix under control to the point I was fully happy with it. However, I think the side-chaining and ducking systems I set up definitely helped to clear the mix up during particularly hectic gameplay moments.