Fix breakout example bug - ball flighlying out when collide paddle and wall at the same time

[liufuyang]

It seems there is a bug of the breakout example, that when ball is collided with both paddle and the wall, the velocity is evaluated and reflected with paddle first, then that break will stop it evaluate if there is other collisions, then the ball will just fly out of the wall.

It is easy to see the bug if you try hold the ball between the paddle and the bottom wall then follow it until the ball hits left or right wall. Then there is a good chance when ball hit paddle and left/right wall at the same time then just flying off the walls.

This should fix this bug in some degree but might not prevent other potential bugs related to this. For example the ball might hit the corner of two walls and only one axis of velocity will change and it might still able to fly off the walls. I was also thinking about collect all the possible collisions then do proper velocity change based on all the current possible collisions, but that might name the code a bit too complicated for an intro example?

[cart]

Yeah I think the current approach to collisions is pretty naive / breaks easily. But in this case I wasn't able to repro, despite doing this and letting it bounce for a long time (10 minutes):

I think the "ball flying out" problem is more a result of framerate dips (resulting in large deltas + missed collisions) than duplicate collisions, and the only way to fix that is to build a more complicated collision system.

Regardless of whether or not this pr fixes a bug, I think I'd rather not add too many "special collision cases" to example games to hack around the limitations of the collision system, as they're intended to be extremely simple illustrations of game logic.

I'd rather focus our energy on making the collision system itself better (or adopting a third party solution like ncollide for collisions)

[liufuyang]

I think you need to try it as setting the bar length slightly shorter to have some gap facing the wall, perhaps use a bar length of 855 or 850, then as long as the ball touches the narrow gap, it flies away (takes like 10 or 30 seconds for me to see it.)

I think this could be a bad initial experiences or impression towards the engine when someone new here to try it out the code example for the first time. I just started looking at bevy yesterday, tried to run the first breakout example then while I played it for a few seconds I encountered the bug. Or maybe I was lucky. But initially I had a feeling that this game engine is not "reliable".

If there is a simple way to fix this, while not making the code look too much difficult to read, perhaps we should do it?

[cart]

Cool I was able to repro with that advice. You're right about "perceived quality" being important and I guess this isn't particularly complicated. Can we change the match statement to this instead?

// break if this collide is on a solid, otherwise continue check whether a solid is also in collision
if let Collider::Solid = *collider {
    break;
}

[liufuyang]

But yeah if there is a way to make the collision system better or even easier to use, then of course that would be a better solution over all. What I am afraid is others might having the same first impression that "it is buggy" if they just try out the first example then encounter a bug like this.

[liufuyang]

Sure I can update the code. Thank you for the input 👍

[liufuyang]

Even though this make it less buggy but it might still not being perfect yet as when I tried out this solution, very few occasions it still can go out. But at least it is much more robust for now. Looking forward to a better collision system later then 👍

[DJMcNab]

@liufuyang please respond in #2373 for the relicense to MIT/Apache 2.0. Thanks!