[Suggestion]Different Collision Polygon types (HITBOXES)

Having Different types of collision polygon types I believe this open up construct 2 to fighting games more so than other game engines. They would essentially be hit-boxes

i doubt that this would be possible to create from a plugin that isn't Spriter.

is it possible to have a useful tool like that in the image editing tool?

When it comes to fighting games and other smiilar attack frames. Most developers spawn the collision box on frame x, and destroy on frame y. Using image points in the frame and then setting angles seems to be a enough.

Though I agree it would be nice to have collision flags to determine how or what can collide with what or not collide with.

This is how Super Smash Bros. handles collisions/hitboxes/hurtboxes http://youtu.be/tonqj4rkjIU?t=1m17s

I can't imagine doing anything like that with the tools we have now. With Spriter, maybe, but not C2's standard toolset.

Multiple collision polys would be great for everything, not just fighting games. For example you can have a platformer where enemies have a simple box poly for good collisions with the environment, then a more elaborate one for interacting with your player and such. No code, extra objects, or containers required.

Multiple collision polys would be great for everything, not just fighting games. For example you can have a platformer where enemies have a simple box poly for good collisions with the environment, then a more elaborate one for interacting with your player and such. No code, extra objects, or containers required.

I've asked about that quite a long time ago. Here's the link to that question and Ashleys answer.

https://www.scirra.com/forum/what-next-for-construct-2_t62566?&hilit=polygon&start=40

shinkan Yeah I strongly disagree with Ashley on that one. For example, if you're using a separate object for an enemy's collisions, then you must code both objects to work in perfect harmony which can be a real pain at times, especially when dealing with multiple instances. Suddenly you end up having to do things like set & compare ID's or use containers, position the enemy to the collision object, give the collision object behaviors and variables instead of the enemy itself, make sure both exist or don't exist together, put them in separate families so one does this and the other does that. Then do you use one collision object for every enemy, or do you make a new one for each enemy? I mean they will have different behaviors and variables and properties so...

All of that can be avoided by simply giving the enemy an additional collision mask. One to handle collisions with the environment, and another to handle interaction with other objects.

[quote:trith7gu]Suddenly you end up having to do things like set & compare ID's or use containers, position the enemy to the collision object, give the collision object behaviors and variables instead of the enemy itself, make sure both exist or don't exist together, put them in separate families so one does this and the other does that. Then do you use one collision object for every enemy, or do you make a new one for each enemy? I mean they will have different behaviors and variables and properties so...

What I'm doing right now. Doable for sure, but a big hassle! Transferring instance variable values back and forth between objects, making sure the right object instance is referenced by comparing ID with the instance variable of a different object, keeping track of em all etc. Makes for convoluted, messy, and bug-prone code. At least in the hands of a programming-impaired person such as myself

So, +1 for this feature. It would be very useful to a lot of people I think.

Know what you mean, it could make things a lot easier and quicker. Having objects "flying around" other objects just to do some test collisions is a bit silly, especially if you need to test many different things with many different objects.

I'm all in for adding multiple collisions for objects.

Not just for fighting games. I have hitboxes for large spaceships that are a huge pain to program and would be very simple if you could have multiple collision boxes for a single sprite.

What would be really nice is scene graph heiarchy for objects.

In Unity 1 object can only have 1 collision box. So it's not unusual for 1;1 ration. it's nothing new. However many engines I have worked with use SceneGraphs and non scenegraph engines like C2 are fewer out those I used.

A scene graph uses a parent->child relations. This makes the XY, Size, angle all relative values compared to the parent. While PIN does this to a lesser extent. it's a far inferior to scengraph.

In Unity when we need multi sensor objects. We create the core object and then child objects with additional colliders. Because unity uses Scenegraph this is easy. If I flip/rotate(ie Mirror) the object and children are mirrored with the parent. This makes handling multi part objects super smiple.

Now I love C2 more than Unity. Much more, but I do disagree with a few design decisions. PIN is not a replatement to Scenegraph design. And scenegraph design would fix a lot of problems developers have with C2 and object structuring.

recently started using Unity for my Uni work and in some respects i miss some of the easier to do other things the using of parent->child relations are a damn goodsend - wouldn't spriter just become a substitute for that if you think about it?

Coming back to this, it's actually pretty easy to have multiple points on your object and then get the nearest one on a hit --so you really don't need multiple collision boxes.