This post will describe a few of the large hurdles I've had to overcoming during the course of this project.
Issue #1: Fading out a sound in Unity's FMOD.
One of the larger of my contributions to this project was my implementation of the FMOD library into C.R.A.B. This allowed us to handle sounds in a much more productive way as opposed to Unity's default sound library. However, this came with several issues, a large one being Unity's own FMOD implementation.
Prior to this project I have not been exposed to the several flaws and imperfections of Unity and I took much of what Unity had to offer as gospel. With that being said I expected their implementation of the FMOD library to be smooth and consistent. Boy was I wrong.
During this project, I had to opportunity to work on the implementation of FMOD's low-level API to my own C++ engine project. Having my own engine and my own context to work in showed me exactly what I needed and provided a clean solution. However, with Unity several compromises had to be made.
In my own engine, I could easily fade out any given sound by manipulating the soundcards digital signal processor. I grab the current time given by the clock, add a parameter for how many seconds in the future I want that to be muted at and then clean up afterwards. However, Unity's FMODRuntimeManager gives a user ZERO control over audio channels.
In FMOD whenever a user wants to manipulate audio, be it muting, changing pitch, etc a user must supply a specific channel. Unity changes these channels into a different wrapper object being an EventInstance. Unity provides proper functions to manipulate these EventInstances on a basic level (pitch, etc). However, I cannot call the functions to fade out using the DSP because Unity does not provide a EventInstance specific function for that. The clear idea here would be to have a way to convert that EventInstance to a specific channel, since it would have to have this information somehow to use these functions in the first place. However, all Unity's library allows is for a user to get the Channel Group of a given event instance. A channel group is a general tag for large amounts of channels (think sound effects, ambience, music, etc). This guarantees that a channel group is present for a EventInstance, therefore it has access to the channel playing it. HOWEVER, Unity does not allow a user to get that specific channel.
In FMOD's direct library when a user plays a specific sound, that function will return an integer representing an ID of the channel it's played to. Typically a developer (like Unity) will write a wrapper library to FMOD for their users ease. A channel ID is typically needed to use any form of FMOD's audio manipulation. However, Unity decided to block user access to channel IDs probably to make it more usable to people who have no programmed before. This caused a massive issue for me because I needed specific channel IDs to make my sounds fade out with ease.
Issue #2: Learning to work with other's code
This project was made in an incredibly short period of time. From first draft to final showcase was about 20 weeks, with that being said this was rapid development to say the least. Having three people constantly editing different components of the same object often leads to us stepping on each others toes. We constantly needed to ask each other "Is anyone editing the Crab movement code?" or "Who touched the crab firing component?". When several people are touching the code, it's bound to be changed in a way that isn't how you usually read your code. All of us programmers had distinct quirks in our programming that we all needed to understand to comprehend the system as a whole.
After the construction of my FMOD Audio Manager, I needed several changes made to the game as a whole to smoothly support audio implementation. For an example, if a player is to charge up their cannon to shoot, a looping sound will play. The function called when a player begins to fire is called in the Crab's "secondary fire" command. However, if a crab were to die, that sound would continually loop since the fire event for it finishing did not happen.
My solution to this was to implement an event manager to have clear accessible code managing all audio-related events. However other components of the crab could not benefit from the event manager, and a similar centralized event system. With that being said, there almost ended up being two event handling systems with the same events. I saw this and I needed to compromise my system and integrate it into theirs. While it was a slight inconvenience to me, their system couldn't work without these specifications. It's also better to have more direct code instead of multiple systems doing the same job for different functions. So that's why I compromised my system, to work with a system that we could both use.