Well, all of our hard work as finally come to fruition. Our game has been submitted for review in the XBLIG community, and we have officially been passed for release.
It was a tough process. We had to have a team get-together to squash bugs and to refine the game where we could before we released for review. Through it all, however, I feel we have a great game that is unique in its premise and game-play We had a press release event to help spread the word about our game, and we can only watch and see what happens from here.
If you're interested, you can find my game here (and it's only $1 to boot):
Avatar Trials: Ninja Uprising on XBOX Marketplace
I'm glad to have been a part of this team, and to lend my creative talent to help create this game. From gameplay to level design to music composition, I had a blast creating this game, and enjoyed working together with my team. What lies next is a mystery as I near graduation, but I'm hopeful that I can continue creating unique and entertaining games.
Adam Durant's Development Portfolio
Saturday, April 27, 2013
Level Building: Level 3?
After playing through all the levels, our team decreed that my Level 2 was more difficult than the current Level 3. Thus, I was tasked with taking my Level 2, and adding a bit more difficulty to make it a truly challenging level.
Therefore, I took the base of my Level 2 and modified it. I made a few minor changes to the beginning of the level, but I largely modified the last sections. By that, I mean I tore apart the last section and created a few new ones. These sections require a lot more skill that befits a final level, and should truly test a player's ninja ability.
Here's a picture of the new level (it's small because it's a much larger level than before):
As you can see, there have been a lot of changes towards the end, and many additional obstacles the player has to overcome. Fortunately, given the level of difficulty, I made it so that the island serves as a emergency landing platform should the player mess up (though this will not always save him from demise). Thus, even if the player messes up, there is a chance he won't have to start the entire level over again.
Overall, I'm quite pleased with how it's turned out, and hope it will challenge players.
Friday, April 5, 2013
Final Level Theme
Since, our last level is meant to be a truly challenging task, I thought I'd compose a final level theme that would suite this epic endeavor.
I wanted the theme to start out slowly, and then build up to a steady pace (thus building up the tension when the player is attempting the level). It's a suitably driven theme that should motivate the player to climb ever higher in the last level. Have a listen, and I hope you enjoy it!
I wanted the theme to start out slowly, and then build up to a steady pace (thus building up the tension when the player is attempting the level). It's a suitably driven theme that should motivate the player to climb ever higher in the last level. Have a listen, and I hope you enjoy it!
Monday, March 18, 2013
Level Building : Level 2
Here's the second level I've built in Unity 3D
I spent the better part of my break working on Level 2 for the game. This level takes off the kid gloves. The player can now easily die if he fails at an obstacle. Also, I started to combine obstacles, so the player would have to utilize multiple abilities to overcome them. For example, there's a part where the player will have to double jump to a wall, and then wall jump off of it to reach the platform. That said, there are some really enjoyable obstacles in this level, and some well hidden secrets as well. I also toyed with a new ability vanish (or rather my old attack ability turned into a platforming ability).
Now vanish allows the player to ascend in a cloud of smoke bypassing any platforms that might be in the way. It acts as a third jump as well, but the player has no momentum once it is activated, so the player will have to be precise. The ability to go through platforms allowed me to build some new puzzles, and I'm excited to see where I can go from there. I'll, of course, be tweaking it, so that it doesn't break obstacles unintentionally.
I recorded a run through on the windows version (yeah that means you'll have to stare at a block doing these obstacles instead of an avatar). Here's a preview of my second level (music in the video was also composed by me).
I spent the better part of my break working on Level 2 for the game. This level takes off the kid gloves. The player can now easily die if he fails at an obstacle. Also, I started to combine obstacles, so the player would have to utilize multiple abilities to overcome them. For example, there's a part where the player will have to double jump to a wall, and then wall jump off of it to reach the platform. That said, there are some really enjoyable obstacles in this level, and some well hidden secrets as well. I also toyed with a new ability vanish (or rather my old attack ability turned into a platforming ability).
Now vanish allows the player to ascend in a cloud of smoke bypassing any platforms that might be in the way. It acts as a third jump as well, but the player has no momentum once it is activated, so the player will have to be precise. The ability to go through platforms allowed me to build some new puzzles, and I'm excited to see where I can go from there. I'll, of course, be tweaking it, so that it doesn't break obstacles unintentionally.
I recorded a run through on the windows version (yeah that means you'll have to stare at a block doing these obstacles instead of an avatar). Here's a preview of my second level (music in the video was also composed by me).
Level Building : Level 1
We've had a change in game design. We're shifting our focus to obstacle course design for our game. The ninja theme is still intact as the player will still use ninja-esque acrobatics and abilities to complete the courses; however, we have decided to remove the combat elements from our game (i.e. attack abilities and enemy AI). We made this decision because our deadline is starting to creep up on us, and we need to focus on the elements of our game that we have implemented solidly. Our platforming elements have been constantly updated and maintained since the beginning of the project, so we decided to polish that mechanic.
That said, we needed to start building levels that suited this change in direction. Since we have little time left before the project needs to be completed, we decided to assign more people to level design. I was one such person enlisted for this task which I was agreeable with. I was excited to roll up my sleeves, and see what I could build given my extensive experience with 3D platforming games.
Fortunately, one of our programmers cooked up a level builder in Unity 3D, so I could place the assets created by our artists with relative ease. This proved invaluable as I could devote the entirety of my effort towards building levels with good flow, challenging obstacles, and general badassery (oh and secrets too).
After a good day of work, I finished my first level layout. It was meant to introduce players to the basic abilities they have at their disposal. Thus, each obstacle is fairly easy, and is made in a way that won't harm the player if he makes a mistake. I recorded a run through on the windows version (yeah that means you'll have to stare at a block doing these obstacles instead of an avatar). Here's a preview of my first level (music in the video was also composed by me).
That said, we needed to start building levels that suited this change in direction. Since we have little time left before the project needs to be completed, we decided to assign more people to level design. I was one such person enlisted for this task which I was agreeable with. I was excited to roll up my sleeves, and see what I could build given my extensive experience with 3D platforming games.
Fortunately, one of our programmers cooked up a level builder in Unity 3D, so I could place the assets created by our artists with relative ease. This proved invaluable as I could devote the entirety of my effort towards building levels with good flow, challenging obstacles, and general badassery (oh and secrets too).
After a good day of work, I finished my first level layout. It was meant to introduce players to the basic abilities they have at their disposal. Thus, each obstacle is fairly easy, and is made in a way that won't harm the player if he makes a mistake. I recorded a run through on the windows version (yeah that means you'll have to stare at a block doing these obstacles instead of an avatar). Here's a preview of my first level (music in the video was also composed by me).
Level Theme
Time for another composition. I composed this theme to be used in a level. It starts right out at a good pace, and helps the player feel the energy of being a ninja (complete with japanese instrumentation just for that extra ninja touch).
It maintains near constant energy throughout, but modulates slightly during some movements to be either a little slower or a little faster. This helps give some variety to the piece, but doesn't lose the drive behind it. I had fun composing this one, so have a listen and enjoy!
It maintains near constant energy throughout, but modulates slightly during some movements to be either a little slower or a little faster. This helps give some variety to the piece, but doesn't lose the drive behind it. I had fun composing this one, so have a listen and enjoy!
Crumbling Platforms
Recently, we've been developing more hazards for our levels. Thus, I volunteered to create platforms that would crumble after a player steps on them (after a set amount of time after the player touched it).
First, we knew this would be a trigger-able event, so using our trigger system seemed obvious. There were three important variables to keep track of for this event. First, the time it takes for the object to crumble after the player lands on it. Second, the time it takes for the object to fully crumble (i.e. the player can't stand on it any more). Third, the time it takes for the object to be restored (so the player can try again if he failed).
I handled most of the logic in the update function. When a crumble trigger event is activated, it sets a crumbling flag. The update function checks for this flag, and if it is true, it will count down the time it takes for the object to start crumbling. Once that timer has elapsed, it will trigger the flag for the object to crumble while disabling the crumbling flag. The update function works similarly to update the timer until it has elapsed (which will mean the object is no longer valid as a platform). Finally, the current flag is disabled, and the restore flag is enabled. Again, the update function will count down; once the restore timer has elapsed, the platform will reform (and, of course, the restore flag is disabled). The crumbling platform can then be triggered again.
There were a few problems with actually restoring the object again. I couldn't simply just delete the object when it crumbled, as I had to be able to restore it to its previous position. Thus, I had to be able to disable and re-enable three aspects of an object. The actual physics body has to be disabled, so the player wouldn't collide with it. The display model had to be disabled (or in essence invisible), so the player wouldn't see it. Finally, the trigger had to be disabled, so it couldn't be tripped pre-maturely. The display model was easy enough since there was an invisible toggle already implemented, but the other two were a bit more tricky.
In short, I collaborated with a few teammates to write enable/disable booleans for the physics body and trigger. When enabled, the physics body boolean would add the physics body to the physics engine, and the trigger boolean would simply ignore colliding information. The reverse is true when the variables are disabled.
With that obstacle out of the way, I had a working crumbling trigger that would destroy a platform after the player stepped on it, and then be restored after a set amount of time. It works rather well, and am looking forward to seeing it in action in our upcoming levels.
First, we knew this would be a trigger-able event, so using our trigger system seemed obvious. There were three important variables to keep track of for this event. First, the time it takes for the object to crumble after the player lands on it. Second, the time it takes for the object to fully crumble (i.e. the player can't stand on it any more). Third, the time it takes for the object to be restored (so the player can try again if he failed).
I handled most of the logic in the update function. When a crumble trigger event is activated, it sets a crumbling flag. The update function checks for this flag, and if it is true, it will count down the time it takes for the object to start crumbling. Once that timer has elapsed, it will trigger the flag for the object to crumble while disabling the crumbling flag. The update function works similarly to update the timer until it has elapsed (which will mean the object is no longer valid as a platform). Finally, the current flag is disabled, and the restore flag is enabled. Again, the update function will count down; once the restore timer has elapsed, the platform will reform (and, of course, the restore flag is disabled). The crumbling platform can then be triggered again.
There were a few problems with actually restoring the object again. I couldn't simply just delete the object when it crumbled, as I had to be able to restore it to its previous position. Thus, I had to be able to disable and re-enable three aspects of an object. The actual physics body has to be disabled, so the player wouldn't collide with it. The display model had to be disabled (or in essence invisible), so the player wouldn't see it. Finally, the trigger had to be disabled, so it couldn't be tripped pre-maturely. The display model was easy enough since there was an invisible toggle already implemented, but the other two were a bit more tricky.
In short, I collaborated with a few teammates to write enable/disable booleans for the physics body and trigger. When enabled, the physics body boolean would add the physics body to the physics engine, and the trigger boolean would simply ignore colliding information. The reverse is true when the variables are disabled.
With that obstacle out of the way, I had a working crumbling trigger that would destroy a platform after the player stepped on it, and then be restored after a set amount of time. It works rather well, and am looking forward to seeing it in action in our upcoming levels.
Friday, March 15, 2013
Checkpoints
We have recently been messing with triggers in our levels. These, aptly named triggers, trigger certain events when a player collides with it. The types of triggers we currently have are Quest Triggers, Ability Triggers, Killzone Triggers, and Load Model Triggers. These are all quite important, but we all decided that we also needed a Checkpoint Trigger, so the player wouldn't have to attempt the entire level again if he/she happened to fail.
Thus, I was put on the task. First, I had to learn about how our trigger system works (since I hadn't designed it). After some research, I found out how we were handling triggers. The actual trigger object is what the player collides into. However, we add, or subscribe, these component-like trigger events to the trigger object. When the trigger is tripped, all subscribed trigger events will activate.
With that in mind, all I had to create was the checkpoint trigger event. The checkpoint in this game needs to only store the position of the trigger that contains it. However, the player needs to store the current valid checkpoint, so he/she can reference it when respawning.
Thus, I created a CheckpointTracker component for the player. It kept track of the current checkpoint, and gave the checkpoint's position coordinates when ReturnToCheckpoint() was called. I also added a function that kept track of the id number a checkpoint had. This was implemented to prevent accidental checkpoint regressing; i.e. somehow a player skips a checkpoint, and then hits a further one. We don't want the player to return to a skipped checkpoint, and suddenly lose progress for it. It's more of a safety precaution, but one that should help minimize such odd circumstances.
With that completed, all I had to do for the checkpoint trigger event was to subscribe it to the owning trigger, and then supply the position/id number to the CheckpointTracker. If the id number was greater than the current checkpoint, the supplied position would be registered as the new checkpoint (and the id number will be set to the supplied one).
I've tested out this trigger, and it works fantastically. I even tested out a circumstance where I skipped a checkpoint and activated one farther away. I then walked back to the previous one, and killed the avatar. It spawned correctly at the checkpoint farther in the level, so I'm satisfied with this trigger event.
Thus, I was put on the task. First, I had to learn about how our trigger system works (since I hadn't designed it). After some research, I found out how we were handling triggers. The actual trigger object is what the player collides into. However, we add, or subscribe, these component-like trigger events to the trigger object. When the trigger is tripped, all subscribed trigger events will activate.
With that in mind, all I had to create was the checkpoint trigger event. The checkpoint in this game needs to only store the position of the trigger that contains it. However, the player needs to store the current valid checkpoint, so he/she can reference it when respawning.
Thus, I created a CheckpointTracker component for the player. It kept track of the current checkpoint, and gave the checkpoint's position coordinates when ReturnToCheckpoint() was called. I also added a function that kept track of the id number a checkpoint had. This was implemented to prevent accidental checkpoint regressing; i.e. somehow a player skips a checkpoint, and then hits a further one. We don't want the player to return to a skipped checkpoint, and suddenly lose progress for it. It's more of a safety precaution, but one that should help minimize such odd circumstances.
With that completed, all I had to do for the checkpoint trigger event was to subscribe it to the owning trigger, and then supply the position/id number to the CheckpointTracker. If the id number was greater than the current checkpoint, the supplied position would be registered as the new checkpoint (and the id number will be set to the supplied one).
I've tested out this trigger, and it works fantastically. I even tested out a circumstance where I skipped a checkpoint and activated one farther away. I then walked back to the previous one, and killed the avatar. It spawned correctly at the checkpoint farther in the level, so I'm satisfied with this trigger event.
Inhibitor Component
During my ability creation, several of my ninja abilities affected the enemies' movement. Thus, I thought it prudent to make a component that controls the owning character's movement speed.
After some discussion, we decided to expand this into a more broad component that affects all aspects of a character's control (movement speed, stunned, frozen, etc). Thus, we called it the Inhibitor class.
Simply put, this class created flags for each type of inhibitor effect (like movement speed). When this flag is triggered, the update function will handle the execution of the inhibitor effect for as long as the flag is triggered. However, each inhibitor effect has a timer that is set when the flag is triggered (which ticks down every time the update function is called). Once that timer finished, it sets the flag to false.
It's very simple to maintain and call, so I'm quite happy with it.
After some discussion, we decided to expand this into a more broad component that affects all aspects of a character's control (movement speed, stunned, frozen, etc). Thus, we called it the Inhibitor class.
Simply put, this class created flags for each type of inhibitor effect (like movement speed). When this flag is triggered, the update function will handle the execution of the inhibitor effect for as long as the flag is triggered. However, each inhibitor effect has a timer that is set when the flag is triggered (which ticks down every time the update function is called). Once that timer finished, it sets the flag to false.
It's very simple to maintain and call, so I'm quite happy with it.
XBLIG EVIL LIST!
Since we are submitting to the XBLIG arcade, there is a submission process we have to pass for our game to be published. Fortunately, there exists an already compiled list of oft-checked items that your game has to pass, at the least, to be accepted.
I was assigned to keeping track of what our game has passed, and what needs to be fixed. Thus, I compiled a list of the items in the checklist, and made a Google doc that would keep tabs on our progress. Below is the link to this document.
Evil List
I'll also update this post to keep up with the parts I personally fixed for our game.
1. I found that our screen wasn't adapting properly for widescreen/standard size. This was largely the GUI elements of the game, so I had to go digging into our GUI code. Fortunately, since we only have to worry about standard and widescreen when it comes to our scaling, I only had to add a scaling factor that was set according the screen mode. It was a relatively simple fix, and it worked flawlessly.
2. After some testing, I found that a second controller (not the profile logged in for the game) could control the menu screen, but not the actual game if they started it. This happened to be an evil list item, so I went to work. Again, this was a GUI issue, as the menu screen needs to keep tabs on what player's input is valid. Thus, I modified our GUI screens to only accept input from registered controllers (which XNA was all too happy to provide for me). This was accomplished by simply adding a check in the button input function, so that it would check the current controller's port to the registered ports provided by XNA.
I was assigned to keeping track of what our game has passed, and what needs to be fixed. Thus, I compiled a list of the items in the checklist, and made a Google doc that would keep tabs on our progress. Below is the link to this document.
Evil List
I'll also update this post to keep up with the parts I personally fixed for our game.
1. I found that our screen wasn't adapting properly for widescreen/standard size. This was largely the GUI elements of the game, so I had to go digging into our GUI code. Fortunately, since we only have to worry about standard and widescreen when it comes to our scaling, I only had to add a scaling factor that was set according the screen mode. It was a relatively simple fix, and it worked flawlessly.
2. After some testing, I found that a second controller (not the profile logged in for the game) could control the menu screen, but not the actual game if they started it. This happened to be an evil list item, so I went to work. Again, this was a GUI issue, as the menu screen needs to keep tabs on what player's input is valid. Thus, I modified our GUI screens to only accept input from registered controllers (which XNA was all too happy to provide for me). This was accomplished by simply adding a check in the button input function, so that it would check the current controller's port to the registered ports provided by XNA.
Saturday, March 2, 2013
Tutorial Buttons
One of my recent tasks was to design a way for buttons to pop up onto the screen. This would be used to help players use the proper abilities in a tutorial level.
My first task was to design how I wanted to show these buttons exactly. Since this is an XBOX 360 game, I decided using the actual buttons from that pad would be suitable for these popups. I then decided to add a
small animation that looped between the button being unpressed to the button being pressed; that way it both draws the players attention (since movement catches the eye), and gives the proper information to continue. Here are the two pictures I used for the buttons being unpressed and pressed.
You might notice I altered the perspective on the second picture so it looked like the buttons were being pressed down.
With that done, I needed to design the class that would support this functionality. Thus, I made the PopupButton class. Since this could be called from anywhere from within the mechanics of the game, I made it a static class. I made a simple function called DisplayButton which took in the button to be displayed. It then loops between the unpressed and pressed state until the RemoveButton function is called. It's very simple to use, and works as intended.
Finally, I had to add the ability for the button to have text to explain what it was going to do. For this, I had to delve into the UI that one of our other members had implemented. By implementing an inheritance class for the tutorial text, I was able to create a UI functionality that displayed a button and text to go alongside it.
At the moment, the tutorial buttons are working great! Here's a short video showing it in action.
My first task was to design how I wanted to show these buttons exactly. Since this is an XBOX 360 game, I decided using the actual buttons from that pad would be suitable for these popups. I then decided to add a
small animation that looped between the button being unpressed to the button being pressed; that way it both draws the players attention (since movement catches the eye), and gives the proper information to continue. Here are the two pictures I used for the buttons being unpressed and pressed.
You might notice I altered the perspective on the second picture so it looked like the buttons were being pressed down.
With that done, I needed to design the class that would support this functionality. Thus, I made the PopupButton class. Since this could be called from anywhere from within the mechanics of the game, I made it a static class. I made a simple function called DisplayButton which took in the button to be displayed. It then loops between the unpressed and pressed state until the RemoveButton function is called. It's very simple to use, and works as intended.
Finally, I had to add the ability for the button to have text to explain what it was going to do. For this, I had to delve into the UI that one of our other members had implemented. By implementing an inheritance class for the tutorial text, I was able to create a UI functionality that displayed a button and text to go alongside it.
At the moment, the tutorial buttons are working great! Here's a short video showing it in action.
Prison Theme
I've spent some more extra time to compose more music for the game. Unfortunately, our team decided to scrap the prison level, so this one is a little out of place at the moment, but I'm still proud of it.
As a prison theme, I composed it to give a feeling of dread and hopelessness at first. I used Japanese instruments again to keep the oriental flavor. Though, to keep the ninja feel, I gave it a section where it picks up a bit to give a sense of action (as if escaping from the prison). From there, it loops back into the beginning of theme subtly.
Here it is. Enjoy!
As a prison theme, I composed it to give a feeling of dread and hopelessness at first. I used Japanese instruments again to keep the oriental flavor. Though, to keep the ninja feel, I gave it a section where it picks up a bit to give a sense of action (as if escaping from the prison). From there, it loops back into the beginning of theme subtly.
Here it is. Enjoy!
Ability Design: Shuriken Storm
Shuriken Storm
For my third ability, I previously wanted to implement Shadowstitch which rooted enemies it touched in place. However, I began to think that I was only designing mobility abilities. While this is fine, and is a great part of the game, I realized that a ninja also needs a some purely offensive abilities. Thus, I designed both the single shuriken attack, and a super attack where the ninja throws a whole barrage of shurikens at once. The simple shuriken acted as a fairly straightforward projectile attack, so I'll detail the Shuriken Storm ability.
I wanted to design an ability that the player could use to decimate a large group of enemies, but be costly enough that it wouldn't be prudent to do so otherwise. Thus, I made it so the ability created around 10 shurikens that spread out in an arc in front of the player. This creates a wide spread that will destroy most enemies in front of the player (given that they are weak enough to fall to a single shuriken).
The process of actually implementing this wasn't too difficult. After creating the single shuriken ability, all I had to do was have the ability create multiple instance of this ability with different trajectories. Simple and efficient! I amped up the energy cost, so that the player could only use this twice will full energy. I tested it, and it works fine for the most part. Some of the trajectories are a little wonky, but I suspect our physics engine is causing that. It'll need a little more tweaking, but I'm still quite happy with this ability.
For my third ability, I previously wanted to implement Shadowstitch which rooted enemies it touched in place. However, I began to think that I was only designing mobility abilities. While this is fine, and is a great part of the game, I realized that a ninja also needs a some purely offensive abilities. Thus, I designed both the single shuriken attack, and a super attack where the ninja throws a whole barrage of shurikens at once. The simple shuriken acted as a fairly straightforward projectile attack, so I'll detail the Shuriken Storm ability.
I wanted to design an ability that the player could use to decimate a large group of enemies, but be costly enough that it wouldn't be prudent to do so otherwise. Thus, I made it so the ability created around 10 shurikens that spread out in an arc in front of the player. This creates a wide spread that will destroy most enemies in front of the player (given that they are weak enough to fall to a single shuriken).
The process of actually implementing this wasn't too difficult. After creating the single shuriken ability, all I had to do was have the ability create multiple instance of this ability with different trajectories. Simple and efficient! I amped up the energy cost, so that the player could only use this twice will full energy. I tested it, and it works fine for the most part. Some of the trajectories are a little wonky, but I suspect our physics engine is causing that. It'll need a little more tweaking, but I'm still quite happy with this ability.
Ablity Design: Vanish
Vanish
I had a great deal of fun designing this ability. The premise was to create an ability that would help the player get out of sticky situations in style. Thus, the ability to vanish away in a poof of smoke seemed rather ninja- esque. However, I wanted to add a little extra flare to the ability, so I thought to also design an offensive aspect to it. Thus, I made it so the player also drops a bomb where he previously was. This created the feeling of escaping a perilous situation while simultaneously attacking a group of enemies.
Fortunately, I was able to make this ability much the way I previously designed it. I made it so the player, once the ability is activated, will vanish up into the air instantly. From there, the player can move slightly to alter his/her landing point. However, I thought of the situation where the player has a ceiling directly above him. Thus, I made it so, if such a situation occurs, the player would actually latch onto the ceiling where he could hang until the situation is less dangerous. This turned out to feel totally bad-ass, and I'm quite pleased with how it turned out.
The next part was the bomb left behind in the smoke. At first, I wanted it to trigger if an enemy attacked it (that way it would be more of a counter-attack for a skilled ninja), but I realized that might be a bit too complicated to implement well. Thus, I decided to give the bomb a proximity where it would explode. This helps it retain the counter-attack theme, but makes it a lot easier for it to be effective against enemies.
All in all, I'm quite satisfied with this ability. It feels like a tool a ninja would have, and it executes near flawlessly.
I had a great deal of fun designing this ability. The premise was to create an ability that would help the player get out of sticky situations in style. Thus, the ability to vanish away in a poof of smoke seemed rather ninja- esque. However, I wanted to add a little extra flare to the ability, so I thought to also design an offensive aspect to it. Thus, I made it so the player also drops a bomb where he previously was. This created the feeling of escaping a perilous situation while simultaneously attacking a group of enemies.
Fortunately, I was able to make this ability much the way I previously designed it. I made it so the player, once the ability is activated, will vanish up into the air instantly. From there, the player can move slightly to alter his/her landing point. However, I thought of the situation where the player has a ceiling directly above him. Thus, I made it so, if such a situation occurs, the player would actually latch onto the ceiling where he could hang until the situation is less dangerous. This turned out to feel totally bad-ass, and I'm quite pleased with how it turned out.
The next part was the bomb left behind in the smoke. At first, I wanted it to trigger if an enemy attacked it (that way it would be more of a counter-attack for a skilled ninja), but I realized that might be a bit too complicated to implement well. Thus, I decided to give the bomb a proximity where it would explode. This helps it retain the counter-attack theme, but makes it a lot easier for it to be effective against enemies.
All in all, I'm quite satisfied with this ability. It feels like a tool a ninja would have, and it executes near flawlessly.
Tuesday, January 29, 2013
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.
Subscribe to:
Posts (Atom)