Sprite covering multiple instances

So, I've just discovered why the platformer tutorial states it's best to have an invisible rectangle be the "real" player / enemy / whatever, with the graphics on top of that. And the implementation for the player works very well.

But how do you do it for enemies that have multiple instances in a level?

Put enemy and hitbox in a container. So each instance will have its own rectangle.

I'm trying this out, and finding it quite complex. I can see how it'll be useful once I get an understanding for it.

I have a rectangle hitbox and a graphical sprite for each enemy type I want. Is there a generic way to make sure each graphic sprite stays on top of its hitbox? The hitboxes are all part of a family, so I can easily reference all of them at once, but how to make them reference their graphics?

No, no... not a Family. As PR said above, you need a Container. <- link to wiki page

When objects are in a Container with each other, then picking one of the objects in the Container will pick all the instances of the other objects contained with it. Then you can do this:

+For each Sprite
  ->Sprite: Set position to Hitbox
[/code:nvjjv8wq]

Then each sprite will automatically line up with the hitbox that is in it's container.

What I'm saying is... do I have to do that for every Hitbox / Graphic combo I have, or is there a generic way I can do it with families? If I have 20 different types of enemies, each with a separate hitbox / graphic, do I need 20 different sets of events to keep the graphic and hitbox together, or is there just one I can use since they're familied together?

If it's the latter, it's going to be a pain when it comes to things like setting attacks and such. Before I was doing this method, I'd just make sure that all my enemies had animations named the same thing, and then I'd set the animation depending on the state, cycling through all the enemies via family. But separating the hitbox and the graphic would mean that each enemy would need a completely separate state machine, even if the behavior is the same as another enemy.

I'm bumping this because my project is basically on hold until I can figure it out. Please allow me to explain my question more expressly.

Before using containers, I had a bunch of sprites in a family with all the animations given to them, and the platform behavior assigned. When I wanted to have the monster do something, I'd have an event that said something like:

+Family member meets condition

-Set family member speed, position, whatever

-Set family member animation

Now, with containers, I have a problem. The hitbox is the family, and the animation is in a container. My event would look like:

+Family member meets condition

-Set family member speed, position, whatever

-HOW DO I SET THE ANIMATION FOR THE OTHER OBJECT IN THE CONTAINER?

It's a referencing question. Each animation sprite, though contained with the hitbox, has a different name. It's not enough to know that if I named the animation sprite, it would go with the hitbox in cases of cloning and spawning and such.

Things like this would be much simpler if Construct allowed you to define custom bounding boxes for sprites, relative to the hotspot. Then there wouldn't be any need for linking animated sprites to hidden interactive hitbox objects.

In GameMaker, with sprites you can define precise collision detection (pixel perfect), custom bounding boxes, or you can even make a mask sprite that can be explicitly linked to the object for collision detection. It's a lot more flexible and robust in that regard. This invisible hitbox and visible sprite method just seems like a hack.

If hitbox is in family and is contained with sprite, then the contained sprite will be picked whenever the hitbox is picked. Or so it works in theory.

Also, there is this new Pairer object.

If hitbox is in family and is contained with sprite, then the contained sprite will be picked whenever the hitbox is picked. Or so it works in theory.

According to my own experiments, not quite...

If you have two (or more) objects in a container, then you have to refer to one of the objects in that container directly in order to pick the others. Since you can't put a Family into the container, you might get weird results.

So you can do a lot of general stuff to your hitboxes by Family, such as setting the speed, angle, test collisions, or whatever... but if you want the Container picking ability you will need to define your condition by using an actual object that is in the container, and not by a Family that any of those objects might belong to.

Hope that makes sense. And of course, now that the subject has been broached I'm sure some dev will pop in and say "Fixed for next build"

This invisible hitbox and visible sprite method just seems like a hack.

I suppose I'm just used to it. I came to Construct through MMF, where it's common practice to do it that way.

At any rate, I read somewhere on the forum recently where one of the developers said they were planning a custom hitbox feature. So who knows, it might be here soon.

And honestly I don't think it's that hacky of a practice. While Game Maker allows you to manipulate the hitbox directly for the sprite, it's really just a matter of convenience (I'm not aware of any other game making software that has that feature). Defining the hitbox with a separate sprite in Construct is the same sort of practice... and has the same reasoning behind it. It's just that it's not as convenient because it happens to be a separate object. In traditional programming it's even more abstracted... you have to define your collision box based on math rather than a visual representation of a box. But essentially you're still making a box, even if that box is made of a few individual coordinate checks.

Hm. Perhaps the object pairer might work? I'd have to link them individually, perhaps for each spawn, but after that it might work. When I get back on my construct computer later tonight I'll try it out, based on the example in the upload forum.

And honestly I don't think it's that hacky of a practice

Hack or not, you can't deny that setting up events and actions for games would be a heck of a lot easier if you had only one sprite to deal with per distinct in-game object. As it stands right now, you need two sprites for each object, with events and actions distributed between them.

I just feel it would be great if you could say "the bounding box for this sprite is W*H pixels in size, offset from the hotspot by XY pixels". Or better yet, the way there are several animations per sprite, it could be possible to have a special image called collision mask, which would override the pixel collisions of the animation frames.

Anyway, I didn't mean to hijack the thread. I'm going to open up a topic on this in the feature requests forum to continue discussing this.

We're going to have a custom collision mask feature for 1.0. This'll be in the Picture Editor, and you can draw it out.

Would it be possible to specify multiple types of collision boxes? Street Fighter, for instance, has boxes to determine where you can hit others, and boxes to determine where you can BE hit.

Would it be possible to specify multiple types of collision boxes? Street Fighter, for instance, has boxes to determine where you can hit others, and boxes to determine where you can BE hit.

You could probably just place all of your hitboxes inside a container with the sprite then have them attached to image points on it. Although multiple collision masks could be a handy feature that I don't think any other program has.