Multiple Collision Masks

Let's say you have a fighting game like Street Fighter (although this would help with TONS of things). You would need two hitboxes: 1 for the player who can get hit and 1 for whichever part of his body is attacking (to register hitting the opponent). Now, to get that accurate, you have to use an image point or create a sprite for each part of his body or an invisible collision sprite for each part of his body. All of these things feel like work-arounds to me.

I propose being able to create more than one collision mask for an object. Extra collision masks would help with melee attacks, complex hit boxes (eg. headshots, bodyshots, etc), or any time you'd want different parts of a sprite to do different things.

You could add a box/option for collision/overlapping events to edit which collision mask you want for "On Collision" and "Is Overlapping" in each case and things like the Platform Behavior could just use the main collision mask (or whichever one you set it to use if that option would be useful).

I don't have time at the moment to create some images and more examples to explain this better and show how useful it would be, but I think anyone could see how this would save a LOT of trouble/time/etc.

You could do all that with containers and briefly spawning invisible collision sprites and such.

You could do all that with ... spawning invisible collision sprites and such.

Hmmm......

[quote:1e6o0ltj]Now, to get that accurate, you have to use an image point or create a sprite for each part of his body or an invisible collision sprite for each part of his body. All of these things feel like work-arounds to me.

It's not really a workaround but yes I can see how juggling many collision boxes could be a lot of work.

Let's just look at the alternatives for a moment. If multiple collision masks were introduced as a feature, how would they be implemented? You would still have to draw the box, if not a full-on mask. You would have to make sure they were aligned properly on each frame somehow. If you look at the current state of sprite collision masks this can be a bit of a chore as it is! Let alone the fact that moving a sprite's mask away from the hotspot causes misaligned collisions.

But let's just say you could move a mask around wherever you wanted. You would have to go through frame by frame in your animation and line each mask up in it's proper spot. Either that or set hotspots and tell Construct to line them up at runtime. So... it's not going to really be a whole lot different to set up than the methods you would currently use, the only difference is that the hitboxes are built in to the sprite instead of being separate objects.

It seems to me like a feature that not very many people would be using all that often. Sure, some people would find it useful on occasion, but for the most part people really only need one hitbox for their sprites. I don't see that changing the fundamental way that sprites and other objects collide and coding in extra editors and whatnot into the IDE would be justified by just a few people needing it on rare occasions.

Of course, in this day and age of plentiful plugins, someone might be able to make a Hitbox Object that you can attach to another object, that manages however many collision boxes you need all in one package. I think that would probably be the best solution, if you can find someone to code such a plugin for you. Otherwise using invisible detectors isn't really a bad thing. It's something that's done a lot in gaming.

Use a single hitbox sprite with multiple animations (or frames). Make it the same size as your sprite, copy your sprite in, and draw over his fist or arm or whatever. Erase everything else and code it up so that when he punches it switches the animation or frame of his extra attack hitbox.

All of these things feel like work-arounds to me.

Actually, like deadeye mentioned, you're not saving much/any time with your way. Your just putting the hitbox work into the picture editor and behind the scenes of the IDE. This is worse than making a seperate sprite IMO. Fiddling with the picture editor to align frames and hitboxes is a pain as is (you can't see the hitbox during the runtime etc.), and then your stuck with a hitbox tied to your image. You won't be able to offset it for special attacks, or do other advanced things. Fighting games take a lot of work. What feels like a "work around" is actually the necessary, unavoidable work.

Fiddling with the picture editor to align frames and hitboxes is a pain as is (you can't see the hitbox during the runtime etc.)

Ah, another good point . Didn't even think of that.

I see what you mean. In that case, it would be nice to have a way to arrange objects in the list so I don't have to scroll through 100+ to find what I want. Folders would be nice. I just really don't like having lots of sprites because I can't keep track of them all in the objects list window.

There's a better object list in the project bar, and in that one you can have folders.

You can use different animation frames to check for collisions without showing them by switching frame, check for collision, and switch back before the tick is over. It was a trick used in mmf (when overlaps at an offset wasn't available) and there's an article about it somewhere on TDC. I don't know if it's needed in construct or if it's allready been mentioned.. but back then it was really impressive to do a custom movement without a detector on each side of the guy.

There's a better object list in the project bar, and in that one you can have folders..

Right, but you can't drag stuff out of it onto the layout, or copy from it . At least, not yet.

> There's a better object list in the project bar, and in that one you can have folders..

>

Right, but you can't drag stuff out of it onto the layout, or copy from it . At least, not yet.

With folders in the object list too you could hide (read: not show in the list) whatever part of the layout you weren't working on (eg. wanting to mess with terrain instead of particle effects).

I had an idea for construct 2 that sort of covers this. Multiple layered object. So you could do all your detectors on one object, or have, for example, armor that breaks off, or do fighting game style hitboxes. It'd be more flexible and obviously useful than just multiple collision masks.

What I do right now (as a practical, but annoying solution) is have an object. I copy the animation I want to add hitboxes to and paste it on this object. I think Go over the sprite with boxes and trim out what doesn't fit right. Then I set animation speed to 0, and give it the same animation name.

Then every frame it's position is set to that of the player, it's animation is set to that of the player and it's frame of animation is changed to that of the player.

Then you modify the original animation and do this ALL OVER AGAIN, but hey, what can you do?

You COULD store all attack data in a 3d array and then make a mini app for creating hitbox data. Then they're made each frame! But thats a lot of work! But thats also the 'pro' way to do anything fighting game related.

What I do right now (as a practical, but annoying solution) is have an object. I copy the animation I want to add hitboxes to and paste it on this object. I think Go over the sprite with boxes and trim out what doesn't fit right. Then I set animation speed to 0, and give it the same animation name.

Then every frame it's position is set to that of the player, it's animation is set to that of the player and it's frame of animation is changed to that of the player.

Then you modify the original animation and do this ALL OVER AGAIN, but hey, what can you do?

I'm not sure I follow you. Why modify the original animation?

I was thinking you'd just do this: Take your sprite animation that you want the hitbox for and copy it to another object. Trim down whatever you don't want to be part of that hitbox (or change it completely for whatever shape you want) and color the hitbox sprite a different color or outline it or something. Of course you'd cut the image down smaller to only where the hitbox is because empty canvas area still takes processing power. Create an image point on the original sprite animation for the hitbox sprite to glue itself to when it is needed. Only spawn the hitbox sprite when you need it then destroy it when the animation is finished (if it isn't supposed to be there always). Also, for example, if you have two kicking attacks, you can still just use one hitbox sprite with two animations if you don't like using lots of sprites. Depending on what you were doing, using one sprite for two attacks would not work well enough, but in that case you might want seperate sprites anyway.