My work on the Bee Game is done, all the sounds Travis, the developer, was looking for are completed and implemented, and as I've learnt, there are a million more things to be done. Even though the most necessary sounds are completed, every time we sit and play the game we think of more and more things that need a new sound. But for now, what I set out to achieve has been completed. I want to do a little reflection on the over all project and all the ups and downs that entailed, including all the issues we faced and what we did to navigate past them. I do just want to say that I not only found this project rather rewarding, but I find it hard to pinpoint problems, because they generally just felt part of the process; I had never created and authored sound for a video game before and because this was my first go at it, I found the whole process very enjoyable.
From the Top
Travis and I had always planned to work together on implementing sound into his game, but I personally had sort of sidelined the project in my own list of priorities. I decided that making it my major project for this trimester would kill two birds with one stone. I asked Travis for an updated list of the assets he would need, and he promptly sent me an updated version of a list he had shown me about a year ago. I then organised all of these assets into a document that I could easily navigate, write notes, and tick off assets as I completed them, I then checked with Travis that my list and accompanying notes were accurate for his vision and he agreed. Majority of the notes I derived from the intentions Travis had communicated with me for the sound assets. I then created a week by week priority list which started with the music as I believed it was the best way to set a precedent of my intent for the over all aesthetic, especially when it came to communicating this with Travis.
Fmod
Fmod is a program that gives power to the audio engineer when it comes to implementing sounds, all an engineer needs (depending on the sound and event in question) is the corresponding values associated with the action he would like the sound to take. I had only ever done basic asset creation for video games, meaning that I have created everything for a client that's creating a game and then sent it off to them for implementation into the game. I wanted to get my head around the way Fmod worked because it is currently one of two programs that is commonly used with game developers to author music and sound into their game engine, the other being Wwise. Before these third-party middle-ware programs were created, game devs were writing chunks and chunks of code to have sounds or music play in their game, especially if that music or sound was going to have complex interaction or dynamics in the game. "The ability to change the sounds and trying new approaches without even changing anything in the game engine is something vital for the development team. It wouldn’t compromise any code or any parameter, and the people in charge of the audio are entirely responsible for how a game sounds" (Nikoofar, H. 2018). I whole heartedly agree with this, and would for one, would rather take the work load off of Travis for this part of the process, and two, enjoy having more creative control over the implementation of audio, as this can leave so much room for creative authoring of sounds.
For example, this rather pleasant game, A Short Hike, includes a change in the music that is dictated by how high up the mountain you are.
Without actually knowing how the developers achieved this, I could guess that the characters relation to the top of the mountain would have a value most likely ranging from 0 - 100 tied to it, the audio engineer could then theoretically create an instance in which the music changes depending on which value the game is producing between 0 - 100. I had been shown some very rudimentary workflows in Fmod, such as being able to tie changes or triggers in the game code to a value that I can then set to particular changes or triggers in the music. This gave me a great idea for the music in the Bee Game, which I decided would be best demonstrated to Travis.
Music
So to kick off the whole process I wrote a bit of music which I thought fit the first level, and worked well with a couple of ideas I had for the other sounds in game play. I sent this through to Travis to see if he liked it, which I had kind of already figured he might because it was quite a similar feel to a short piece I wrote for a trailer that he had released a few months prior. He liked it and so I went on to explain my intention for the music; I wanted the loop that I had created to be dynamic, so my first thought was to have the music progress and add more elements as you got closer to completing the level. Travis immediately suggested ways that we could achieve this and so I thought that he was definitely on board with it. He's quite clued into working in Unreal Engine so all of his suggestions involved authoring and programming the audio elements within the engine, however, I really wanted to use Fmod for this project as I had never used it before. He also hadn't used it before and was a bit iffy on using a secondary program rather than doing it himself. I decided it would be best to show him how using Fmod can take a huge workload off of him by asking him to prepare UE4 for Fmod while I began making the dynamic music loop. Almost immediately we had issues with getting Fmod to work as his version of UE4 didn't match the current version of Fmod and the tools that allowed them to work together. We decided to talk over Discord while he both did some research into what version was needed, which took us a while but eventually we got there. This, however, wasn't the end of our problem; almost every bit of information on using Fmod with UE4 doesn't actually explain the implementation of Fmod assets correctly, which had us researching for a solution for another few hours. I had almost given up and let Travis know that if it takes too much longer we can just go ahead and use his workflow. But after a quick chat to my friend Ryan who had already used Fmod in conjunction with UE4, we had it working properly, and Travis was able to implement the music loop I had created. With this, he was able to see the benefit of leaving all the authoring of sound up to me, as he could simply place the assets into the game where he needed them and the sound would work, as long as the values he provided matched the assets he was tying the sound to. So, so with our music properly implemented and Fmod working like a dream, I could begin creating some of the other sounds which would create more dynamics in the music.
Collection Sounds
I had an idea at the beginning of this project for the sound associated with the collection of pollen during gameplay, and I could see it being a good way of making the music a satisfyingly interactive experience. The idea was to have random notes played in the same key as the music every time you collected pollen during game play, this way the player would be sort of rewarded with a new edition to the music with this action. As the recordings for the game were all acoustic instruments I chose a Kontakt acoustic guitar to make the sounds with, as they would be the cleanest sound I could make and also fit the aesthetic I was looking for. I then played a little bit of the instrument on my midi keyboard along with the music loop I had written to get a feel for the key, and a scale that I could make all these one shot sounds in. Then it was just a matter of creating long midi notes that would play each of these notes in the key I had decided, so that I could export a full piece of audio with all of them in it, and then cut that down to the individual notes I was going to export. In Fmod I created an event called "CollectionSounds" and made a multi-instrument that I then placed all of these sounds in. Every time the event triggered one of these sounds would play at random, and because of the shuffle setting in the randomisation options, none of them would play twice in a row, giving it a nice natural feel. Once again, Travis was given more of a reason to stick with the Fmod work flow as he was able to simply attach this event to each collection event and the notes would play perfectly with the background music. We did have an issue with this where the notes being played would unfortunately get a bit lost in the music, which made it harder for the player to notice the association with collecting the pollen. I solved this by not only adding a small shimmering sound effect that played at the same time as the notes, but also another multi-instrument which randomly played a small number of leaf rustling sounds I had put together after a sound collection trip to Mount Tamborine. Once this sound was added it seemed like everything gelled together perfectly, as the flower actually moved and sort of rustled as the player flew past it to collect pollen, so not only did I have a pleasing sound effect that tied in with the music, but also a diagetic sound that reflected the movement happening on screen.
After going through the music and collection sound implementation stage, it was a definite that we were going to use Fmod for the rest of the process. The fact that I could easily edit assets and the way they behaved without Travis having to rewrite a mountain of code was obviously a bonus, but there were things we didn't expect as well. Such as the ability for Travis to change things in the Fmod session on his end, thus eliminating the need to send him an entirely new project for small changes. It also means that now I have a lot more of an understanding with third party audio authoring software; I would have liked to look into learning Wwise a bit more, because it is another very popular software used with devs these days, but I imagine my knowledge in Fmod will translate quite efficiently. Not only that, but Travis now has an understanding of it as well, so if ever he has to work with a sound designer that wants to use Fmod and expects him to be ready to implement using it, he'll be able to work efficiently with them as well.
The Workflow
Travis and I have been good friends for a very long time, so we never really have issues when it comes to creative differences. I very much respect the work he has put into this project and his overall care for it, so I was very open to going with his preference on things over mine, however, he also respects the work that I do and so he also is inclined to accept my opinion and ideas. We would always very easily reach an agreement on things and would regular talk about new ideas while we played video games together; often we would immediately get to work on them after discussing them, because we both have so much love and care for this game. If anything, I wish I had gone to his house a bit more and say with him while he worked on this game, so that I could get a really good idea of what happens on his end of the process. I suppose I never felt that this was necessary because Travis is quite good at explaining how things work but when I visited him to finally get a copy of the game on my phone, the different perspective of the process gave me a new level of respect for his end of the process and also a lot of ideas regarding the way things could be implemented. I also wish I had gotten a copy of it on my phone earlier, because actually playing the game was a bit of an eye opener when it came to what elements still needed sound. I definitely would have gone ahead with getting a copy of it a lot earlier down the track if Travis didn't live an hour out of the city and had already figured out a way of building it onto devices without directly plugging it into his computer. Other than this, I think the way I approached this project was sufficient for getting the result we desired. At the end of the day, Travis had given me a large list of sounds that needed to be in the game, and I delivered those to him (and then some) in a format that was easily implemented for testing in game. Another point for Fmod, as it was super easy to get these sounds tested quickly before ticking them off. I also think I picked up Fmod fairly quickly with the help of Travis's knowledge about game programming, coupled with a few tutorial videos suggested to me by peers and also their input and suggestions. As much as I am confident with using Fmod now, I am sure that I've only just scratched the surface in terms of it's capabilities. Credit to Fmod where it's due, it is a very easy to navigate program, so figuring out how to add effects and new parameters only took a limited amount of knowledge and a bit of messing around.
If I had my time again, I would have definitely gotten some of the more difficult to create sounds out of the way first; such as the sound of the bee buzzing around as you move. I think I've done a good job of it, but I left it rather late as I wasn't sure how exactly I was going to achieve the sound I wanted, and ended up spending most of my time focusing on other assets. I had done a bit of research into the aesthetic I wanted for the bee buzz, and knew what I wanted as a end result, but wasn't sure exactly how to achieve it. This meant that because of how late we had left it to add this effect, the troubleshooting for it was done on the day we built it to my phone, and since then Travis has actually improved the way the sound works a bit more (and luckily a way of getting it to me without having to drive for an hour each way).
Some More Troubleshooting
Buzz
I've already mentioned a few things that we had to troubleshoot during the process of making audio for this game, but a couple of things that happened later in the project are worth mentioning. The first thing I'd like to mention was actually the last thing that was fixed before I finally had a build on my phone, and that was the way the bee buzzing sound worked in game. Like every other sound in this game, I wanted it to have a dynamic element that meant it wouldn't always be a constant buzzing that the player would have to endure during a play through. For this, I created a low buzzing sound by humming into a microphone that would fill the base of the sound, and would play constantly. This meant that it had to be quite low in the mix and gentle to the ear, while still sounding like a bee; humming was the best way of creating this sound after a couple of trial sounds were tested. Then I created a higher pitched buzzing sound by recording my electric razor for a short while and then pitching the sound up in Fmod, which I intended to increase in volume every now and then to change up the sound. I did this by tying the volume control of this track to the tilt parameters of the bee, so whenever the player would turn the bee, the slightly higher buzz would come in and then fade away as the bee started moving straight. I asked Travis if he had a parameter set to this action and he told me that there he had created one for the yaw of the bee, and that we could use the same numeric scale to control this new sound event. His scale went from 0 - 80, as that was the bee would tilt as it turned, so I set my parameter in Fmod on a scale from 0 - 80 and hooked up the volume control. In Fmod it seemed to work perfectly so I sent this over to Travis. We ran into an issue right away, as his code wasn't recognising the parameter i had set, which was something we had encountered before and solved by making my scale 0 - 100 and then setting the envelope, which controlled the volume, to work to the parameters we had set. With this function in mind, I set the scale for the parameter to 0 - 100 and then had the change in volume end at 80 instead of reaching all the way to 100, which actually worked when we tested it in the game engine, however there were some slight issues within the code for this action. Because of the way Travis had programmed the mathematics side of his function for the bee tilting, the Fmod control wasn't tracking at a smooth pace in between each numeric value, so the sound was kind of juttering around as it tried to find the value it should be setting itself to. As the code only recognises the difference between numeric values being 1 value, the sound suddenly jumped up in volume as the numbers quickly increased, but we wanted it to slowly track through the values as they increased, and to do this, the code would have to recognise a sliding scale in between each value. The solution was fairly simple; in Fmod, I set the parameter to slowly slide between values instead of instantly jumping to whichever was set, so even if the game engine suddenly set the value all the way to 80, it would slowly glide up to full volume rather than suddenly jumping there. Travis has since made this a lot smoother by adjusting some of the mathematics in his code, but I truly don't have an understanding of game programming so it would be pointless for me to try and explain.
Dying/Running out of Nectar
During game play, the player must manage a meter to the side of the screen that slowly decreases in between the collection of pollen, so if the player takes too long to collect pollen, the game will time out and reset the level. We wanted there to be audible feedback for this function and so we decided that because the music had become such a large part of the game play, we would tie this into the music. Because the music is so nice and calming, we thought that maybe making the music slow down would add a level of urgency to the game play as it would sort of make the music a bit jarring and unpleasant. However, after some feedback from my lecturer and some other people that played the game, we decided that it was too jarring and settled on making the music become muffled as you would start to run out of time, thus keeping the music intact while also being very clear in the consequences of letting the time run out. We also had an issue with the scale in the parameter, similar to the one I just mentioned, but having prior knowledge of it meant we could fix it quite quickly.
Final Thoughts
We're certainly not finished with this game, and especially the sound aspect. While I have successfully delivered all the assets Travis wanted, every time we play the game we notice new things that could be added, which is also why I wish I had a playable copy of it a bit earlier. I am however over the moon about the things we have achieved, and can't wait to continue working on it. I'm also glad I got a chance to work with Fmod and get my head around a program which is very much industry standard, therefore preparing myself and Travis for further endeavours in the games industry. There isn't much I would have changed if I could do it all again, other than the things I've already mentioned, and the over all prioritisation and testing of the game.
Alpha play testing happens soon so shoot me a message if you're interested in getting involved!
Nikoofar, H. (2018). Why are game developers afraid of third-party audio engines? [Blog]. Retrieved from;
https://www.gamasutra.com/blogs/HamidrezaNikoofar/20181203/331940/Why_are_game_developers_afraid_of_thirdparty_audio_engines.php