Ability Design: EarthTrap Shuriken

Over the break, I was successfully able to design most of the abilities I set out to do.  However, I did decide to scrap Shadowstitch for now as our direction in combat my not be suited for this particular ability. Additionally, I altered some of the mechanics for some abilities as well, and even designed a new one to take  the place of Shadowstitch.  For this blog post, I'll elaborate on the EarthTrap Shuriken Ability

EarthTrap Shuriken

This one works pretty much exactly as I designed it (which is great because I designed it to be awesome).   The player performs a backflip, and throws shuriken into the ground in mid-air.  The shuriken then slows down all enemies nearby for a set amount of time (currently 10 seconds). Designing this was both fun and challenging.  

First, I had to analyze our physics system to find out how to make the player move backwards  and upwards.  Fortunately, I was able to successfully apply the impulse.  

Second, I had to design the shuriken to be thrown in mid-flight. This involved creating a timer that kept track  of the interval when shuriken needed to be thrown, applying an impulse to make it move diagonally downward, and creating hit detection for the cases if it hit the ground or an enemy.

Finally, I had to create a component that slowed down all nearby enemies. It had to activate after it collided  with the ground or an enemy.  After that, I had to create a new component that allowed characters to be slowed (which I called the AlterSpeed component).  I made AlterSpeed to be dynamic; it could take in a  percentage of speed (which could be faster or slower than the current speed), and allowed a set time to be  inputted before a character's speed returned to normal.  For the EarthTrap Shuriken, it calls each affected  enemy's AlterSpeed component and sets it to 50% speed for 1 second.  The reason for 1 second is that the  shuriken pulses every second for 10 seconds.  This allows new enemies that enter the field to be slowed, and  enemies that exit the field to return to normal speed.

I am quite happy with this ability at the moment, and am looking forward to seeing it action in a proper level.  On another note, I would like to shoot a small demo video of each ability, but I'm limited at the moment due to our level not being stable.  Additionally, I can only make videos with the windows version which doesn't  have the avatars.  However, I'd still like to show it once we have the proper assets in place. 

Ability Design: Post Alpha

Well our team has finally hit our Alpha stage, and I'm pleased with how it has turned out.  We have a functional game that has an interesting control scheme.  We have most of our mechanics worked out, and are ready to use them to create awesome content.

Now that the semester break is coming upon us, I want to design more abilities for the player to utilize as a ninja.  My goal is to, at least, design three abilities.  I've already thought of some cool abilities that would suit the game (and, of course, make the player feel like a bad-ass), so I've decided to share some of my ideas.


1.  EarthTrap Shuriken

Being a ninja, it seems natural that we would use one of their most iconic weapons, the shuriken.  However, with the supernatural/ancestor aspect we are implementing, it needs a little more spice than just a simple projectile.  Thus, I am thinking of making this a type of avoidance/crowd control move.  The move would initiate by having the player back-flip away from his enemies.  Then, in mid jump, the player would launch a magical shuriken into the ground (or into an unlucky enemy).  The shuriken would then emanate an aura that would slow down enemies within a radius (as if trying to move under shifting earth).  From there, the player could either dispose of the enemies in their crippled state, or simply move past them as they struggle to give chase.


2. Shadowstitch

This would be an upfront, almost melee, ability that would activate in front of the player.  It would strike in arc downwards towards the ground which would then become black.  Enemies caught within this arc would be temporarily paralyzed as if bound by unseen wires.  The player then could proceed to defeat the paralyzed foes, or simply leave them in their immobile state.  This is a powerful ability, so its arc wouldn't be too big; it would cost a lot of energy to use as well.  However, it would be a valuable tool when the player is in a bind.


3.  Explosive Illusion

