[Request] Multiple collision boxes

I know it wouldn't be easy but there is great value in this for touch games.

When we put a collision box on a sprite, we typically make it as tight as possible so that when the sprite collides with other sprites it looks good (no massive gaps between the collided objects).

But with touch we want the opposite, we need exaggerated collision box to more easily pick up a touch otherwise the game isn't very playable.

So would it be possible to have more than one collision box?

Then instead of :

"on sprite touched/overlapped"

etc, we could check

"on sprite.collider("box1") overlapped"

"on sprite.collider("box2") touched"

And also

"on sprite touched/overlapped" would now mean any of the sprite's defined collision boxes.

I've used touch as an obvious reason why you'd want this but I imagine there could be many more. And lots of cool stuff to be gained from allowing it.

It would be easier to pin multiple collision boxes to an object and detect any collision with them ...

I wouldn't say easier, because you have extra objects to manage which causes more work when destroying etc.

Regardless for now I will give that a try, thanks. :)

If your object doesn't have an animation, you can add an animation frame with a larger collision box which you switch to in code only when you are checking for touch, then switch back before any other collision checks are made.

If your object does have an animation, then it's probably a better idea to pin a collision to it as Whiteclaws suggested.

Yeah objects are animated.

I'm experimenting with pin right now. As expected, works like a charm for detecting touch, but due to the lack of reverse lookup (i.e. My hitzone can get pinnedUID, but the object I'm destroying can't see what is pinned to it) then there's no elegant way to remove the "hit zones".

So, I have two ways an enemy can de-spawn and in both cases I would need to identify and remove their pinned hit areas - can't see a tidy way to do it.

Right so yeah, I can get it to work like this but it's finicky so I'll leave my request here as a "nice to have".

Use separate pinned collision sprites and put them in a container. That will automatically handle creating, destroying, and picking the associated object. I don't think we should add multiple collision masks to the editor, because this is a good solution with containers, and it becomes confusing if you have separate collision masks (which one should behaviors collide with?).

—

Unless you can set me straight here..

The problem with containers, and the prime reason I still haven't found a use for them, is that they can only be bound to one sprite, AND they can't be bound to a family.

So I've got 50 different enemies, I'd have to create 50 unique collider objects and associate each.

That's a bit of a design time nightmare and also uses way more memory than needed, so for now I'm going with what Whiteclaws suggested. Creating and pinning a "larger" collider sprite to a created family enemy at runtime.

Then when the fade of my enemy completes I loop around all colliders, match faded Enemy UID to ParentID (instance variable I manage), and destroy the collider.

If you have a more elegant approach using containers and I'm being silly and missing something, let me know!

As for my request..

I think if you had many masks you'd be able to check for collision to "any" mask which would be the default and look the same as the events look today.

I think you'd additionally be able to check collision against a specific mask per sprite (just like you can reference the sprite's various animations by animation name).

You don't have to use the built in drag and drop behavior, you can make your own.

In fact you can dummy it down a bit to fit what you need.

+on touch

+for each object

+distance(object.x,object.y,touch.x,touch.y) < n

+object pick closest to touch.x, touch.y, object set variable selected to 1

+touch is in touch

+object variable selected = 1, object set position to touch.x, touch.y

+ on touch end, set object variable to 0

Might not even need the for each since pick closest is in play.