 This video was brought to you by my patrons. Thank you so much for your support. Hello there! In the previous week I worked on Kitchentail's hit and hurt system and I also added a cool blocking mechanic. So the character can enter in a block state. I'm not using state machines here, but it can turn on the block. And when this happens it will block any sort of damage unless this damage is from a type that will break the guard. So every guard has a weakness and if the attack uses this weakness, the guard will be broken and the character will take damage. But before we start this video I want to ask you to go to the repository and start the repository and also to turn on the notifications on the repository so that you can get all these notifications and updates right when I update them to GitHub. And also I want to ask you to follow me on HIO so you can read the devlogs that I'm posting there every single Friday. So let's get started. So what we are going to achieve here is that you can see that I'm hitting the enemy here but it only takes damage when the guard is not up. This bubble is a representation of the shield of the character. So let me show you how this works. So if I go here into the player I will open the hit with box here and you can see that this hitbox has this player hit resource and this is what the player uses to attack. But the weakness of this bubble of this shield is actually the player fireball. So if I drag and drop this fireball hit here now I can break the character guard and start to attack him. So in this video I will show how did I achieve that. So let's get started. So let's start with the attack class. I will open this attack node here. So if I open the script here basically what an attack does is that it will execute or cancel itself and when it executes it will check if the cooldown is not running. So we have a cooldown here and a cooldown timer. So if this cooldown is not running so if the cooldown is finished it will execute and it will tell other classes that this attack is executing and it will start the cooldown and the duration timer. The duration is basically the duration of the attack really. So let's say I have an uppercut. I can make the duration of the uppercut the same duration of an animation for instance or something like that. So when the duration timer times out it will emit that this attack finished but if the player managed to cancel the attack in the middle of an animation something like that the duration timer will stop and the attack will finish as well. So you can stop an uppercut for instance in the middle of the animation or something like that. And I think that this is a good approach to an attack because now I can abstract this attack into a weapon, into a punch, into a kicker, anything. I can just pick up this node and I can say oh this is a punch attack so this has this duration, this has this cooldown and I can also use that for weapons so I can have like a dagger that has a given duration and a given cooldown and then an axe which has a different duration, a different cooldown and so on and so forth. So by now I think that this attack class is closed already. I won't modify it unless I find a bug or something like that. I will just try to expand this class. So now let's talk about the hitbox. So the attack is meant to work together with the hitbox because the attack will execute and it will tell other classes that the attack is started and in this case, in this event, the hitbox will also activate its collision shape so you can see that I have here four different collision shapes but I think that I will take rid of that and keep each hitbox with only one collision shape and I don't want to have this responsibility of having multiple collision shapes and have the hitbox managing which one should be disabled or enabled. I think that this is not a good thing because if you go here in the hit you can see that each hit has a hit resource and if I want to, I want to have for instance a hit for a jab or a hit for a punch and a hit for an upper punch, something like that. With a single hitbox it will be difficult to manage that. Instead I can have two different hitboxes to do that. So if we go here into this hit resource and actually if I open this hit resource here you can see that basically this is a data container. So this resource here will encapsulate all the information of the hit so basically the damage information. By now it has a damage property which is the amount of damage that this hit will inflict and it also has a team property because if I want to I can create two different resources for different damage source so I can have a player and an enemy using the same resource but with different teams so one can inflict damage on the other. And I can expand this resource to add damage types or let's say elements or something like that. I can keep expanding this hit resource. And in this hitbox specifically I have the normal hit but in the player I have the player hit as you can see here so I can have the player hit or I can have the enemy hit. And you can see that the enemy hit has a different team from the player's hit. So let me reset that. So let's open this hitbox scene here. You can see that I didn't add any collision shape because I think that it's better to keep the workflow of Godot itself. So when you create an area in Godot you also have to add the collision shapes and I think that this is a better workflow than to keep editing a collision shape that is inside the hitbox and you have to always create a new resource and something like that. So instead we create a hitbox, we add a hitbox to the scene and then we add the collision shapes that build up this hitbox so I think that this is a better workflow for me. Now opening this hitbox script you can see that basically what this does is that it will try to confirm a hit. So it will activate the hitboxes and stuff like that. I want to remove this method because I don't want to add the responsibility of managing which collision shapes should be active or not. I think that the hitbox should activate or deactivate every single collision shape that builds itself up. So I think that I will remove this and let another class tell which hitbox should be activated or deactivated through this disable hitboxes and activate hitboxes methods here. Let me know your thoughts about that if I should keep this set hit direction in the hitbox or I should delegate this to another class that will activate hitboxes independently. So I can take rid of these and also of these methods here and throw them to all the class that will manage which hitbox should actually be active now. So let me know that in the comments please. But basically what this hitbox will try to do is to, in the end, it will try to confirm a hit. And I think that I will use that because with a hit confirmation system I can build up a combo system. So each time a hit confirms, so each time the player or an enemy land a hit on another enemy or an opponent, I can keep building up the combo. So I can have like a system for a chain of combos like having on the screen how many hits you did without missing. Or I can also have a combo system which each hit landed will build up the next type of attack. So it can start with a punch and end with a greater hitbox, for instance. Next, let's talk about the hurtbox. So the hurtbox is very simple. So it follows the same design as the hitbox. So it only carries a collision shape which is designed inside the scene that will use this hurtbox. So if I open the hurtbox scene, you can see that it doesn't have any collision shapes inside of it. If I open the script, you can see that basically the hurtbox will also try to confirm a damage inflection. It has an invincible state. And basically what it will do is that it will take an area that is on the same layer as it, and it will try to access the hit that is inside this class. So since the hitbox and the hurtbox are on the same layer, this area here will be the hitbox. And we know that the hitbox has this hit resource, this hit property which leads to a hit resource, right? And what this will do is that it will try to check if this hurtbox is inside the group that matches the hit team property. We saw that the hit has a team property, which by default is the player. So if this group doesn't match the hit team, it will then lead to a hurt confirmation, to a damage inflection. So it will emit a signal that this hit landed and it will tell what this hit is. It will actually pass this hit to wherever class is interested in this hit resource. And then it will try to get hurt by this hit. In the get hurt method, it will get this hit. And the first thing that it will do is that it will check if it is invincible or not. And then it will emit, if it's not invincible, it will emit a signal that it got hurt. And then it will emit to other classes such as the health, so the health class, the health node. What is the damage that this hit inflicted on the hurtbox? So each hurtbox will try to handle this hit differently. So I can override this get hurt method in other hurtbox. So each hurtbox will try to manage this hit damage in different ways. So let's say I can have a hurtbox for the character body. It will like, I can add an arm of in that. And it will emit a signal telling that even though this hit has 10 damage, I managed to defend 3 damage, so the actual damage is just 7, something like that. And I can have like a hitbox for the head and this hitbox will take more damage. So each hitbox will have different ways to handle this hit damage. So I can basically override this get hurt method to achieve this behavior. And finally, let's go to the guard node. You can see that this guard node has a weakness hit and this is what this guard will use to tell whether this hit can break the guard or not. So let's open this script here. Basically, this guard follows the same logic as the attack. So it executes, it will tell that this guard state is started, it can cancel and it will tell that this guard state finished. And these are the signals that I use to tell this hurtbox to enter in the invincible state or not. So the hurtbox will not get any damage or the hurtbox can get a damage. So if the character is guarding the hurtbox will not get any damage but if the guard is down, so if the guard is finished the character will take damage. The hurtbox will take damage. And here is the method that check is for the weaknesses. So it takes a hit that is passing through this hurtbox so the hurtbox when confirms a hit landed on it it will emit a signal with this hit information so with this hit object. And when this guard gets this information it will pass through these checkings here. So if it's not blocking it will not try to check for this hit. But if it goes down to this checking and the hit that it just got matches the hit that represents its weakness it will cancel itself. So it will emit the signal that this guard is finished so this guard is broken. And this works because indoor road engine resources are only instantiated once so the same resource that I use for the attack so for instance the attack of the enemy can be the weakness of a guard so we only need to drag and drop the same resource to the guard and to the attack of the enemy so the player can have a weakness to the enemy's attack. So this is how it works. So this is how I achieve this combat system so I inverted the weakness of the enemy so that the fireball doesn't hit the enemy but the weakness is actually the player's melee damage so if you go here I can break this character guard and I can try to inflict some damage but if the guard is up the fireball does no damage so I have to break this guard and then do damage with the fireball. And that's it. That's how I achieve this behavior. So if you like this kind of content if you are liking the Kitchen Tales process these devlogs that I'm making here please leave a thumbs up, don't forget also to subscribe and also turn on the bell, do all this stuff for engagement and that's one thing that is important not for data only but I really like to know your comments on that topic that I said earlier so if I should keep the hitbox managing each shape or if all hitboxes should turn on and off every single collision shape and let another class tell which hitbox should be turned on or off. So this is very important for me. Please let me know. So that's it. Thank you so much for watching. Keep developing and until next time.