FORSAKEN Fish fighters

Forsaken Fish Fighters is designed as a couch competitive fighting game where the players are fish in a fish tank. They battle each other, trying to kill the other fish in order to be the last fish standing. They do this by either ramming into the other fish to knock them out of the tank, or by using their unique fish abilities to get advantage, or even by competing for food dropped into the tank so they can eventually grow big enough to eat the other fish. (Note: this game is still in progress—updates to come)

Joining a new team:

I was not on Forshaken Fish Fighters at its start but I was brought into the game three months after it started. I was brought onto this team as technical sound designer because they did not have anyone specific to manage their game sound. This meant I would both managing the implementation of sound and creating sound effects for the game. I started by looking at what sound they currently had, making a document to describe them, as well as noting any sounds they might want to add. I was given a lot of autonomy with sound direction, however I felt I should get the teams approval for changes since as I was recently added to the team and did not yet have their vision for the game. Next, I came up with list of all sounds I would need to add in the future and what sounds would need to change.

Sound Design:

Audio Systems

Audio MANAGEMENT 

I started developing a Unity tool to make my life easier by having a system that all the sound effects in the game would run from. Since Forsaken Fish Fighters was a fighting game, I also wanted to make this system separate each sound by the interaction with the player. Looking at other fighting type games, they mostly have very precise sound effects. If there is an action by the player, there is a unique sound effect that goes with it. Separating sounds by interaction would let me make the sound system trigger them on a player by player interaction basis. Secondly, I wanted this system to work with an audio script that would trigger each sound based on what happen to each character. Since there would be one script for each character, I called this script CharacterAudio scripts. Next, there would have to be an audio manger script, which I called AudioManager script. This script would manage what each CharacterAudio scripts had access to in terms of sound and triggers. Now all I needed was a way for a Unity Prefab to store triggers and the sound effects they would play. I came up with the idea of making something I called Interaction Scripts.

Sound by Interaction

Interaction scripts held options that were public enums to determine what type of interaction would trigger the sound, public Booleans and Integers to determine different triggers for the sound, and the actual sound file that would be played. All these public variables on a Unity script would look quite messy, so I overloaded the Unity Inspector window for the Interaction script so that it would only display the relevant information. If I selected an interaction by force as an enum, it would only show me variables relevant to an interaction by some amount of force to a character plus the variable for what sound to play. I could also store privately whether the audio was a background sound or a sound effect, which let me balance the volume of the sounds with public numbers for the AudioManger script in each scene. Now I could make Prefabs with an Interaction script on them for each interaction the character or object would have. Then the character audio scripts, through the use of public enums, could be set to what character they were on and this would go through the audio manager for each scene. The AudioManger script will link the correct character Prefab to the CharacterAudio script.

Character Audio

The CharacterAudio script will then create copies of all the interaction scripts adding them to lists to keep track of them. Next, CharacterAudio will add an audio source, which is what unity uses to create sound, for each Interaction script it has and let each Interaction script keep track of its own audio sources. After this, while the game is running the CharacterAudio script will check through its lists of Interaction scripts to see if their condition has been triggered. It will also work with the other player scripts to determine whether certain button inputs have been made or the character has been hit with the correct amount of force to trigger a sound.

Risks

This kind of system is very good for adding sound effects whose types have been added before. For instance, adding a “being hit” sound effect across multiple characters is very easy as all I would have to do would be to go through some Inspector UI menus and the sound would be in. However, adding new sound effects like a grab and throw would be harder as I would have to program them into the Interaction script and make sure the current CharacterAudio Script could handle its triggers. The reason why I made this audio system for Forsaken Fish Fighters is that, while we have multiple fish characters and multiple levels, most sounds that were going to be added have very similar triggers across most fish and levels. There would only a few edge cases with fish and levels where it would be necessary to have different options.

Edge Case

One of these cases was the game menu. As I wanted to implement this same sound system with the menu, I simply added a menu option for the Interaction Script enum options. However, because I did not what to keep adding to the CharacterAudio script, I made a separate script to manage the menu sounds called MenuAudio. This script did much of what the CharacterAudio did, just on a smaller scale as it only managed the menu audio sounds. Like the CharacterAudio script, the MenuAudio script communicated with menu code to determine if the player moved between options or selected an option on the menu.