4
\$\begingroup\$

So, I'm using box2d for my 2.5d game (think double dragon, tmnt arcade, castle crashers) where you can move around on the z-axis (faked as y-axis movement). Basically, I have box2d only doing collision if 2 entities have the same z coordinate or a z-coordinate within the depth. All is fine, except when I approach an entity from the top or bottom. explanation

So yeah, approaching any box2d entity from the top or bottom within the correct x will make the player bounce back once the z becomes the same as the entity - which makes sense because then it starts detecting collision, and it detects a box inside a box. How could I circumvent this? Thanks.

\$\endgroup\$
4
  • \$\begingroup\$ Have you considered making the collision box only a small fraction of the lower part of your sprites? That way, they would only collide at if the bottom parts of the Sprites touch. \$\endgroup\$
    – jgallant
    Commented May 28, 2013 at 17:05
  • \$\begingroup\$ I have, but I thought that it might affect the rest of my collision - I'll try it though. \$\endgroup\$
    – Jimmt
    Commented May 28, 2013 at 17:06
  • \$\begingroup\$ Right, it may or may not work for you. Mulling it around in my head though, it could definitely work for this type of game. Stationary objects would have full collision boxes, and if your player's feet come in contact with it, it will prevent you from going through it. \$\endgroup\$
    – jgallant
    Commented May 28, 2013 at 17:15
  • \$\begingroup\$ tried it, ended up with flickering when approaching from the bottom and completely going through it when approaching from the top. I'm pretty tired but I'll think about it some more tomorrow. \$\endgroup\$
    – Jimmt
    Commented May 30, 2013 at 5:43

2 Answers 2

Reset to default
2
\$\begingroup\$

This blog post covers pseudo 3D collisions and discusses an interesting solution to your problem. I'll give an overview of the post but you should check it out as it does a thorough job of explaining the solution (with pictures too!)

Their entities are essentially represented by three parts: a box for the body, a box for the footprint and a box representing the attack area. You can think of the body box as representing the width and height of the entity and the footprint as representing the depth. The footprint is used to determine z-order for drawing and whether or not entities are capable of colliding with one another. So, when the player is just moving (not attacking) only the footprint is used to determine whether it's colliding with another entity.

In Box2D terms an entity could be represented by a Body with three Fixtures for the body, footprint and attack. Each Fixture would be a sensor so you get begin/end callbacks for collision detection but the Fixtures don't actually physically collide. In other words, just use Box2D for collision detection not physics simulation.

\$\endgroup\$
0
\$\begingroup\$

You shouldn't treat your objects as boxes with the same height the entity have. Your objects should have a collidable fixture only on the FOOT, and the head+limb+legs should be a sensor fixture, where you only use it to detect if a player has fell on top of another, etc.

\$\endgroup\$

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .