Construct 3 suggestions & ideas

Suggest and vote on ideas for Construct 3! Please note this is only one aspect of planning. We do not guarantee any features here will be implemented, even if they are top-voted ideas. The aim is just to collect feedback. Remember to search for existing submissions before adding an idea, describe your ideas as comprehensively as possible, and vote for plausible ideas that are well thought out. Please see our full guidelines on suggesting features.

18 VOTE

Allow multiple collision polys per object (like image points).

Construct is long overdue for allowing objects multiple collision polys. They are needed to interact with different objects in different ways (i.e. Rectangle for environment collisions, Sprite Mask for general object detection, Freeform Shapes for melee weapons or attacks in fighting games, etc.)

Currently our only option is to use separate objects as collision masks, but this is just a workaround that originated in Multimedia Fusion over a decade ago and is far from ideal. With this method comes a slew of issues with overhead, object selection, multiple instances, and even using behaviors and variables and families just for collision masks which really gets messy.

 I don't feel that this feature would involve significant architectural changes or break any existing projects either. Polys would be managed just like image points, and when creating an "On Collision" or "Is Overlapping" condition you would choose the collision poly of the sprites as well.

  • Matt Gruber
  • May 12 2018
  • No status
  • May 14, 2018

    Admin Response

    It's not clear how this would actually work at runtime. For example, if a Platform behavior lands on a solid with 2 collision polys, which should it collide with? It makes this basic function ambiguous. A similar problem occurs with the "on collision" and "is overlapping" conditions: at a minimum, these need to have a defined way of working with multiple collision polys for backwards compatibility reasons. This extends to many less obvious features using collision detection like "on clicked sprite", "on tap gesture on sprite", which poly to use for Physics, per-tile collision masks for tilemap, etc. Using multiple objects actually solves this pretty well, since you choose which object to apply 'solid' to, or which to select for the "on collision" condition, etc. This suggestion ought to include a proposed way to resolve these ambiguities in an intuitive way that doesn't overly complicate things for beginners.

  • Attach files
  • Guest commented
    May 12, 2018 21:33

    Having a limited number of votes sucks. I can't vote, but I endorse this.

  • Mateus Sales commented
    May 14, 2018 13:20

    Sounds like a really nice addition and i don't see why it would "break" anything that's already implemented. +1

  • Matt Gruber commented
    May 14, 2018 21:09

    Objects would just need a "default collision poly" like sprites do with animations. It would be the first existing poly by default, but could be changed in the layout editor and possibly with events, too.

  • Matt Gruber commented
    May 14, 2018 21:12

    And, obviously, existing "On Collision" and "Is Overlapping" events would pick the default / first available poly since it was the only one available before this feature existed.

  • Admin
    Ashley Gullen commented
    May 14, 2018 21:15

    So does the feature extend to physics/mouse/touch/tilemap etc. or are you essentially describing a feature for the "on collision"/"is overlapping" conditions and everything else just uses the "default colliison poly"?

  • Mateus Sales commented
    May 14, 2018 21:25

    Well, i don't think that it's a good idea to choose which collision poly you want when you use something like "on collision" or "is overlapping". I guess the best option would be to treat collision polys like animations, which is a property of the object it self. For example, you would have a default collision poly and you can switch to other collision polys during runtime and all objects would react to the currently selected collision poly. You would be able to select a default one in the editor and switch betwen then with events.

    Anyway, it's just a suggestion, i know that Ashley will make the best decision about it, even if it means to not implement this feature. ^^

    BTW, sorry if i said something wrong, i didnt even used Google Translator. :p

  • Matt Gruber commented
    May 14, 2018 21:38

    It'll primarily be used for on collision / is overlapping events and everything else just uses the default collision poly, yes.

     

    For example, a sprite with the platform behavior and a solid tilemap will work exactly as they do now. The sprite's collision poly (which is now just the 1st / default poly in existing projects) is what interacts with the tilemap. However, the sprite will now be capable of having other polys to use for interaction with enemies, wielding melee weapons, and so on without relying on separate objects.

     

    I would think Mouse/Touch/Physics will just interact with the default collision polys as well, but they can use other polys in collision/overlap events. Alternatively, a new dialog will ask which poly you want to interact with (Mouse Clicked on Object, Collision Poly (2))...but that's getting a little more advanced.

     

    Probably not the best time to get into it, but there are other suggestions for allowing Unity-style composite objects that would make things like this far easier and more versatile. If Construct requires us to use separate objects like this, I would expect a more sophisticated way to tie them all together. Containers are a start but don't quite cut it.

     

  • Admin
    Ashley Gullen commented
    May 15, 2018 09:10

    I don't know if you've noticed, but to help implement collisions efficiently, there's also a limitation that the collision poly must be within the bounds of the image. Do you think this will be a significant limitation or do you think it won't generally be a problem? Using separate objects allows you to position extra collision tests anywhere which basically works around that limitation. Additionally if users end up increasing the image size and padding it with transparency to make more room for additional collision polys, that would start to waste image memory.

  • Stefan Rumen commented
    May 18, 2018 18:29

    This might be my biggest problem with Construct. Collisions are such a big part of almost every type of game, but in Construct you have to do a lot extra stuff to get things working well. So I gave my 3 votes immediately when I saw this.

    Example of its use

    I made a mockup to show off how necessary this can be for even the simplest game. Below you see a Koopa enemy from Mario.

    Here's how these collision polygons are used:

    • Purple: this polygon is used to prevent the enemy from clipping into walls, the floor, etc. You could also use it for collisions that hurt the enemy. So if the player jumps on top of him or shoots a fireball at him, you want the player to have a big target.
    • Red: this polygon is used for collisions with the player that will hurt the player. To give players a bit more leeway, many games make such a collider smaller than the actual pixel size of the sprite.
    • Cyan: this polygon is used as a sensor. If this enemy is walking on a platform, you don't want him to fall off. Using this sensor polygon you can sense when there is no platform beneath it and have the enemy turn around.

     

    I noticed the Admin Response that added some questions on how to implement this. I don't know if any of you have used Stencyl, another game creation kit, but it did collision very well. In Stencyl you can implement my example from above in about a minute. Construct takes a lot longer in comparison.

    So how does Stencyl go about it?

    1. Each colllision polygon is part of a collision group. There are a few default ones, but you can make more if you need them.
    2. You can set up which collision groups collide with eachother
    3. Sprite animations can have multiple polygons
    4. Each polygon in an animation can have a different collision group

    You can read more about it here. I also recommend downloading Stencyl and trying out the system for yourself.

    http://www.stencyl.com/help/view/collisions-and-groups/

    How could it be implemented in Construct?

    A collision group system might not be too far from how Construct things now. If you consider the collision group system of Stencyl as a layer system, but for collisions, then you can imagine Construct as already having a collision group system. Only thing is, at the moment all objects are part of two groups: collision and no collision.

    You make this a true collision group system you would have to add more layers, but from the outside it looks like it could be added onto the program without breaking anything. Older games would simply have only the two collision groups in use. The work arounds they use to fake collision groups would still work. New games could then make full use of the collision group system to help simplify and speed up development.

    Reply to Ashley's comment

    "I don't know if you've noticed, but to help implement collisions efficiently, there's also a limitation that the collision poly must be within the bounds of the image. "

    In my proposed system 90% of collision polys could be done within the same object. If you wanted collision polys that acted as sensors (see cyan in mockup), then you'd need only a little bit of extra transparent areas around the sprites. The 10% that would need a bigger area of transparency could still be done the old fashioned way, with separate collision objects linked to the parent object.

    Conclusion

    Multiple collision polys per object don't have to be possible. By using collision groups, sort of a layer system for collisions, you can implement multiple polys in a way that is clear to both C3 devs (I think) and C3 users. It should also be possible to implement this system while keeping old games/workflows working as before.

    I hope I helped a bit with making this feature suggestion a bit  more detailed. If you need more info or more feedback on this issue, I'm your man.