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.
Adam Durant's Development Portfolio
Thursday, December 6, 2012
Sunday, December 2, 2012
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.
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.
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.
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.
Subscribe to:
Posts (Atom)