[Feature request] Layout Collission Vector Maps

Hi everyone!

Construct is a great engine, no doubt about it. However, after I have been working with it for quite a while I have noticed that collision can be quite tedious in games embracing art styles similar to ubi-art games. I am currently working on a project like this. And even though Construct 2 is not as flexible in the creation of collision as Ubiart engine (https://youtu.be/XoLpPw864eA?t=143) I can actually convey a similar graphical feeling by adding, rotating, mirroring, resizing and overlapping a lot of 2D objects. However, these 2D-objects are only a graphical representation of the world and the built in "object vector maps" does not suffice for a bug-free experience. The issue I am having is that the location of the graphics is not always coherent where you want the collision to be positioned, resulting in a lot of bugs arising from collision overlapping, gaps etc. In order to get rid of this I have made dummy-"collission"-objects on a separate collision layer. then I can stretch rotate and position these to my specific needs, the backside is that I have invisible objects that still require to be drawn and it requires a lot of bug testing for collission overlapping and pixel / sub-pixel gaps between the objects. The solution with dummy objects is the one I am going for, but I wished there was a way that required less testing.

here is an examples of what a level would look like in the game editor (without lighting effects). I chose a pretty basic level to keep things simple, and I have zoomed out to 32% of the original size:

As we can see there's a ground that is rather flat, there are two slopes on higher grounds , a small cave on the left side

In order to deal with this I have to assign vector maps to both normal graphical objects (platforms, the slopes etc), as well as the my solid collision dummy objects, represented by black rectangles.

I know that I am probably creating something that Construct was never intended to do, however, I would love if you could actually draw a vector collision map (with nodes) directly on the layout. Resulting in less collision calculations, fever bugs and less gap and overlapping issues. I made a screenshot in order to represent how I would like it to work. Red colour is the "solid" behaviour and yellow is the "jump through" behavior):

A dream would be to create the ground with textures in a similar manner as in the ubiart video that I linked to, but I guess that will always just be a fantasy of mine.

You can do that with tilemaps.

Pretty neat idea but i think you can do someting very similar already.

* Remove collisions on all objects.

* Create 2 dummy objects one red for solid and 1 yellow for jump through, The dummy objects could be 5x5 px or whatever.

* Create 1 new layer on top. Place and stretch those red and yellow dummy objects where you want them.

* On start of Layout. Hide the dummy Layer.

Not as neat, but it could work.

Pretty neat idea but i think you can do someting very similar already.

* Remove collisions on all objects.

* Create 2 dummy objects one red for solid and 1 yellow for jump through, The dummy objects could be 5x5 px or whatever.

* Create 1 new layer on top. Place and stretch those red and yellow dummy objects where you want them.

* On start of Layout. Hide the dummy Layer.

Not as neat, but it could work.

That is actually what I am doing with the black boxes. (as well as yellow "jump through"-boxes, although they are not currently shown on the screenshot)... The whole idea is to remove the use of "dummy objects". Because it is an inflexible solution that requires a lot of time testing the collision positioning in order to rule out collission bugs from overlapping and pixel/subpixel gaps between the dummy objects. This solution would result in a gap- & overlapping-free situation with less calculations and less draw-calls. (even though a collision layer is invisible the objects will still be rendered, but with zero opacity)

You can do that with tilemaps.

I unfortunately cannot see the benefits of using tilemaps when you are striving for a flexible high resolution art-style. Still, from what I know, you can only assign collisions vectors on each individual tile, but not the layout as a whole.

You wouldn't draw the collisions, you would piece them together using different the different collisions.

Tile with left slope here, right slope there etc.

You could also assign the tiles at runtime.

This is a work around that is as close as possible to what you are asking.

Anyway you are asking for an in editor feature where the in editor features of C2 are pretty much locked.

Better luck with C3.

You wouldn't draw the collisions, you would piece them together using different the different collisions.

Tile with left slope here, right slope there etc.

You could also assign the tiles at runtime.

This is a work around that is as close as possible to what you are asking.

Anyway you are asking for an in editor feature where the in editor features of C2 are pretty much locked.

Better luck with C3.

Yeah I understand what you mean, but it doesn't seem as I would gain any efficiency by using tilemaps instead of dummy objects. The feature request however does not necessarily have to be developed for C2. It would make more sense to include something like that in C3, And I would buy C3 without hesitation on the day of its release.

Ashley, would a feature like this (or similar) be feasible for C2/C3?

C3 is an editor re-write and supposedly will make plugins able to have more deluxe editor capabilities. So if that's true even if this isn't officially added, a third party plugin could be made to do it.

A current idea you could use is to make an in game editor to add the collision maps. Here's a quick mock up:

https://dl.dropboxusercontent.com/u/542 ... ditor.capx

There's the initial work of creating the editor mode but afterwards it makes it much quicker than manually positioning lines like that with sprites. Not to mention that you can extend it in any way you need.

I made an all-event-based version of what you're getting at.

I'm actually surprised how easy that was to make (I thought it was going to be super-difficult).

Important notes:

-Numbering is zero-based.

-Object number, node number, and last node are all really important to get right. If you don't remember "last node," subsequent shapes won't draw.

-Steep jump-through objects don't seem to detect collision in the x direction.

boundingboxes.capx

(And Google Drive will show a bunch of files, but just click the download button at the top and it'll turn back into a .capx)

Eh, Steve!

Thank you so much R0J0hound for the input, and calebbennetts for the wonderful example you made. I haven't looked into it quite closley yet. But from what I can gather the method still result in collision bugs at certain angles where the player object can walk through a solid collission, The method unfortunately also adds a separate layer of 2D objects that impact rendering performance (not by much, but can still be crucial on scenarios with many layers and many overlapping objects. Which is of course, very typical of the game that I am creating)

If the layer is invisible it won't affect rendering performance at all.

Hi, g3nki!

I clicked on the link for Project Catnip, and it’s breathtaking! I thought it would be great to be a part of this in some small way (If I could be so bold), so I ran some tests.

As far as the jump-through problem, that happens when the player hits the edge of a link part-way up the player sprite or when the link is very steep (For a flat fall-through object, a platformer object won’t fall through for gravity angles between 40 and 140 degrees. I don’t know whether there’s a way to fix that.

Next, I tested solids. A 7x8 pixel rectangle traveling towards a surface at 1000 pixels per second, running at 60 fps, required a bar only 2 pixels thick to consistently sense collisions. However, when I positioned the bullet at a worst-case position, flush with the bar at the start of the first tick, the required thickness jumped up to 10 pixels for consistent collision! And with rectangles so wide, the corners could really get in the way of good collision.

Depending on how your game will work, especially in terms of objects’ movement speed and whether you can get a consistent framerate (How’d I get it in my head you were developing for the Wii U?), my events for solids still might work for you. But if you need high move speeds or the corners start giving you trouble, I guess codename: Bounding Box is scrap.