- Star Ranger
- Star Ranger
What is Star Ranger?
A Stylish Hack and Slash Action Game that takes its inspiration from Tokusatsu and Saturday Morning Superhero Shows.
Take action against the forces of evil and save the world by inspiring the people with your sick action moves.
Why make Star Ranger?
As a kid, I loved watching Power Rangers growing up. I remember waking up on Saturday mornings, eating breakfast while catching the latest episode of Power Rangers SPD. Hearing them do their cool stunt moves and calling down their mechs was the highlight of my childhood. The thing that stuck with me though from watching these shows was how they inspired me. To never give up hope, that no matter how bleak everything looks, you just have to get back up. I take this lesson with me in everything I do, especially in my game development journey.
I knew when I began learning game development and programming that I wanted to capture the beauty of Kamen Rider, Power Rangers, and Super Sentai in game form. While there have been games that include these shows, they never try to capture the stylishness that the shows provided. I wanted to combine the stylish action combat seen in games like Devil May Cry, Bayonetta, and Hi Fi Rush, with the high intensity and cheesy action provided in the shows.
Roles:
Lead Designer for Gameplay and Effects
Lead Gameplay Programmer
VFX Artist
What did you make?
Created the gameplay system to make, modify, and test different attacks in a combo.
Setup and maintain the C++ code used by our gameplay ability system that is used in our attack system.
Designed and implemented the various attacks such as the Pull Back Lasso, the Ultimate Attack: Big Bang, the light and heavy attack combos, and the Parry System.
Created a smart AI for enemies to ensure the player doesn’t feel swarmed with attacks.
What have you learned?
Throughout the weeks I have worked on Star Ranger, I have gained a lot of practical knowledge such as how to work with Unreal Engine’s Gameplay Ability System, the principals of animation, how to make great effects. But I have also gained new skills in leading a team and effective communication as well as the know-how of User research and what are the correct questions to ask to play testers. Working with the group, it was imperative that made my code easily understandable and organized as to make it easier for my group to assess and bugfix the game and also act as an example to follow when they do their own code.
The Development Journey
Week 1:
So, in this first week, we discussed in a meeting the main gameplay loop that we envisioned our game to be. We are taking inspiration from games like Zenless Zone Zero and Monster Hunter to blend combo games and giant monsters. We wanted the main character to wield a heavy chainsaw greatsword and the world to be inspired by eldritch horrors. We definitely want a combo mechanic that would powerup the player as they string more and more hits towards and opponent as well as implement a dodge roll and parry system to make the combat more fluid.
This week has been mainly setting up Unreal Engine base and setting up the player character so that I can start to work on the basic combo and more advanced movements like dodging for the following week. I have been looking at videos and tutorials in making easy combo systems in Unreal Engine 5 as well as trying to understand the best ways to implement a good feeling attack system. The video from Sakurai where he breaks down attack animation has been really helpful.
Week 2:
For this week, the group discussed ways to use the Gameplay Ability System plugin that Unreal Engine provides. We talked about how we could implement new abilities for combo strings as well as how to implement new abilities that uses a string of different button inputs. We also worked on getting a model of sword that we are going to use, and I implemented the basic combo system for our light attack string. We would need to adjust timings for buffering inputs and make sure that the sword has proper collision timings in order to feel smooth and responsive. I also included a dummy actor that players can hit which causes it to do a small hit reaction.
Week 3:
For this week, I tried implementing the preliminary start of our Rev Mechanic that rewards players who land their attacks successfully. The Rev state allows the players to attack faster and do more powerful combos.
This week has been mainly making the light attacks feel more impactful so that when we work on other attack strings, we would already have the basis of attack feel. We added a functionality for light camera freeze and shake that is based on the direction of the attack as well as adding a new attack, the dash attack. This week, I will be trying to implement the heavy attack that uses the holding down of our attack buttons, similar to what we talked about with the Spiderman attack system, where our attack button goes into two different attack branches depending on if the player held or simply presses the button.
Week 4:
The last week, we just discussed the player feel with the bulk of the abilities in the game already as well as implementing the Heavy Attack combo string so that it could interweave with the light attack combo string and the dash attack so that the players can choose if they want to do a light attack or heavy attack in their three hit combo. It was my job to do the implementation and throughout the week it was just adjusting when and where the players can combo from one ability to another and how fast the attack would be.
Since the heavy attack is fairly new to the game, the combo string and numbers would need to be adjusted with more playtime. I also added a nice charge meter in to give the player a secondary sense of powering up an attack. Instead of doing more damage as the player charges up, it instead makes the attack complete faster if you charge it up. This would incentivize the player to charge the attack instead of just holding and letting go of the button quickly, while not severely punishing those who just needs the damage. The heavy attack also pushes the player forward a lot so while it is powerful, it takes a bit to aim the attack in order to hit your opponent.
Week 5:
This week, we mainly focused on polished our pre existing combo system by adding effects and added juice. We divided up tasks to quicken the process, and I was tasked to polish up our attack sequence and our Rev mode. I added some weapon trails to our attacks to give it a nice swish look as well as adding variable camera shake in order to give each attack in the sequence some nice oomph. For the Rev mode, I went all out in trying to make it look as cinematic as possible. I added a combat camera that circles around the player when they activate the ability as well as adding some powerful charging lines, explosions, and camera shakes to really sell the power of the mode. Finally I added a neat animation before and after the move as well as add a nice overlay for the character that will really differentiate when the player is normal vs when they are revved.
For a nice added bit of polish, I added some nice knockback for our enemy and gave him a nice ragdoll when he's defeated since players are keen on trying to beat our dummy.
Week 6:
This week the tasks have been mainly bug fixes and working on some added effects in order to address the issues that our weapon did not feel like a chainsword enough as well as addressing other miscellaneous comments made by our playtesters.
A minor thing I did was to change the "eyes" we had on our enemy to a much more defined face as our playtesters were confused on the point of the spheres on our enemy.
I also made a nice Niagara affect to be used for our chainsword.
I'm still working on tweaking the damage numbers and animation speeds for the attacks but I believe that these small fixes would help bring the feeling we want a little more.
Week 7:
Alright so this week has been exploration on making a simple enemy AI system. I was tasked in creating both enemies and trying to build interesting logic between them. We decided on exploring the light vs heavy attacks so I decided to make an enemy that can be attacked by both light and heavy and a shielded enemy that must be attacked by a heavy first in order to break the shield first. In order to give the players more choice in how they take down each enemy, I also decided to allow both types of enemies be taken down if the player is in our revved state that way the player can either take down all the enemies with just the light attack to slowly build up the rev meter to kill every enemy, or methodically use their attacks to take the enemies down smarter. I feel like this encourages either playstyle well enough that it doesn't feel like one attack must be used on one enemy only.
I also did some refactoring of the damage system in order for it to work with the enemy. The following week is going to be juicing the enemy in order for their attacks to feel more impactful as well as juicing the player so that attacking feels much better.
Week 8:
This week, we had a discussion on what we wanted to do going forward as the team decided it best that we pivot the project due to unforeseen circumstances. We pivoted to continuing my personal project for the class and taken what we have learned from our previous project in order to not make the same mistakes again. So, this week was mainly playing catchup so that our current project could match where we left out. We created two enemies, and I went and designed several new UI elements for playtesting.
Among the UI Elements added was a simple health bar on the player and enemy health bar. The enemy health bar would only show up if the enemy has already taken damage or is currently being locked on by the player.
The player also has a lock on feature to specifically target one enemy, the camera would be locked to facing that enemy and it will show the enemy's health bar if they have not taken damage.
There is also a reticle on that would indicate what range the enemy is relative to the player. The yellow star indicates long range attacks would target that specifically enemy, and the blue star indicates melee attacks would target that enemy. The reticle shows who the player would hit with what type of attack.
The player also has an item switch ability that changes their combo. Currently, the way the player knows what type of item they have equipped is by seeing what item is on the player and the color of the helmet. We currently have two items which gives 2 different combos. The Red helmet would give the player a scarf they can use to bring enemies close to them, and the Blue helmet gives shoes that gives charge attacks.
We plan on adding more items as well as having animations for item switching.
Mid Semester Review
As we round up the middle of the semester, I want to look back at everything I have learned from both the YoungBucks project as well as the current Star Ranger project and specifically point out three major points during their development.
When I was creating the player’s attacks, we had to use an Unreal Engine plugin called Gameplay Ability System (GAS). One of the great things about GAS is that they are really nice for attacks that have different animations since the logic blueprinting allows for better organization and much easier grouping of similar attacks which we were taking advantage of. However, in two specific cases of our heavy attack animations, players noted that the sword swings did not feel impactful even with the addition of camera shakes, hit stun, and sound effects. One of our players noted that, “It felt like hitting an enemy with a wet noodle rather than a powerful sword.” After playing around with various timings for attacks, I uncovered what made it feel so weak: the motion of the attacks was too fast, which meant there was no sense of weight with the swing. In order to accurately achieve the feeling of heft of the sword in the attack, I looked into utilizing the ideas of anticipation and more pronounced key frames. Through some research, I figured out that the simplest solution to fix the animation was various notify calls within the montage to increase or decrease the play rate scale of the animation as it is playing to control the speed of the animation within the animation itself and to allow us to easily adjust the rate for any specific point. Once I had implemented many notify calls onto the animation, there was a noticeable positive difference where the animation felt much more weighty and powerful. There were distinct speed ups and slowdowns in certain parts of the animation that altogether did not change the timing of the attack too much but allowed the attack to have good follow through and anticipation. As our players noted during playtesting, the attacks felt much more powerful, and they could really feel the weight of the sword as they swung. We gathered that the players felt much more positively to the attacks now that we implemented the animation changes. After working on the fix for the animation, I learned a lot more about how Unreal Engine controls their Animation Montages and I was able to use the same notify blueprints to easily modify and future animation montages that I have to use in games I develop in the future. It provides an easy way to make minor changes to animations in the engine itself to test out timings without needing to redo animations and it also acts as a good visual reference for artists when they do retime their animations.
Another issue we faced during the development of our game has been the frustration players would feel when their attacks would miss targets that were extremely close by and that attacks in a combo would not all land because each attack changes the relative locations of the player and enemies so that the next attack in the combo does not land in the right location. This is a frequent problem due to the fact that our attacks always push the players forward in the direction they were facing when they initiated the attack. This was a big pain point for our players looking to chain combos together, so we had to fix the way our combo attack worked. I researched various different ways other games of the genre did their attacks (primarily DMC and Monster Hunter), and it seems to me that these games provided the players with a small buffer attack range where their attacks would magnetize towards the closest target in their peripheral and attacks in a combo would always target the same enemy in the sequence. With this knowledge, I created a small collision sphere on the player that acted as their attack zone. When the player presses the attack button, the game would check if there were any enemies in the attack zone and if so, find the nearest enemy in relation to the player. Once an enemy is set, the player would rotate to face the enemy before they go through the attack montage. The enemy is then saved as a variable for the next attack as long as it isn't dead. This change allowed for some leniency for the players as they attack and allows for attacks in a combo to hit far more often. After we implemented this change, we noticed far more playtesters doing combos and experimenting with our attacks. The players noted that they had more enjoyment doing combos as it was more consistent, and they finally get to feel the impact of the final hits of the combos instead of only ever hitting one or two stray hits in the combo. After implementing the changes, I learned the value of giving players leniency for their attacks and allowing for a certain degree of hit safety where the player is confident that an attack can land. This leniency range differs depending on the game genre and the type of combat the game needs, but it would still be an effective implementation for player controls.
During the development of our game, our team had a small crisis as we were about to lose a core member, and the state of the project was in flux. The team as a whole did not feel strongly about the project and I did not feel confident helming the project as its designer and vision holder as the initial concept of the game is not what I am personally passionate about. Alternative solutions that we discussed as a team with the help of the professor include having the existing core member remain on the team with a reduced workload so that we could maintain the same project. However, we decided as a group that the best action forward was to pivot the project from YoungBucks to Star Ranger, my personal project that I have been working on in parallel. I felt more comfortable taking the lead on a project I had passion for, and the team agreed that they would rather continue the work with me as the lead. After this decision was made, the project is going much more smoothly, and the team feels revitalized in their work.