Sprite covering multiple instances

For questions about using Classic.

Post » Fri Jan 30, 2009 9:15 pm

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?
B
2
G
3
Posts: 71
Reputation: 992

Post » Fri Jan 30, 2009 9:27 pm

Put enemy and hitbox in a container. So each instance will have its own rectangle.
B
21
S
6
G
10
Posts: 1,024
Reputation: 7,445

Post » Sun Feb 01, 2009 9:56 pm

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?
B
2
G
3
Posts: 71
Reputation: 992

Post » Mon Feb 02, 2009 5:38 am

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:

[code:nvjjv8wq]
+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.
Moderator
B
5
S
2
G
6
Posts: 4,348
Reputation: 10,971

Post » Mon Feb 02, 2009 4:39 pm

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.
B
2
G
3
Posts: 71
Reputation: 992

Post » Tue Feb 03, 2009 4:09 pm

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.
B
2
G
3
Posts: 71
Reputation: 992

Post » Tue Feb 03, 2009 5:00 pm

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.
B
2
S
2
G
3
Posts: 105
Reputation: 1,510

Post » Tue Feb 03, 2009 6:47 pm

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.
B
62
S
21
G
12
Posts: 1,910
Reputation: 13,155

Post » Tue Feb 03, 2009 7:16 pm

[quote="Mipey":scp0n7hp]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.[/quote:scp0n7hp]

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" :P

[quote="GMG":scp0n7hp]This invisible hitbox and visible sprite method just seems like a hack.[/quote:scp0n7hp]

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.
Moderator
B
5
S
2
G
6
Posts: 4,348
Reputation: 10,971

Post » Tue Feb 03, 2009 7:56 pm

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.
B
2
G
3
Posts: 71
Reputation: 992

Next

Return to Help & Support using Construct Classic

Who is online

Users browsing this forum: No registered users and 5 guests