When developing the Player character further, we had noticed a lot of bugs and issues during this process, this post outlines our discussions, decisions and what I had to do in order to fix them.
Outlining Issues and Changes
Firstly, when Ayse, our Mechanics Designer pushed her initial version of the Player with its new attack, I noticed two issues: It was able to move around with the attack hit box activated and The player could hold left-click and the attack hitbox would constantly be active. Which caused me to do the following:
However, neither me nor our Mechanics Designer was unable to find a way around these two issues:
Which resulted in me suggesting to re-do the player entirely for a few reasons:
After explaining my though process, our Mechanics Designer also agreed it would be best for me to re-do the player entirely:
Fixing the Player
In order to fix the player, I had to re-do it entirely. Therefore, I not only had to recreate some existing features, I also needed to fix issues and bugs that occurred with the previous iteration of the player:
- Reduce the amount of attack directions the player had from 8 to 4
- (Reduce the workload on our animator)
- Make the players’ position locked while attacking
- (The player was able to move while attacking in the previous version)
- Can dash during attack
- Play the correct animation when the player attacked
- Deactivate the attack hitbox after a duration
Attack
Firstly, the function of the player that was causing the most issues was its attack, so this was the part I decided to tackle first. To begin, I created four separate hit boxes for its attack, one of which would activate when the player pressed left-click, depending on what direction the player was facing (Explained in the Movement section below).
To implement this logic, I created a new C# script called AttackNew:
This script had references to all of the player’s attack hitboxes e.g: public GameObject upMelee; and other variables for the attack, such as: public float atkDuration = 0.5f; , public bool isAttacking = false; , Animator anim etc.
In the Start() method, some of these references are gotten, like the player’s controller script and animator.
The Update() method is constantly calling the CheckMeleeTimer() method and checking if the player has pressed left-click, if they have and the player isn’t attacking, the HandleAttack() method is called.
This HandleAttack() method, sets the isAttacking animator bool to true, which can then be used in Unity’s animator to play the correct attack animation, it then starts the MeleeActive() coroutine and sets the isAttacking bool to true.
This MeleeActive() coroutine waits a small duration (For the windup of the attack animation) and then activates one of the melee hitboxes depending on what direction the player is facing. Then, after another small duration, the hitbox is set to inactive and the isAttacking bool and isAttacking animator bool is set to false aswell. To prevent the attack animation from being played and allowing the player to attack again.
Movement
Although I created a new C# script called PlayerControllerNew, the majority of it is kept the same from its previous iteration, such as its: Player movement, inputs and dash. However, one of the only differences is that this script stores what direction the player is currently facing:
In order to do this, I created 4 bools under the heading of “FacingDirection”, only one of these bools would ever be active at once, essentially storing which direction the player was facing.
In order to set these bools, I created a SetFacingDirection(bool right, bool left, bool up, bool down) method, which would take in input of 4 separate bools, each corresponding to a direction that the player could be facing.
Then, in the ProcessInputs() method of the PlayerControllerNew script, the method that was responsible for the players’ movement, I created a set of 4 if statements that would check which was the most recent direction the player had moved in, and would set the player to face in that direction using the SetFacingDirection() method. Therefore, the player would be facing a specific direction whether the player was currently moving in that direction, or had stopped moving entirely.
Furthermore, I created an Animate() method that would set an animator float called “isAttacking 1” to a certain value between 0 and 1 depending on what direction it was facing. Therefore if the player was facing right (90o) its isAttacking 1 float would be 0.25f (90/360).
Then, using this “isAttacking 1” float and the “isAttacking” animator bool, the player would be able to play the correct animation for its attack, according to the direction its facing.
The one other difference made in the PlayerControllerNew script is preventing the player from moving during their attack, in order to do this I created a reference to the player’s AttackNew script, which was then set in the Start() method.
The Update() method would then perform a check to see if the player was attacking before allowing any inputs to move the player.
This was the result of the new player:
Bug Fixing
Immediately after committing this version of the player, I tested it against enemies and found that the player was still able to input movement while the death animation was playing.
To fix this, I created an isDead bool in the PlayerHealth script which would be set to true when the player’s currentHealth less than or equal to zero.
In the PlayerControllerNew script, the Update() method would now check is the isDead bool was true before calling the Dash() coroutine or the ProcessInputs() method.
However, after testing the player against multiple enemies to get a feel of the game’s combat, I noticed two more glaring bugs:
This first bug was caused by the player’s script preventing any inputs after death, therefore after dying it would continue moving in the most recent input’s direction while the death animation was being played.
However, this was a simple fix, as I had already written the logic for this, anticipating that this bug may occur, setting the player’s velocity to zero if the isDead bool was set to true in the Update() method. However, I had put the logic in an if statement that would only execute if the isDead bool was false. Therefore, all I had to do was change the order of the code in the Update() method.
However, this second bug, where the player could take multiple instances of damage at once, was an oversight I made when creating the PlayerHealth script, I had forgotten to implement I-frames, an important quality of life feature made in a lot of video games that feature combat.
To implement I-Frames, I created a iFrames float and a canTakeDamage bool, now, whenever the player would take damage, an IsDamaged() coroutine would be called which would set the canTakeDamage bool to false, wait for an amount of seconds equal to the iFrames float and then set the canTakeDamage bool to true again.
Whenever the player’s TakeDamage() method is called, it checks if the canTakeDamage bool is true before it executes.
