Sliding puzzle game - blocks sometimes not sliding/getting stuck, edge detection issue?

Unity Engine
1

(I think I should first mention I believe I found an okay workaround for this issue using an edge radius for the boxCollider2D and making the bc2D slightly smaller to provide enough room for contact generation, but I’m trying to get a deeper understanding of what’s going on with the following issue.)

I’m playing around with a sliding puzzle game where the mouse delta can move the puzzle pieces (bc2Ds with slipperiest material possible and no edge radius, dynamic rb2ds w/ no gravity) in the four directions if space is available. (Only one total blocks worth of space is “free”.) If the puzzle piece is close enough to a grid piece, it snaps to the grid piece (transform/center), which should give just the right amount of separation for the next piece to move since the grid pieces are the same size as the puzzle pieces.

The problem: being able to slide/drag a puzzle piece is inconsistent, despite being placed perfectly aligned to each other/instantiated right up against one another. Sometimes a piece will move fine, other times (often moving horizontally), they seem to detect a tiny fraction of the bc2D above or below of the grid space they’re trying to move into.

I’m also curious how Default Contact Offset comes into play; I have it set to 0.01 which seems sufficient for what I’m doing. If I have that at 0.01, does that mean I want my bc2Ds to be shrunk by 0.01 on each side? (like if the bc2D Size is 3,2 in game units, should the size actually be 2.98 and 1.98?)

Gif showing movement with bc2Ds size at (2.99,1.99)

Gif showing movement with bc2Ds size at (2.98, 1.98)

Main question: Is there a way to assure consistent sliding movement with the right amount of spacing, and without resorting to using the edge collider or allowing for “wiggle room”, or is that essentially not possible (perhaps without having a deep understanding of physics and physics engine “under the hood”, or using kinematic movement instead)? If it is possible, how can I calculate the precise right amount of space? (bc2D size with room for the Default Contact Offset)

Movement script (I’m not sure it’s all that relevant here)

I’m open to the idea that what I want to do with dynamic rb2ds may not be possible without making changes similar to what I mentioned in the first paragraph (or working out a grid movement system, perhaps trying kinematic collision), but I’m curious about this.

The issue does remind me of 2D platformer player controller edge detection issues, which recommend using a capsule collider to avoid getting stuck on slight changes in “ground” colliders and co.

Thanks for any help.

2

Was there something wrong with my question? I understand that most people are busy with their own stuff, but was hoping somebody could respond.

3

With no insult intended, my honest answer here would be; why would you even want to use rigidbody physics on such a simple puzzle slider mechanic? You have to know that what you’re doing here is nothing to do with rigidbody dynamics so the fit is awkward at best.

Moving a tile from one logical position to another is an animation thing and super simple to do in script so I don’t see how physics should get involved in it.

4

Thanks for responding :slight_smile: If I understand your concern correctly, you’re wondering why I don’t just use something like MoveTowards or Lerp (upon a click or touch interaction) to the new position with no physics involved? I guess I just wanted to try to create a version that allowed for more user interaction over the pieces, draggable tiles.

But in any case, another user linked me a related thread and I saw your link here - https://www.iforce2d.net/b2dtut/ghost-vertices. (This thread is yet another "why does my character get stuck when moving along flat ground?" but at the time of creating this thread I wasn’t sure the right wording to search for to find similar questions). So this is probably what I should read up on.

5

Yes but dragging doesn’t require physics; it’s obviously just moving which is why I questioned the use of physics i.e. bodies, colliders etc.

I just think you’re using the wrong tool here.

6

Currently I’m using the rigidbodies for collision detection/overlap prevention. What are you thinking is the correct approach here?

7

Not using physics to know if you can drag a tile from one position to another. A 3x3 grid is an array, each item knows whether there’s a tile there. You can select tiles where the array isn’t empty and move it and it ends up at another logical tile position and you update the array. The tiles are in a uniform grid so you don’t need rigidbody physics to know where it moves from and to.

Short of writing code I don’t really know how to answer more.

1 Like
8

Cheers. I’m using a 4x4, and (unless I’m mistaken this isn’t addressed) I would like the ability for a puzzle piece to not stick to a grid position unless its close enough. This would allow other pieces along the same row or column of the empty space (only y movement in the column, or x in the row) to potentially collide with each other. Naturally I’d want them to avoid overlapping and I assume this can be done with some simple raycasting and logic like “if (position.x + extents.x) + mouseDelta.x > hit.point, position.x = hit.point.x - extents.x”