Game Design | Quality Assurance
Walk
.png)
I added a walk function to movement to prevent players from falling off ledges in stick situations. Basically the blueprint runs a number of checks to make sure it does not conflict with other code, such as being grounded and not crawling. The players movement speed is significantly reduced and a boolean is called to prevent falling.
Crawl
.png)
In typical metroidvania fashion, I added a crawl function. There are certain areas the player will have to crawl through in order to progress. It checks to make sure the player is grounded and then runs its course. Because we do not have animations yet, I created a fake crawl by reducing the size of the player and reducing his movement speed. This allowed the player to move through small spaces during testing. The crawl was eventually replaced with a crouch and slide.
Dash (Improved)
.png)
This build added more dash functions. Now the player can dash on the ground and in the air. The blueprint now checks to see if the dash is locked (This prevents spamming and activates during and deactivates after use). Because of the character being airborne, the impulse for dash had to be cut by half to prevent the player from getting launched across the level. In order for the air dash to make any difference from falling, I had to momentarily disable gravity, set Z velocity to zero, and return gravity to normal at the end of the boost.
Player Attack
.png)
This build I added combat mechanics. I condensed the camera zoom from earlier to the top grouping, where, as stated before, the camera will zoom in every time the player attacks to a specific limit and stop, and return after a cooldown. As for the attack, the color of the test dummy changes to indicate the attack, as well as displaying the collision sphere of the attack itself. During this time, a boolean is set (IsAttacking) that is used in enemy BP's, and the overlap events are turned on. After the attack duration all the settings reverse to normal.
Player Damage
.png)
.png)
All damage from enemies is cast to the player's custom events. There is a specific damage count for each enemy, and every time the player is hit, a function will run to check if the player's health is zero. If it is, the player will die and a death screen widget will appear with an option to return to the title screen. The camera switches from the SideViewCam to the DeathCam to display post processing effects. This was done because of conflicting post processing shader instances that were either overridden or completely disabled. It became easier to make one camera for each situation that called a different post processing.
Combat Effects
.png)
Every time the player hits an enemy, the screen will freeze momentarily to capture the action. When an enemy is hit for the last time, it initiates a finisher sequence. The game will pause, switch to another camera with a black & white filter, and add a widget that displays "DEAD" on the screen in red. The idea was to create a truly satisfying cinematic effect to the game. When the player is hit, the screen will shake to give the player instant visual feedback in a fast paced environment without distracting screen effects.
Ronin Enemy
.png)
When the enemy spawns he will run a repeating function that checks hitboxes do detect what is happening in combat. The pawn will roam to random locations as long as it does not have sight. When the player overlaps a collision box deemed the "sight radius", the sight boolean will set true and stop the loop shown above.
.png)
When the player is seen, and as long as the Ronin is not stunned [I will cover that below], he will chase the player and attack when he gets close.
.png)
When the Ronin attacks, he checks to make sure he is not stunned and his guard is not down. I will explain these in detail later. The next branch checks to see if the player's attack box is hitting the ronin's attack box.
.png)
If the branch is false, it will check if the Ronin's attack is overlapping the player hitbox. If it is, he will take damage. If the branch is true, it will check if the player is attacking. If he isn't the player will still take damage. If he is attacking, the next sequence will launch both characters back as their swords clash together.
.png)
Next it will pass another branch that checks if the Ronin is stunned, if not, add 1 integer to the Guard Count. Once the Guard Count has reached 3, the Ronin will be pushed back and Guard Down will be switched on, opening him for attack in another graph. The character changes material to indicate his guard is down and he will stop in place [maxWalkSpeed 0]. After a one second delay he will return to normal and begin attacking again. Lastly, it will check if the Ronin is stunned, and if so, initiate a timer to remove the stun.
.png)
When all enemies in SOTDC reach zero health, they turn grey and become stunned. At this point, the player must hit them one last time in order to kill them. However, they are stunned for a limited time, and once that time runs out, they will return to normal and fight again until they are hit once more [they will always sit at zero].
.png)
StartCombat is always being checked. If the player is attacking, and his attack circle is overlapping the Ronin hitbox, and the Ronin's guard is down, he will take 1 damage. It will then check if he is stunned, if so, the Ronin will die. If he is not stunned, but his health is at zero, he will become stunned. If he is still greater than 0 health, he will recoil back in response to being hit.