I think that, overall, this project was extremely ambitious. I think I knew it was ambitious to take on a game, but I didn’t think I realised at the start just HOW ambitious it was. As I haven’t technically been taught anything in regards to FMOD or game engines, it’s been a process of trial and error, of replication in many cases and a lot of talking to people who’ve done what I want to do. One of the biggest things i’ve had to learn during this process, is that the creation of audio is just a small portion of work – it’s like 30% of the battle. There are so many other things that are far more complex, on many different levels; for one, the relationship with the developer is absolutely key. I was very lucky in this case because James already knew me and wanted to work with me, based on my previous work. In the cases of other projects i’m working on, it’s sometimes a long battle to convince the developer to take you on for the audio – even well into the creative process. In the case of Taphobos, I was lucky because James was very invested in me and was happy for me to take a creative lead on the sound of the game.
Another thing that outweighed the creation of audio in my list of concerns was the implementation, and the game engine. I naively thought that, given it’s ‘status’, working with FMOD would be easier for both myself and the developer – this wasn’t the case. We actually had a lot of trouble getting FMOD to talk to Unity properly, and often even James was baffled by the problems we had with it. Making games is literally about trial and error – despite having years of coding experience, James often found he didn’t know what the engine was doing, or why it was doing it. We had to spend a lot of time fiddling with values and seemingly insignificant details to make the final product come together in a meaningful way.
Organisation also became huge for me, as I had to take into consideration the fact that I was coordinating my work alongside another creative professional, and not just working on my own. We used google drive extensively, and I also used spreadsheets to keep track of what sounds had been made and what hadn’t. We collaborated mainly with a versioning engine called Github. My previous experience with this kind of system has only been with Perforce, and I far prefer the open layout and accessibility of Github.
Due to these factors, and many more, a lot of things that I set out to accomplish fell by the wayside – for example, we came across the issue of not being able to send a independent stream of audio to the second player in the oculus rift, due to an issue with FMOD and Unity, which was annoyingly completely out of our control. I also look back on the amount of audio I set out to create and implement, and consider it hugely ambitious considering the timeframe. Games take YEARS to make, and for good reason – it’s not a quick process, at all. While my final product isn’t all I had initially intended to make, i’m really pleased with what I have achieved in just a few months. If it was a lineal sound to visual piece, the results wouldn’t be that impressive – the fact that it isn’t on a linear timeline, that the creation of audio was actually just a small aspect of the process, and above all, the fact the sounds are being triggered interactively by the player in the game, for me, is really exciting. It’s opened my eyes hugely to the amount of learning I still need to do – the work and time and effort that goes into some of the big games being released at the moment is really mind blowing – I think I will continue to learn and hone my skills for many years to come to reach that level of quality and sophistication.
I will now briefly look back on my learning outcomes, and consider whether I achieved them.

LO1 – ‘By the end of the project, I aim to have explored field recording in much more depth, in order to capture all of the sounds for the assets in the game’.

I beleive that this is something I have excelled in, and i’m really pleased with the results. ALL of the audio in Taphobos I captured myself – every element I recorded in the field or in the studio, processed myself in Pro Tools and implemented into Unity with FMOD. This is rare, even for indie games – the vast majority of games will use library content at some stage in the process. I’m really proud that the game has come together and sounds good with just my own audio in – this is definitely something I consider an achievement. I think I really have completed my aim – previous to my third year, I hadn’t done any field record or sound effects recording at all. Even since before Christmas I had only done enough for me to make some fairly simple linear pieces. Through spending many hours recording in fields and forests and quarries, I’ve honed my field recording skills in a very quantifiable way – through the game sounding so good.

LO2 – ‘I will explore and evaluate the sound of both other indie games, and other ‘horror’ games, in order to expand my understanding of indie game sound, and deliver a similar standard product’.