This ability would act as a counter to an enemy attack.  When activated, it would allow the player to vanish in a puff of smoke leaving behind a small explosive.  The explosive, when struck, would unleash a small blast that would damage any enemy nearby (though it wouldn't deal too much damage).  As for the player, he would re-appear, in mid-air, above the spot he vanished from; from this point, he could activate any other ability that can be used in air as he sees fit.  The point is to use it before the enemy is about to strike the player, so the enemy, instead, strikes the explosive.  It feels like a tool a proper ninja would have at his disposal, and it would add an element of timing to the game-play.


These are the three abilities I want to design over the break.  I'm quite excited about getting into the more creative aspects of game design, and will be trying my best to design fun, creative, and bad-ass abilities.

Damageable Component

My final task for Alpha was to build a component that would keep tabs on the health of the character attached to it. This was vital to the Alpha build because it allowed the player and enemies to be defeated by  depleting their health.

Again, this is going to be a component, so it can be attached to either player or enemy. Overall, this was a  fairly easy class to create. When creating the component, the input will dictate how much health the character  has. As for functions, I made the following methods: one that subtracts from health; one that adds to health;  and one that checks if the character has run out of health. If the character has run out of health, it will delete  that character, and check if it was a player. If it is the player, then it's game over.

A simple, clean class, but necessary for our alpha build. Since I worked on the projectile class, this was  extremely easy to test with enemy projectiles. Fortunately, it works as expected.

Animation-to-Sound Handler

Since our Alpha was drawing close, I was asked to start adding sounds into the game.  In addition to that, I was asked to build a system that played sounds based on the current player's animations. This would be  useful for playing sounds in exact accordance to what animation is playing, and provide programmers one simple location to edit/replace animation sounds.

First, I designed this to be a component, so that it could be added to any character with a reasonable amount  of animations (be it player, enemy, or otherwise). This component, the AnimationSoundManager, had access to that character's avatar, and this avatar held information about what animation was currently playing. Thus, my class looks for when a new animation is played, and checks if there is an associated sound file for it. If so, it plays the sound, and waits for a new animation to activate. I give thanks to Blake who suggested a  system for storing the previous animation to compare with the current one to see if a new animation had triggered.

However, I ran into a little problem.  I had no way to shut off looping sounds from my AudioController class.   Thus, I restructured that class as well to include a way to delete clips from the previous animation.  I also programmed a function that cleaned up clips that had completed. Previously, they still existed even after they finished, but now they are properly removed.  This should prove much more efficient down the road. Additionally, I programmed a simple mute functionality that would either un-mute or mute all current clips when called (i.e. it reversed the current mute setting).

Another problem arose when I realized that the Windows version of our game doesn't switch animations  (because we only use a cube for our character on Windows). This proved an obstacle in seeing if the AnimationSoundManager was actually doing its job. To overcome this, I had to manually program changes  in the Cube's current animation (though this change was strictly to notify me when to play a sound). I decided  to keep these changes in, so that anyone playing on the Windows version would be able to hear animation  sounds.

In the end, this worked out well. We now have various sounds in our game to give it a little more life. Even though most of these sounds are placeholder, they add to the experience nonetheless.

Re-factored Projectile System

Our game went through a bit of a redesign in the last couple of weeks. This change altered how enemies and players were created and controlled. Thus, since my projectile system is based on the interactions between the two, I had to redesign the projectile manager a bit.

First, our new system is designed around adding components to a base character class.  Therefore, what defines a player or an enemy is what components are attached.  Therefore, I made my ProjectileManager class a component to be attached to either a player or enemy.  Porting my code into this format wasn't too difficult.

The next step was for the ProjectileManager to spawn arrow projectiles for enemy guards to fire. Unfortunately, the way objects were drawn was altered in the redesign, so I had some trouble porting my code.  However, one of our team members, Ron, had made a handy little class that handled the drawing of a model with our new system.

After all that, the logic still worked like a charm, and adding the new component to characters is rather easy now.  Thus, I'm glad with how this worked out, and am excited to expand upon my ProjectileManager to handle different types of projectiles.