During this week's lesson, we were given a quick overview on how Wwise worked; learning the different funtions, and given a few examples to implement into the Cube project, such as basic enemy sounds. We chose the Wilhelm screams, and used various Wwise functions to create a randomised container of different variations of the scream to an ogre death trigger, which meant whenever an ogre died to the player, it would choose one of the various sound bytes in the randomised container and play it.

After this example, I decided to start looking through the Wwise project triggers, and started grouping them up. Creating categories such as Footsteps, Player Interactions, Weapons, Monster SFX and such, I started organising the different groups of sound I would have to make, and thus could start planning on how I was going to create them.

So far, I believe that I learned the various functions of Wwise decently well, and I could navigate the program efficiently enough that I would be able to start implementing sounds on my own, which would now lead me towards beginning to create the sound effects for my Cube Game.

In order to create the actual footsteps, however, I had to pull from my previous skills learned from James a couple months ago. I first decided to record foley live, but after a couple days decided that it was not working well enough for me. Instead, I decided that I would look online for different footsteps on different materials, and directly implemented those sounds into my footstep sequencer system.

In order to give the game the ability to pull from the various footsteps sounds I created, I had to make a switch container, which will allow the game to switch between different sequencers I created depending on what terrain the player walks on. After implementing it, it seemed to work great; using the stone footstep sequencer whenever the player walks on stone surfaces, and using the sand footstep sequencer when the player is on sand, and vice versa.

It was a shame that I was not able to fully create my own footstep sounds, but I realised my limitations and sought to work around that as I still had plenty of other work to do over the next few months.

I used this philosophy to create more sound effects for the fire, poison and lightning gem. For the fire gem, explosions and crackling fire SFX were used. For the poison gem, thick bubbling/mud splatter effects and acid hissing sounds were used to simulate the thick, caustic nature of poison, and the lightning gem used a combination of a thunderstorm and an electrical transformer to create a loud, strong sounding weapon, reflecting its damage in the game.

Overall, I felt like I've done a good job for these weapon sounds, making them sound distinct from each other, but representing the weapons they were implemented onto well. Thankfully, implementation was easy; I only had to use a randomised container to hold the sound effects I made, and linked them to the weapon use triggers in the game.

The potion and wizard hat items were mundane compared to some of the other interactables in the game, so I decided to make them simple, but clean. Since the potions were glass vials with a cork stopper, I decided to use a cork pop sound effect, followed by gulping sounds to simulate the player character drinking the potion. Meanwhile, the wizard hat item would just use a rustle sound effect. Funnily enough, I had trouble finding the correct sound effect, as cloth rustling sounded too uninteresting and small for my game's purpose. Thankfully, searching for rough bag-handling lent me the perfect sound for simulating the player wearing the wizard hat, and sounded distinct enough that the player would recognise they had interacted with the item. This served as a great reminder for me that the best sound is not always realistic, but immersive.

Meanwhile, I was having trouble coming up with the idea for the Super Gem. I started with the idea of the Starman theme from the Super Mario series (the melodic theme that plays whenever the player picks up the star item), but I decided it would detract too much from the game's music and it would be a pain to program Wwise to mute the game's music as the Super Gem item was picked up. Instead, I settled for a sound that would feel empowering to the player. Using samples from storms and other natural disasters, I layered them all together to form a background sound for the player that would make them feel powerful, like a natural disaster that I had pulled the sounds from, and helping them feel the impact of the Super Gem item through this piece of immersion.

The Jump Pad was easy enough; all I had to do was find a 'Poof' sound effect and program it to play whenever a player stepped on one, and it served my purposes well enough.

Thankfully, all of these sounds did not take too long for me to figure out. I did learn a lot making the sound effect for the Super Gem though, and it taught me how I could use sounds from unintuitive sources to serve a drastically different purposes; as how I had turned a sound from an event people fear into one that would make the player feel unstoppable.

I decided to create my own sound effects for the portal first. In logic, I was able to use some of the synths I had to create some interesting sounding teleporter loops, and a decent enough teleport sound.

To implement the sound, I had to first make Wwise recognise the loop as a loopable sound file. Using the loop function and some integrated controls, I put crossfades on both ends of the loop so it would be able to seamlessly transition from the end of the loop back to the beginning.

Meanwhile, to give the sound a 3D effect in the map, I went to the positioning tab and enabled Relative Routing, which allowed me to assign position + orientation to the sound which will take into account the player's position and orientation to play the sound accordingly.

After working on implementing the portal loop sound today, I feel like I have sufficiently learned this function within Wwise, and that I will be able to use this knowledge elsewhere.

Before I could start writing music, though, I had to look at where I was implementing my music. There is a specific level I had to compose music for, and that includes various triggers that I had to write music for. The list is as follows: Exploration, Combat, Story, Boss, Victory and Defeat.

