Week 7

This week was doing a lot of work to make my sounds not only easily accessible for the designers, but also giving them all the capabilities needed in order to make the sounds work the way they want them to.

A major issue we were having at the end of last week was the fact that many of the animation times did not sync up with the sounds they made before hand ("woosh" sounds to simulate how fast the characters are punching).  My first instinct was to cut the length of the sound clip to match the length of the animation.  This ended up being easier than I thought, but did not work how we would have liked.  This ended up cutting each of the sounds before they were finished playing instead of changing the entire length of the clip.

After discussing the problem with Ryan, we decided that many of the animation sounds worked well with certain animations, but there were simply some animations that have unusual timings.  A couple examples are Major Marvelous's heavy punches such as his uppercut.  What Ryan decided to do was to make some generic sounds for each character's animations that mostly work together, then edit the length of the sound clips to make them fit the oddly timed animations.  We decided this would be the best solution because it did not take Ryan much time at all to make the "woosh" sounds.

The other major thing I worked on this week was polish for the sound controller.  Basically, I added some more lists of sounds for different circumstances as well as some other variables to help the designers control which sounds played when and what sounds they choose from.

Polish included, fixing some audio source prefabs so the sounds would all work together properly.  I also added in the decals for the taunt animation and allowed them to follow the character as well as an offset that is based off of a position that is slightly above the character's head.  This allows the designers to move the taunt decal anywhere they would like, but if the y value is left at 0, then it will still appear above their head instead of inside the ground.

That's about all that happened this week.  The next few things I'll be working on are environmental sound implementation as well as (possibly) some character super powers.  Of course, I'll still be polishing everything that's been done so far.

Week 6

Last week I mostly worked on some sound implementation features.  Some of these things included: panel breaking sounds, on hit sounds, pow mode sounds, etc.  This week was mostly implementation.  Much of it was hacked together to just get it working and then I gave it to the designers to tell me what needed to be done in order for me to polish it.  Next week I am looking to add a couple more features to the sound implementation and get my code cleaned up so it's easier to use.

Something we discovered with the sound implementation is that the pitch mod seems to be a little wonky.  If the pitch mod goes above 1 or below -1, it gives a very unusual sounding audio clip and does not fit at all with what we are trying to do.  For now, I'm keeping all this in just in case we do want to do something with the pitch, but it is currently set to (0, 0) for the minimum and maximum pitch on just about everything except the panel breaking noises when the individual pieces hit the ground.

Week 5

This week was not incredibly busy for me, but I finished implementing the sound effects.  The current effects in the game include: on hit sounds, on block sounds, super power sounds, explosion and breaking sounds for the panels, and jumping sounds.

Adam had many sounds implemented from last semester, but he explained that it was put together pretty fast and wasn't actually a fully functioning system quite yet.  What I ended up doing was creating a serializable class called FighterSoundController.  This class goes on each of the fighters and allows the designers to easily set the sounds for everything the fighter does through an easy to use drag and drop menu.  This includes sounds for the super powers, jumping, and all the fighter moves both blocked and unblocked as well as the different sounds for the POW mode attacks.

The panels work in a very similar way.   It still uses the drag and drop system for implementing sounds, but it is on the panel prefab instead of the character prefab.  There are two sounds for this; the initial bursting sound and then a sound on each of the pieces that instantiates when the pieces disappear or "hit the ground".

The last thing I really need to work on for sound implementation is any environmental sounds that Ryan is looking to add.  I still need to meet with him one last time about these, but everything else is implemented how he wants, but he said he won't be adding the final sounds until much later in the semester.  At least we can throw in any prototype sounds we have to give some more flavor to the game for now.

The next thing I will be working on is helping Adam with some of the new superhero moves that the later characters will have for their super moves.  We didn't discuss much on this, but I did want to mention that this is most likely what I'll be doing this week after I finish up the meeting with Ryan and implementing the environmental sounds.

Week 4 - Player Sound Effects

This week I basically just worked on some sound implementation in order to further improve our game for green light.  This is not something that is needed for green light, but having it done before hand is going to just make everything a lot easier and allow the sounds to be put into the game as soon as we have them done.  Placing the sounds in the game is as easy as dragging ( one or more sounds) and dropping on each fighter move.

When the player actually attacks, the scripts grab a random sound from the fighter move that is being used by the player, figures out a random pitch based on two modifiers that out designers will set depending on what they think sounds best, and then plays the sound.  There are two different variables in the list of type FighterSoundSet.  The FighterSoundSet is a serialized class that allows anyone to edit them in the inspector, but keeps them private in code for my use.  Each of these classes are basically just a list of type AudioClip with a function called getRandomClip(float pitch).

The lists are simply there in order to hold the sounds while the pitch is passed in as an "out" reference in order to get a random pitch value as well as (its normal return value) the random AudioClip grabbed from the move itself.

Basically this will allow us to have a lot of functionality for the sounds that the characters will be making.  Ryan will be able to, after he makes all the sounds, simply be able to drag and drop as many sounds as he wants on each move and adjust the pitch range accordingly.  If there is only one sound, that sound will play every time that move is used, but will sound slightly different depending on the pitch that gets returned from the function.