This maybe has been something I haven’t done quite as well, or at least, not really demonstrated through research that I’ve done it as well. My main references have been Amnesia and Dark Souls, the two games i’ve explored in the blog. I think my decisions for the sound aesthetic of the game have been very fluid and organic, and maybe something I have picked up more from engaging with indie games on the whole, than specifically picking examples to build from. Both Amnesia and Dark Souls have a very particular sound – and I think Taphobos has it’s own sound too, which, while influenced by those games – doesn’t necessarily draw much from their sound other than some similar approaches to aesthetic. Jumping into the indie games world and spending time at events like Rezzed  and Game Audio North (which I wrote about in my blog) have enabled to me form a dialect and working ethic when it comes to approaching game audio and working with developers. It isn’t necessarily something I can point to as my direct influence – but rather a product of spending time with the types of people who’s work I admire and look up to.
It’s also worth mentioning here about my examinations of the different approaches to sound creation and implementation that I looked at in the blog – i’ll come back to this in my FMOD learning outcome, but I think it is also very relevant here. Given the example of the post that explores the article about the sound of the Banner Saga, I think this really formed a basis for my sound approach on Taphobos. The more I speak to high level sound designers in the games industry, the more it becomes clear that this procedural sound design technique is extremely important and favored by many. It is key to break elements down into tiny elements, create a large number of variations of each element to then trigger randomly in the engine. Just the other day I was speaking to a sound designer who told me he’d broken footsteps down into multiple different elements, including heel, toe, shoe squeak and impact, and had recorded multiple variations of each of these elements for multiple surfaces. This is really mind blowing – that just for a simple aspect like footsteps, there could be hundreds of audio files, each helping to create realism and bring life into the game.
I’ll also say that, before I started the project (as you can see in the objective), I considered the game a ‘horror’. I now mostly certainly do not, and I don’t think my sound design reflects that of a horror at all. Granted, I took influence from Joanna Orland and used the approach of mixing the surreal with the real to create a certain amount of unease for the player – but after spending a long time chatting with James about his vision and thoughts about what Taphobos should achieve, I definitely don’t think it reflects a horror aesthetic. Perhaps an uncomfortable and uneasy game to play – granted. But I wouldn’t personally go as far to suggest it aims to scare the player.

LO3 – ‘I will work alongside the developer, in order to best understand and deliver their vision, as well as using my audio expertise to deliver a high quality product’.

This I think can be demonstrated in the end product. As i’ve mentioned, myself and James didn’t really talk in sound terms, at all. He didn’t really know what he wanted the game to sound like specifically – he just understood his own aesthetic for the game and how the audio was related to that. It wasn’t a situation of him giving me any expectations sound wise – he didn’t suggest any similar games or anything for me to draw from – but he instantly knew when a sound was wrong for the game environment. I’d like to think the final product is of high quality – it’s not far off high quality, at least.
Working with a developer on such a personal level has been really interesting for me – on my previous game, Hashtag Dungeon, the audio was implemented by the developer independent to my influence. This meant a lot of things ended up in the game that I personally didn’t want to be there. In this case, I sat down with James regularly to implement the audio into Unity – something I hadn’t done before. In my eyes, this is a huge achievement in itself – a year ago, there was no chance I’d be able to have done this same process in the way I have done. Working with James in the engine required a certain amount of understanding of game engines, and even an amount of understanding of code. I’ve begun to learn to code in small amounts, through my experiments with game engines – coming from a purely audio background, this is massively intimidating. Code is just such a different headspace and process to anything i’ve worked with or experienced before. I think that my ability to work with James and understand the technicalities and challenges of code has been a huge achievement.

LO4 – ‘I will explore improve my technical implementation and understanding of FMOD and it’s integration with Unity’.

Again, as i’ve mentioned, this was a funny one. I went into the process with the understanding that FMOD is an industry standard tool, used for its ease for both parties. This is true to a certain extent – in that, I could never have created the complex endless ambiences that I did in Taphobos through the in-built audio engine in Unity without a lot of faff and a hell of a lot of code. Unfortunately however, FMOD is designed primarily to be integrated into Unreal Engine, and its compatibility with Unity has only been a relatively recent thing. This means that there is a lot of bugs and problems with the integration, such as sound not playing correctly, problems with the debug tools, issues with audio loading times and James had no idea how to publicly declare and reference FMOD in code. That being said, one of the nicest features about FMOD is the live updates – essentially you can have FMOD running in tandem with Unity, and make changes to the sounds and their implementation on the fly, and have it correspond live in the game engine. This was huge, and meant I could play through the game on one screen, and adjust the pitch of a tiny element of ambience on the other screen.
In terms of my own skillset development in FMOD, it has been extensive. Prior to Taphobos, i’d never worked in an engine with FMOD, and had only built theoretical audio systems in it independently. To go from making stuff in FMOD on it’s own, to integrating the software into the engine, has been a big jump and a lot to learn. I think i’ve done it successfully, but I know I still have a lot to learn.

Overall, i’m really pleased with the project and I’m glad I took it on. It was ambitious – really ambitious – and it’s been nothing like any of the audio work i’ve done before. I’ve enjoyed working alongside a client a lot, and I think our combined skillsets have really resulted in Taphobos being a great experience and an engaging sonic journey. While not all aspects have been as successful as I would have liked, I think the process, the amount i’ve learned and the final product have been fantastic.