2D Mobile Game: Enemy Attack
Intro
In this article, we will cover the following…
- Setting up the Enemy Attack animation
- Having the Enemy face the Player when Attacking
- Setting up the Hit Box for the Attack Animation
- Giving the Enemy the ability to Damage the Player
Enemy Attack Animation
After importing the Enemy attack animation we will want to think about when we will want to transition to it. The Idle state is the keystone, where it has a parameter (InCombat) that determines if it will transition to Walk or Attack. If InCombat is true, we will transition to Attack and if not, we will transition to Walk.
The animation transition is working, but we will notice that the Enemy faces the wrong way when it is attack from the back.
Enemy Facing Player
In fixing this we will use the Distance formula which is taking the Enemy’s position and subtracting it from the Player’s position. This will be stored in Vector3 variable (direction) and we are calling it direction because we can use the distance of the Player from the Enemy to determine what side of Enemy the player is current one.
In visualizing this, we log the direction value.
Looking at the X value of the Vector3, you can see if the Player is on right of the Enemy it is a positive value and if the Player is on the left, it is a negative value.
Using this knowledge, we can check the direction X value and if it less than 0 (negative value, player is on the left) we will want to flip the Enemy sprite. If the direction X value is greater than 0 (positive value, player is on the right), we will do not want to flip the Enemy sprite. We only want this flipping to occur when the Enemy’s animation is InCombat, so it doesn’t interfere with the Walking animation that has the Enemy flipping after it has reached it desired waypoint.
Enemy Hit Box Setup
It is time to add a Hit Box to the Enemy’s axe, so it can hit the Player and cause Damage. We create a Sprite called Hit_Box, and make it a child of the Enemy Sprite. Give it a basic sprite image, a BoxCollider2D with Is Trigger true, and a Rigidbody2D with Gravity set to 0. Once you have the Box Collider in position of the axe, you can remove the SpriteRenderer component.
In the Animation window, we are going to need to go through each frame of the Attack animation, while in record mode, and adjust the Hit Box to match the axe.
Playing through the Attack animation, we can see how the Hit Box is now tracked to the axe.
We want the Hit Box to only be active during the Attack animation. In the Inspector we will uncheck the Hit_Box game object to deactivate it.
Back in the Animation window, we enter Record mode, and activate the Hit_Box game object. This will have the Hit_Box active only when the Attack animation is playing.
The Enemy has to BoxColliders, one on the body of the Enemy another on the axe. We don’t want these two colliders to detect each other or it will cause the Enemy to damage itself. We are going to put them into two different layers; Enemy and EnemyAttack.
The Enemy will be layer Enemy.
The Hit_Box or axe, will be layer EnemyAttack.
In Project Settings, under Physics2D we can have the Enemy layer ignore the EnemyAttack layer using the Physics Matrix.
Enemy Damaging Player
We already have an Attack script being used by the Player’s Sword that detects when it has entered another collider. When it does, it makes use of the Damageable Interface which will call a Damage method of the game object that is being hit. In this case, the game object that is being hit is the Player.
This Attack script is not specific to any particular game object, so we can use it from our Enemy’s Hit_Box.
The only thing we need to modify is the Player script by adding the Damageable Interface. The Damageable Interface requires a public int for Health and a Damage method. If these are not added, it will return errors since these are requirements of the Interface. For now, we will just log “Player Damage” when the Player takes damage to show the Enemy Attack is now functioning.
We can see “Player Damage” is being logged when the Enemy hits the Player. In the future, we will add Player health and tie it to the UI, but this is a good start. Until next time…Cheers!
