Week 12

We're closing in on the last week of production.  From here on out, all functionality has been built in the programming part of the game and the mechanics are complete.  The last few things we have to do is bug fixing and polishing.

I finished the tutorial this week with only one bug and one design fix needed which will both be pretty simple.  The bug in the tutorial is that the end screen does not actually do anything, it just says success for now.  The design fix is simply that one of the tutorial messages needs to be split into two different ones.  These can both be accomplished very easily with little code change.

Other than that, I just need to fix some bugs that have been popping up over the course of the last few weeks of implementation.  One thing we found is that Warpath does not have a particle effect on his super move so I will most likely be implementing that in the next week as well as some other polish such as fixing the broken texture on the panel when it breaks and looking at chain's grappling hook to make it a bit smoother.

Overall, were in a pretty good position.  The only other things that I will have to do is just fix any bugs or issues that come up over the next couple weeks.

Week 11

This week was working on the tutorial mode for me.  We got word of it last minute last week while I was finishing up the panels, so I had to cut those a bit short, but I also have the tutorial mode just about finished.  It should be finished up for beta, but I wanted to get this blog in before tomorrow.

The tutorial mode is pretty simple, but no one was really planning on having a tutorial mode so there was nothing built to accommodate it.  Basically, the tutorial is its own level where it displays a gui text box in order to give the player directions.  After the player completes the goal that is displayed in the box, then it disappears and displays another goal until the player knows the basic controls of the game.

Week 10

This week was all polish on the panel breaking system.  The idea is to cast two capsules against the panel pieces and break or destroy them based on which one hits them and their current state.

One of the major problems I've been having is with the capsule casting.  I think the problem is that it is casting the capsules in the wrong direction.  A major bug that I was just recently able to fix was causing blocks from the left panel to break when the right one was hit.  This was due to the fact that the capsule was being cast (basically) infinitely in the negative x direction.  Now, it is currently at a state where, I believe, it is still casting the capsules in a weird direction, but I limited them so they are working, but I still want to fix this problem.

Next weeks work will most likely consist of fixing this and doing some more polish on the audio programming based on needs that come up from Ryan.  Otherwise, there has also been talk of a tutorial that we just recently heard we need to implement.  Unless other things come up in class or at meetings, I think that just about covers it for me.

Week 9

These past few weeks have been and will probably continue to be polishing the systems we currently have implemented.  The first thing I've been working on is the way the panels are breaking.  I'm in the middle of implementing a new system to include "broken" blocks so the panels have a more realistic feel to them.  The second thing I'm continuing to polish is the entire sound and effects system for the player.  We're looking to move as many scripts off the player as we possibly can in order to clean up the scene view and make it easier to work with.

The panel explosion will not be on the player and each panel will have its own script attached to it.  This will control the texture (broken or unbroken) and how much "damage" it needs in order to actually break away and disappear.  This will be done by casting two capsules on the character.  The first one is the hard break which is about the same size as the character.  When a panel piece is hit by this, then it will break away and be destroyed.  The second capsule cast will be slightly larger than the size of the character model.  If this hits a panel piece then it will change the texture to "broken" and will be destroyed if it is hit by another one of the capsule casts. This is where the majority of my time went this week, but I also did some things to polish the sound system.

As far as the sound system goes this week, I added in some audio lists and implemented the system for making sounds when the character jumps and hits the environment.  The last thing that actually needs implementing for the sound system is the landing sound for when the character lands back on the ground after a jump or being knocked in the air.  I still need to talk to Ryan about how exactly he wants to implement the sounds for this, so this will probably be done soon this week.  If not, it should be in there by then end of the weekend.

Week 8

This week was not too heavy in work load.  For the most part I focused on fixing any bugs we found with the taunt controllers and  the panel breaking.  Other than that, it was just polishing and cleaning up code for readability.

The panel breaking only had one problem with it, that I could find, which was the fact that if the enemy was too close to a panel, then the knock back of your character would not push them through the panel.  This was pretty simple; I just needed to add a OnTriggerStay() function to the panel breaking script.

The Taunt decals worked a bit differently.  Adam had added in some functionality classes for taunts which I finished tweaking the code he had in order to use with my taunt scripts.  The only other thing I fixed was the bug that wasn't allowing specific character taunts to trigger.

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.

Trail Renderers and Particle Effects

Basically, what I did this week for our game was implementing the effects system for when a hero is attacking as well as actually making contact with someone on an attack.  Basically, how the system works, is that there is a list on each hero move that contains the particle effects for when the move actually makes contact with another collider, and the other list contains trail renderer game objects that are instantiated when the player uses the specific move it's attached to.  This is then cleaned up when the animation is finished.  I might want to do some more work on the clean up to make it look smoother later on, but it seems to be working pretty well, especially for this point in time.  I have a cool video that I made with fraps in order to show, but blogspot is having a difficult time accepting the video for some reason.

Week 2

This week was pretty successful for me.  I managed to finish up the panel breaking system.  It now adds an explosive force from the center of the character when they reach the breaking velocity and ram into the side of the panel.  This then, based on an explosion radius, pushes any blocks (or panel pieces when we get the art in there) away from the character simulating they being "thrown" from the comic panel and into another one.  Some of this will change and I might have to tweak a few things when the art gets in and the designers start playing around with the system, but it's working great so far.

The other thing I started working on this week was exploring the idea of trail renderers and particle effects on the heroes' limbs when they attack and connect an attack, respectively.  With the way the code is set up so far, I can instantiate the particle effect or trail renderer from a list of prefabs on the scripts that control the animations and inputs, but I need to ask Adam about how that actually connects with his code.

Week One

So this week was mostly just getting started on the project.  My duties this week included two different things.  The first was that I needed to go through the code and start learning the code base and how everything works.  I think I have a good idea on how this works, but I still need to work with it some more.

My second job this week was to start exploring some physics calculations for breaking away the panels on the side of the level. The basic idea was that, upon some (to be determined) event, one of the players will break through a panel frame and into another panel.

There were a few different things I explored while working with this concept.  The first issue was what type of panel frame should we use which can either be 2D planes or a 3D Game Object.  Personally, I think either one will work, but I personally enjoy the look of the 2D planes.  In the end, this will be more of a design choice than mine depending on how they want it to look.

The second thing I explored was how to do the physics.  The two choices here are basically use unity's .addExplosionForce() method or to create and fake our own physics.  I played around with unity's physics system for a while and I managed to get some interesting looking effects (based on the objects I had which were essentially just cubes and planes), but we can probably get a more controlled looking panel break if we fake the physics.