How do I delete a collision polygon from a single animation frame?

Hitboxes are often separated into their own invisible helper objects as well. You would create and destroy these hitboxes as necessary on the correct animation frame. This goes for hurtboxes, terrain checks, ect as well.

Hitboxes are often separated into their own invisible helper objects as well. You would create and destroy these hitboxes as necessary on the correct animation frame. This goes for hurtboxes, terrain checks, ect as well.

Thank you! How exactly would I go about doing this? Would the hitboxes just be an invisible sprite? If you know of any tutorials for this, could you please direct me to them? Thank you in advance.

Yes, it's just an invisible sprite, similar to how the base object is just an invisible rectangle

Yes, it's just an invisible sprite, similar to how the base object is just an invisible rectangle

So the logic would be something like...

"Every time frame x of attack animation plays, create a hitbox sprite at player base (x,x) offset when facing right or (x,x) offset when facing left. After frame x is over, destroy hitbox sprite.

On enemy collision with hitbox sprite, subtract x from enemy health and move x this way if facing right or x this way if facing left."

Does this sound about right?

That sounds about right, although I don't have a running example so best to just try it and see and modify and fix it as you go.

Here's an example of what hit/hurtboxes look like if you were to be able to see them. There is usually no need to follow the exact curvature of your blade. Games "feel" better if you cheat a little in favor of the player - make the hitbox extend past what the blade looks like a bit. You also won't need to create/reshape a unique hitbox zone for every single frame of your animation this way.

https://www.eventhubs.com/imagegallery/2016/mar/13/sf5-hit-and-hurt-boxes/14/

The boxes do not always exist, and usually last for more than one frame. So they would be created when the triggering frame starts, and destroyed when the "active" portion of attack animation ends.

Edit: More reading if you're interested game.capcom.com/cfn/sfv/column/131422

https://www.reddit.com/r/Fighters/comments/by2hzu/question_fighting_games_where_hitboxhurtbox_is/

Thank you!

To follow up, do you think it would make the most sense to create the hitbox in the same sprite editor that I make everything else, or is there something within Construct that I can use to make polygonal/circular sprites that I can create quickly and give really cut-and-dried collision polygons?

Whatever fits your workflow most comfortably.

Personally I don't bother with "exact fit" hitboxes, so creating a rectangular box in Construct's editor is no problem for me. For that matter, I only ever have to make one since it's just a rectangle and I can shape and size it during runtime, and they all serve the same purpose.

If you want to paint exact hitboxes, it might be more comfortable to do so with your image editor of choice, with the ability to use layers, transparencies, brushes, and bulk export options. Again, I'd say that this isn't standard practice, and is probably going to cause more problems and headaches than it's worth...

Whatever fits your workflow most comfortably.

Personally I don't bother with "exact fit" hitboxes, so creating a rectangular box in Construct's editor is no problem for me. For that matter, I only ever have to make one since it's just a rectangle and I can shape and size it during runtime, and they all serve the same purpose.

If you want to paint exact hitboxes, it might be more comfortable to do so with your image editor of choice, with the ability to use layers, transparencies, brushes, and bulk export options. Again, I'd say that this isn't standard practice, and is probably going to cause more problems and headaches than it's worth...

Thanks for the heads up. I’d like to try to take your advice but I’m a bit stuck on how to resize the Hitbox sprite during runtime like you said you do. It got as far as getting the Hitbox to show up when you attack and destroy itself when the attack frame ends or when the animation is forcibly canceled (by being hurt or falling off a ledge while sliding forward during your attack). But that’s about as far as I got. I took a short video that shows what I’m currently looking at. Is it possible that you could tell me how you’re resizing recurring sprites during runtime? Thank you in advance for your consideration.

youtube.com/shorts/0BHunIUSrrw

(Also, I think YouTube age-restricted the video. I have no clue why it would do that but if that causes any trouble don’t hesitate to let me know.)

On the right frame, create hitbox, set position, set size, and optionally pin to character. Destroy it on the end frame.

dropbox.com/s/fnuh7n3cipkil6i/hitboxexample.c3p

On the right frame, create hitbox, set position, set size, and optionally pin to character. Destroy it on the end frame.

https://www.dropbox.com/s/fnuh7n3cipkil6i/hitboxexample.c3p?dl=0

Thank you so much! The example definitely helped a lot. The Hitbox shows up just how I want it, so now all I have to do is make an enemy hurt function that activates when an enemy collided with the Ground Attack Hitbox, make functions and hitboxes for aerial attacks, and then rinse and repeat for the other three knights.

Video of working hitbox: youtube.com/shorts/58pupev4Kww

If you're setting up a function (decidedly a good idea) for creating hitboxes, you'll probably be able to use a single hitbox object and function for everything, including ground attack, air attack, and for every different characters and all kinds of attacks. This would simplify your events for what happens when an enemy overlaps a hitbox as well.

You'll want a createHitbox function that you can enter the parameters X Offset, Y Offset, X Size, and Y Size (possibly add damage, knockback, and other potential values as parameters and hitbox instance variables). You'll even be able to run this multiple times to create hitboxes of varying shapes and sizes that don't have to be perfect rectangles and can have different properties, like the tip of a spear doing more damage than the shaft.

