Drag-and-drop-and-snap

Firstly sorry for the bad diagram but I think it shows what I need.

In words, I have certain shapes (not those shown) that can be drag around the layout. When dropped near to another shape, the dropped one should move to, align with (i.e. rotate), and 'snap' to, the shape nearest to where it was dropped. The shapes can only fit to each other in certain way (e.g. along specific edges).

(I also need the shapes to be dragged off again (un-snapped) and to allow the connected shapes to be dragged as one, but the above is the main thing)

I'm still deciding whether to have each shape as an animation frame of the one Sprite, or to have different Sprites for each shape.

I have looked through the FAQ and forums. Some ideas come close, like magnetism effects, etc. I'm running with a couple of ideas involving lots of Pin-ing, but I'm sure there are elegant solutions that I'd not consider.

Thanks!

I would take a look at the puzzle demo that comes with C2.

Hey TheDom thanks for the response. You mean Physics Puzzle? hmm not sure how that fits but perhaps I'm missing something. Could you be more specific? My needs are more like a tangram puzzle where the pieces must 'know' how they are allowed to fit together, and automatically move to the nearest piece and snap onto it.

I'm also not using physics, although there might be a clever way to leverage physics to do this. I just thought it was overkill. And also it's important my pieces snap together fairly accurately.

I've just looked at the jigsaw tutorial, but those pieces are arranged on a grid. Mine are arbitrarily placed.

My idea would be to first have a sprite pinned to the center of snap-able each edge center of each shape. Let's call them "edge".

Then when a shape is dropped pick the closest other edge that's closest to each of the shapes edges. Of the two pairs of edges only keep the closest. A little tedious to make events for but that would give you the two edges that would need to snap together.

The snapping could be done by moving the dropped shape by the offset of the edges and orienting them based on the normals of the edges.

I'm attempting to come up with an elegant event setup, so stand by for a capx.

My idea would be to first have a sprite pinned to the center of snap-able each edge center of each shape. Let's call them "edge".

Then when a shape is dropped pick the closest other edge that's closest to each of the shapes edges. Of the two pairs of edges only keep the closest. A little tedious to make events for but that would give you the two edges that would need to snap together.

The snapping could be done by moving the dropped shape by the offset of the edges and orienting them based on the normals of the edges.

I'm attempting to come up with an elegant event setup, so stand by for a capx.

Yep exactly what I'm attempting Currently I find the nearest 'shape sprite' to the dropped one, then decide which 2 'edge sprites' from each shape sprite are closest, then do a move-to to bring them together (the shape is pinned to the edge sprite so it moves too). Now I just need to get the angle of the objects right. Thanks so much for your time and I'll be happy to look at any ideas/refinements you have!

codah

The math for the angle was simpler than I thought, but I was messing around with it blind for a bit.

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

codah

The math for the angle was simpler than I thought, but I was messing around with it blind for a bit.

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

Thanks R0J0hound, I'm going to see how I can incorporate this into my code. I'm sure this will be very useful to others as well <img src="{SMILIES_PATH}/icon_e_smile.gif" alt=":)" title="Smile"> Cheers.

Line11 is a great trick! Never thought of it!

It's a nice learning material, thanks R0J0hound !

Line11 is a great trick! Never thought of it!

It's a nice learning material, thanks R0J0hound !

Question is, what would you do a few versions back when Wait for signal didn't exist? Wait 0 doesn't do it, even though I thought it's supposed to delay the following actions to the next tick. Wait 0.05 seems to do it. TBH 'tricks' like these concern me.

Question is, what would you do a few versions back when Wait for signal didn't exist?

I did a lot of trial and error and eventually put the mechanism on halt, since I have abruptly failed to get it right. Part of the reason I "swim" a lot in forum is to look for sparks of idea to solve my own problem, one thing led to another .

I attempt something very similar back then, which is a RPG drag-drop equipping, which recycle sprites for left and right side, the mechanism is crazily similar that I'm eager to revisit the project. Btw, it's a robo-rpg with extendable appendages.

The event 11 trick was so the pinned connector sprite's positions would be updated before moving.

The reason for this is the game flow is like the following and we have to wait for the next frame for pin to run again.

behaviors -> event sheet -> draw -> repeat.

Wait 0 or with a very low time can be ready by the end of the event sheet, so wait with a higher value or "wait signal" worked. Although I agree it's not a very clean solution.

The clean solution would be to do pin in events so I can update the pinned objects whenever I need.

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

But sometimes it's easier to just make do with exiting behaviors.

Thanks very much. I've adapted your design to my objects (well 1 so far) but the normal calculation will need to be hard coded for each object? As I have a number of objects. Did you just choose the angle (x1, y1, x2, t2) values by any special technique?

The normal is just the angle perpendicular to the edge facing out. For instance the slope (rise/run or change in y divided by the change in x) or the right edge is 2/1 and the norm slope is 1/-2. The calculation of angle from slope is angle(0,0,run,rise). Another way is to guess the angles, test and re adjust

R0J0hound at rescue again I was looking for something like this thanks R0J0hound

R0J0hound I see a new behaviour in your future... align-and-snap. With an automatic normal generator based on polygon edge