How to get the physics just right in a physics driven game

Question

I'm working on a physics driven game using a java port of Bullet (JBullet).

In our game we have a ball that can have collisions with the other objects, including the objects that define the boundaries of the playing area.

Since we consider collisions between the ball and other objects as a very important aspect of the gameplay we wish to handle those collisions in our own code. This allows us to get non-realistic but very controllable behavior for the ball.

The other gameobjects also collide with each other, but JBullet handles those collisions well and we have no issues there.

The problem is that we have great difficulty triggering the custom behavior in the correct way. In our first set-up called our custom collision handling code every time JBullet reported a collision for the ball. This caused undesired behavior as a single hit could trigger multiple reported collisions. Which caused the ball to be sort of glued to the wall.

Our "fix" for this was to have the ball keep a timer and to ignore subsequent collisions occurring within let say 0.1 second of another. However, this caused ball to bounce through walls in some cases, probably because the first reported collision isn't the one we expect, and the ball-wall collision occurring shortly after is sadly ignored.

So that brings me to my question. How does one sort this out without resorting to all sort of "fixes" that only make the problem more complicated and less predictable?

Would for instance placing the ball at the last known position before the collision and handling the collision from there work? But what if another object has moved to that position in the mean time.

Or maybe calculate future collisions with the ball for non-moving objects and enforcing them if they are missed by the physics?

Any feedback / thoughts / revelations would be greatly appreciated!

Answer 1

About objects sticking to one another, that is a classic flaw in impulse physics simulation engines, it happens when two objects haven't cleared each other completely after a collision, the collision formula will then shift them back to move towards one another, and they will stick to this pattern until something disturbs it. The simplest way to deal with this problem is to check if the two objects are actually moving towards one another, if not, don't respond to the collision.

As for using custom handling on top of a prebuilt library, beware about it, when you open the black box you will have to understand what goes on inside it in order to be sure that you don't break anything. In some cases rolling your own physics could be a better alternative, you would certainly gain a lot of useful knowledge for tinkering with physics this way.