I'm prototyping a 2D platformer/brawler game for uni and I'm having some trouble with creating collision/bounding boxes. This is most likely going to end up on a Vita so I do have some library constraints as well as performance implications.

None of this has yet been implemented but is all theory.

My idea was to have the artist create a sprite sheet for the character animation and then a second identical sprite sheet with the corresponding collisions in a solid colour (e.g green for where the character can be hit and red for dealing damage, near the foot if kicking etc.)

With this, I would then parse the collision sheet and generate the various collisions required storing them in the character model. This is the point I feel would be most inefficient.

While I think this is a possible solution, I was wondering if there was a more standard way of doing this or a more efficient way as I feel this would have severe performance problems.

  • \$\begingroup\$ I like the idea of using pixel coloration to detect collision with different body parts. \$\endgroup\$ – bobobobo Oct 28 '13 at 14:45

You should go for a set of bounding boxes (BB) per sprite. This way you can separate your points of interest in the sprite and automatically knows which parts of the sprites participate in a collision. For example, you could have BBs for the arms, heads, legs, etc. The price for that is that you also must animate them and you will have more collision entities in your game. You should also use Oriented Bounding Boxes, since they have more culling efficiency than other boxes. If you want more detail and can afford the performance penalty, go for K-dops.

| improve this answer | |
  • \$\begingroup\$ This is pretty much the standard, even in 3D. \$\endgroup\$ – Casey Oct 28 '13 at 17:18

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.