2D Collision behaves unexpectedly

Physics
, ,
1

I’m making a Puzzle Bobble inspired game where you shoot CDs instead of bubbles. However, my collisions behave very strangely sometimes. In the video below you can see an example (the shot at ~00:03):

Some additional context: The black, slightly transparent bubble is the last position of the bubble before snapping to the grid. The green line is drawn from that position to where the bubble was snapped. The red line is from that position to the first collision contact point. The cyan line is where the bubble would snap based on the contact point.

The static bubbles have a Kinematic rigidbody. This behaviour happens with the toggles “Simulated”, and “Use Full Kinematic Contacts” both enabled and disabled. The moving bubble is Dynamic, but becomes Kinematic upon snapping in place.

The problem is that the bubble is shot from below, hits the green one, but because the collision is detected way too late, it is snapped to the row above instead of the one below. How can I prevent this? Can I increase collision precision/ frequency somehow?

The game including this bug can be played on my itch: https://untravelled-realms.itch.io/hyper-bubble-dj

2

Don’t use physics or collisions for this… store the data in a grid and do your own movement until it comes close to where it needs to be to line up and latch.

Here’s more:

Tile-based / grid-based 2D games: match3, tetris, chips challenge, rogue, pac man, etc:

For any tile-based game such as Match3 or Tetris or a grid-based Roguelike, do all the logical comparisons in your own data storage mechanism for the tiles, such as a 2D array of tiles.

Otherwise you needlessly bind your game logic into Unity objects and the Unity API, making it about 10x more complicated than it needs to be.

If you have no idea how to work with 2D arrays, hurry to some basic C# tutorials for the language portions of it, then look at any good tutorial that uses a 2D array

Here is my Match3 demo using this technique of storing data in a grid. Full source linked in game comments.

https://kurtdekker.itch.io/match3-demo

It stores all of its data in a 2D array:

PieceController[,] Board;

This allows for easy simple checking in code, not relying on anything like physics.

You should strive to use that pattern for all logic, then only use Unity to present what is happening in the game logic.

3

Since the things move very fast you want to enable continuous collision detection on the CDs you shoot.

4

I haven’t implemented a bubble-style game, and I don’t know what exact behavior you’re implementing, but like the previous poster, I’d suggest not using Unity’s built-in physics or collision systems for this.

Continuous collision detection between circles/spheres is, fortunately, fairly straightforward. It can also be simplified by treating one circle (or sphere) as a point and expanding the other circle by the radius of the first, reducing the test to a linear component (segment, ray, or line) vs circle test. Given certain constraints, numerical issues can be more or less eliminated as well.

It may take some work to put that all together, but it seems likely to be a better approach. (It would be my starting point for something like this, certainly before trying to use a physics system in any capacity.)

5

I’ve looked at the Rigidbody a thousand times, and never noticed it as an option. Enabling this toggle for only the dynamic bubble solved the issue, thanks a lot! After playtesting it doesn’t seem like its necessary for the kinematic ones.

And with regard to Kurt & j_y_k: I disagree, and I’m fairly certain physics and collisions are the best way to implement the shooting of the bubble. As I stated in my initial post, after that initial collision the bubble is snapped to a grid, and the rigidbody is set to Kinematic.

6

Yes, using continuous col-det for this works perfectly fine but so does using physics queries too ahead of the “projectile” (thing that moves fast).