OK, I’ve admitted it before. I’m a Box2D junky.
I use the physics engine for everything but I’m wondering when you all choose not to use physics for collision tracking.
Do you use non-physics collisions for simple games or maybe for multiplayer online games?
If we are just talking about just detecting collisions between simple shapes, then yes. However, once we get to talking about the physics behind the collisions and all that, then I opt in for Box2D every time.
I do frequently use point-in-polygon detection in tandem with Box2D. For instance, I have one mini golf project that is from top down perspective. Naturally, the game features all sorts of surfaces, like sand, water and slopes. With Box2D, there can be issues with detecting if and when a collision begins or ends when the ball is moving fast and/or when there are multiple overlapping (or worse, almost overlapping) surfaces. But, by simply checking to see if the ball is inside any surface via PIP, it becomes easy and reliable.
The thing that came right to mind was any situation where the third dimension comes into play in a significant way. It complicates matters, at the very least.
I’ve found it’s messy to deal with changing shapes, since last I knew you had to destroy and recreate them, and your own logic needs to be ready for that.
There is also a problem somewhat like this, shapes overlapping but the potentially-colliding status is in flux, that can be a bit of a hassle with Box2D alone. (I don’t know if the fix there handles already touching and becoming vulnerable again, for instance.) I know there was a more recent thread on exactly this, but searching has failed me.
I would say never use physics for collisions unless in specific circumstances:
You are already using physics for other aspects of the game. You are already paying the processing overhead for the physics engine,
You have complex shapes, such as a concave object that you need empty spaces to be non-colliding and a simple box or circle won’t do.
If you’re building a card game, you just need to know if the card is over a drop zone, no need for physics to do that.
The physics engine is already looping over a list of objects and computing if the objects are overlapping, so you’re doing the same thing in an enterFrame loop should accomplish the same thing.
Rob
If we are just talking about just detecting collisions between simple shapes, then yes. However, once we get to talking about the physics behind the collisions and all that, then I opt in for Box2D every time.
I do frequently use point-in-polygon detection in tandem with Box2D. For instance, I have one mini golf project that is from top down perspective. Naturally, the game features all sorts of surfaces, like sand, water and slopes. With Box2D, there can be issues with detecting if and when a collision begins or ends when the ball is moving fast and/or when there are multiple overlapping (or worse, almost overlapping) surfaces. But, by simply checking to see if the ball is inside any surface via PIP, it becomes easy and reliable.
The thing that came right to mind was any situation where the third dimension comes into play in a significant way. It complicates matters, at the very least.
I’ve found it’s messy to deal with changing shapes, since last I knew you had to destroy and recreate them, and your own logic needs to be ready for that.
There is also a problem somewhat like this, shapes overlapping but the potentially-colliding status is in flux, that can be a bit of a hassle with Box2D alone. (I don’t know if the fix there handles already touching and becoming vulnerable again, for instance.) I know there was a more recent thread on exactly this, but searching has failed me.
I would say never use physics for collisions unless in specific circumstances:
You are already using physics for other aspects of the game. You are already paying the processing overhead for the physics engine,
You have complex shapes, such as a concave object that you need empty spaces to be non-colliding and a simple box or circle won’t do.
If you’re building a card game, you just need to know if the card is over a drop zone, no need for physics to do that.
The physics engine is already looping over a list of objects and computing if the objects are overlapping, so you’re doing the same thing in an enterFrame loop should accomplish the same thing.
Rob