If you're setting up a function (decidedly a good idea) for creating hitboxes, you'll probably be able to use a single hitbox object and function for everything, including ground attack, air attack, and for every different characters and all kinds of attacks. This would simplify your events for what happens when an enemy overlaps a hitbox as well.

You'll want a createHitbox function that you can enter the parameters X Offset, Y Offset, X Size, and Y Size (possibly add damage, knockback, and other potential values as parameters and hitbox instance variables). You'll even be able to run this multiple times to create hitboxes of varying shapes and sizes that don't have to be perfect rectangles and can have different properties, like the tip of a spear doing more damage than the shaft.

I’m actually really glad you brought this up. I want to keep the “base moveset” for all for players identical, simple single-hit attacks. But, I do like the idea of eventually giving players “toys” to play with in the form of single-use power-ups that can score big damage, deal damage over a large area, and/or provide some kind of extra movement or stat boost, but that would be a little later down the line.

With all that being said, it sounds like I ought to make that future plan easier for myself by seeing if I can get what you’re talking about to work with the basic ground attack ASAP so I can do the same thing with anything more complex down the line.

But I’ve got a couple questions.

- If I’ve got an attack that puts out multiple hitboxes, I’d probably need something that would prevent an enemy getting hit multiple times if it’s meant to be a single-hit attack. I have no clue how I would go about this. Do you have any ideas?

- Say if player one and player two swing a ground attack at slightly different times. Player 1’s attack ends first and the function that called for the Hitbox to be created calls for the Hitbox to be destroyed. Would this not prematurely destroy Player 2’s Hitbox? I’m also not sure how I could prevent this. Do you have any ideas?

- When you say the hitboxes don’t have to be perfect rectangles, are you saying I can make an irregularly shaped area by overlapping multiple rectangles, or are you saying there’s some way to turn an instance of the universal hitbox sprite into a circle or oval during runtime?

> - If I’ve got an attack that puts out multiple hitboxes, I’d probably need something that would prevent an enemy getting hit multiple times if it’s meant to be a single-hit attack. I have no clue how I would go about this. Do you have any ideas?

I didn't think about this much, but here's what I would try.

You could use a simple flag on the receiving object, isHit, true or false. When you check overlap with hitbox, this must be false, and it would be set to true so that following hit events no longer run until you set isHit to false again. Could be until the end of a tick, could be longer. Also can be used for invincibility frames, although I think the traditional way to do that would just be to remove the hurtbox entirely. Edit: Pick nth instance is probably the way to go.

For the overlap check, you could also add a pick Nth instance (first). If there is just one overlapping, no problem. If there are multiple, it would only run on the first one. You'd have to work out some sort of priority system if there are hits of different types/damages that could trigger together.

Otherwise just sticking with single hitboxes is perfectly valid too.

I haven't tried this and there are probably kinks to work out, but I'm sure it can be done.

> - Say if player one and player two swing a ground attack at slightly different times. Player 1’s attack ends first and the function that called for the Hitbox to be created calls for the Hitbox to be destroyed. Would this not prematurely destroy Player 2’s Hitbox? I’m also not sure how I could prevent this. Do you have any ideas?

You would associate each hitbox with it's owner sprite. Most straightforward way is by instance variable. Upon creating a hitbox for a player, set the hitbox instance variable "source" to player.uid. You can then pick by this "source" instance variable, if you only wanted to remove boxes for a certain player.

I think you can do something with hierarchies as well? I haven't explored that at all.

> - When you say the hitboxes don’t have to be perfect rectangles, are you saying I can make an irregularly shaped area by overlapping multiple rectangles, or are you saying there’s some way to turn an instance of the universal hitbox sprite into a circle or oval during runtime?

I was thinking irregularly shaped area with overlapping rectangles. But that was just an idea since you seemed interested in more accurate hitboxes.

There's also nothing keeping you from having both a circle/oval hitbox along with your rectangle hitbox, besides a little more complexity. You could also make it the same way with a function and resize as needed. Those two basic shapes should get you quite far with possible shapes with minimal effort, especially compared with having to make a unique collision bounds for every frame of every animation you plan to have in the game.

You can put the two shape hitbox objects either as different animation frames of the same object (which means you add one more parameter to your function to pick which kind to make/animation frame to set), or you can use two separate objects and put them in a family to treat them the same.

Thanks for all the help! I think I got the ground attack and enemy damage/death to be fully functional. I used the same logic that I used to make enemies receive damage to redo and streamline the logic I used to make the player receive damage from different enemy types: youtu.be/q1FWmKGSKTU

In the process of streamlining, I turned the Platform behavior for enemies into a family behavior, and added and tested some instance variables I plan to use in the future, namely YKnockback and TakeKnockback (boolean that determines whether the enemy takes knockback to begin with). These weren't made at the time of recording the short video.

As for how to separate Hitboxes based on which player they belong to, I could definitely do that. Another thing I was considering was just making "Red Hitbox", "Blue Hitbox", etc. which might make it easier for me from a purely visual looking-at-my-own-code perspective, but I'll see when I get there.

And as for making moves with multiple, possibly overlapping Hitboxes, I think I understand how to use nth instance, but if I don't it'll be something I can look at separately later down the line, especially because I'm not sure if I'll end up using it.

Again, thank you so much for your help!