Since this level has a mostly linear progression, I had to make sure my compositions flowed well into each other. This included Exploration and Combat, as Exploration would be playing for a majority of the level, and Combat would be playing once the player encounters an enemy. Thankfully, this meant I could copy/paste elements between the two tracks, and just ensure Exploration would never go past a threshold of tension or excitement, while making sure Combat was more bombastic and got the player excited to fight monsters.

Mark had taught us how to use Wwise to fade in between two tracks synced together, so transition between two tracks could be smooth and enhance the player's immersion into the game. This is why I decided that Combat would just be a variation of Exploration.

Since these footsteps will be heard from a longer distance, I decided I did not need to split them into left/right variations of themselves, since the player is only going to rely on the sound for pinpointing the locations of enemies, and the reliance on this sound for immersion is much lower compared to grunts and death sounds. This is why I decided to create three distinct groups of footsteps; light, heavy and knight.

Light footsteps would be used by a vast majority of the creatures in the game, and they would have no variations for different ground material as the player won't be paying attention to that little detail compared to every other sound raging around in combat. This was easy enough to create and implement, and it worked great in testing. The other two categories were for specific enemies; Bauuls and Knights. Bauuls were massive, towering demon like creatures that players encountered in the level. Since they were so physically imposing, I decided to create a completely different footstep sound effect that reflected their size, which would add a little detail to benefit player immersion. Meanwhile, the other enemy of note was the Knight. Completely clad in metal armour, I thought it would be appropriate if it would create a distinct, metallic footstep sound.

In order to save time, I used the Bauul's footstep effect and layered two metal sounds on top (a hammer and an anvil sound effect), in order to create that metallic clank highlight for a footstep, which resulted in an end product that I thought worked well. In the end, I handled this part of the monster sound design decently well, and the implemented sounds worked well when I tested it further in the game.

Story and Boss were a little different, however. Since Story plays once the player enters a certain room, I had more creative leeway with how to compose it, as well as not having to make a transition as it did not need one in the first place. Boss was similar, as the player would have to jump through a mirror portal, which in turn would trigger the Boss music to play as the Player is thrust amidst a whole bunch of enemies.

Using the knowledge I had gained from looping the portal SFX, I was quickly able to make my loopable music tracks do so within Wwise. Now, however, I had to tell Wwise how I wanted it to transition between tracks. Recalling what Mark had taught me in class last week, I went to the Transitions tab, and created one that dictated any track can fade into each other in as soon as the next bar, and it would be playing the same segment too. This way, the music states would fade into each other seamlessly ingame.

However, I realised this singular transition option wasn't enough, since the victory/defeat themes didn't instantly play whenever they were triggered. Therefore, I added two more transition rules where if it detected either the victory/defeat triggers activate, it would immediately play the tracks from the beginning, with no fade ins. This fixed the problem, and both themes were playing in a much more obvious manner ingame now.

From my experience with working on the transitions, I think I can recreate and expand on what I've done here onto other video game projects, and the idea of being able to successfully implement dynamic music is an exciting prospect to me. This will definetly be something I work on further in my own time after the Cube Game Project.

I still gave creating my own monster sound effects a good try, though. For example, I had been working on the Hellpig sound effect, which had layers of a pig, and some generic demon sound effect I found online. Unfortunately, this was the extent of the unique sound effects I have created for my enemies, as most of the others were just pulled from free online sources.

In the end, I had to settle with re-using some monster sounds for various enemies, and differentiating them by adding a pitch-shift effect on a separate set of monster noises to allow for different sized enemies to sound a little different from each other.

Even though I wasn't able to create as many varied monster sound effects as I had planned to in the beginning, I think I had adaped adequately to the situation and managed to come up with a solution that still covered all my bases in the end. Next time, however, I am going to plan out far more things in advance so I won't run into this problem yet again, so I'll still be able to create my own varied sound effects for monsters.

Quickly making a heartbeat loop using all the other techniques I had learned and applied on previous things, I created and implemented it into the game quickly. In order to make it play when the player's health is low, I had to use a couple tricks within the RTPC function to do so.

First was making the heartbeat loop play when the player spawns; and I would use the RTPC function to effectively mute the loop while the player is above a certain amount of HP. However, using the grid, I drew a short graph that will dictate the volume to rise when the player is under 30hp, and will only continue to get louder as the number slowly reaches to zero. When playtesting ingame, I found this to be effective and it achived the effect I was going for.

One problem I ran into while doing this was whenever the player respawns, there would just be another loop played on top of the current one, and eventually the player will be hearing multiple of the same loop. In order to prevent this, I added a stop function on the player death trigger, which will stop the current heartbeat loop completely, which solved the overlapping issue.

After playing around with this function, I got inspired and went to the music modules of Wwise, and applied an inverse of the RTPC function to the music. Whenever the player's health got low, the music would slowly fade away and have a filter applied on it. This raised the tension felt ingame when the player was at low health, and I was happy I found another way to implement my new knowledge in a different area of my project.

I would even say my problem-solving capabilities have grown with dealing with this project while being busy juggling other projects as well, since I feel like I was able to stay on top of this project relatively often and complete things in a timely manner.