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.
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!
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.
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.
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"); } }