Giving our skeleton a fighting chance!

Today, we implement our sketons attack animation. We’ve already gone through implementing new animations multiple times so I’m going to skip this step from now on.

With the skeleton attack animation set up, let’s go into the animator and set up the transitions:

We know idle to walk only happens when inCombat is false, so we know idle to attack will happen when inCombat is true. remember there’s no no exit or transition time going from idle to to attack. Going from attack to idle, we leave exit time alone and 0 transition time.

Hitting the skeleton now puts it in attack mode and it will attack until the player moves away. Great!

Maybe he’s swinging a bit too much, let’s turn on exit time on idle.

Seems a bit more believable. I would imagine a skeleton would have a hard time brandishing such a heavy axe around to be waving it like a magic wand!

One final thing, we should have our skeleton face the player if the player hits him in the back, the skeleton will just swing in his current direction:

To fix this, all we need to do is store a Vector that subtracts the Enemys position from the player. If it remains positive, the player’s on the right, if negative, the players on the left, and depending on that answer, we flip the sprite:

In our skeleton code:

So a new Vector2 variable is made and we call it direction, we subtract our position (the skeleton) from the player, and what’s left is a postive or negative number, if it’s positive, the players on the right (and we’re in combat mode), and no flipping needs to be made, if on the left however, and in combat, then we do flip the sprite:

Awesome! Nobody’s going to be pulling the wool over this skeletons eyes!

Now we’ll set up its hitbox; Like the player, we’ll go under sprite, create a new sprite called Hit_Box, add the UIBox for its temporary sprite, add a boxcollider2d set to trigger and a rigidbody with 0 gravity.

We then want to adjust our hitbox to the position of the first frame of the attack animation, We won’t need the sprite renderer anymore, so feel free to remove it. Also be sure to hit record so the position is recorded when you’re done.

Then select the next frame and do it again!

and again…

And do it for the rest of the 30 frames…

I put hitboxes on all the frames, but in reality, I could have skipped the first and last frames as those frames will be used to record turning the box collider on and off.

We first start by turning off the box collider outside of recording mode.

Then we turn on record mode and turn boxcollider back on in frame 1, and turn it off again on the last frame.

And like the player hitting himself originally, we have to tell the hitbox to ignore the enemy, so we’ll place them on their own layers called “Enemy” and the hitbox into “Enemy Attack”.

We then go into Project Settings and turn off Enemy in the Enemy Attack line so the hitbox will completely ignore the skeleton when attacking.

Now we’re ready to write code for our skeleton to attack our player! If we look at our attack script, we’ll see it’s pretty agnostic and it isn’t written for the player specifically. It’s only looking for an IDamagable attached so guess what? Let’s attach it to our skeletons hitbox! First, let’s move the Attack script out of the players folder and move it in the general scripts directory:

Next, we’ll attach the attack script to the skeletons hitbox.

And as you can probably guess, the player now needs an IDamagable attached to it so the attack can work. We’ll have to add a public Health variable with a get and set, as well as a public Damage function to comply with IDamagable.

For now, let’s just use a Debug.Log to check if our player is successfully hit:

And now our player is ‘damaged’ when our enemys hit collider touches our player!

The moss monster and spider setup take the same steps as the skeleton so you can just use these past few articles as reference, though I’m sure this is quickly becoming second nature! Tomorrow we’ll get into Loot!