I'm planning to write a fairly basic scrolling shoot 'em up, however, I have run into a query with regards to checking for collision. I plan to have a fixed top down view, where the player and enemies are all 3d objects on a fixed plane, and when the enemy or player fires at the other, their shots will also be along this fixed plane.

In order to handle the collision, I have read up a bit on collision detection in 3d, as it is not something I have looked into previously, but I'm not sure what would be ideal for this situation. My options appear to be:

  • Sphere collision, however, this lacks the pixel precision I would like
  • Detection using all vertexes and planes of each object, but this seems overly convoluted for a fixed plane of play
  • Rendering the play screen in black and white (where white is an object, black is empty space), once for enemies and once for the player, and checking for collisions that way (if a pixel is white on both, there is a collision)

Which of these would be the best approach, or is there another option that I am missing?

I have done this previously using 2d sprites, however I can't use the same thinking here as I don't have the image to refer to.

Edit: For clarity, I just wanted to add some additional information.

One of the things that I would like to account for is if the player or enemy is rotated in some way, which would mean intersecting along 1 Z plane would not be completely accurate. For example, if there is banking on the player's ship when they move from side to side, the tips of their ship would be above and below the central plane, but I would still like these parts to be possible to hit.

Secondly, I plan to have different sizes and shapes for the player's craft, where the size and shape affects the hit box and is one of the properties the player can use to choose which ship they would like to use.


1 Answer 1


Your gameplay is 2D, so your collision detection should be too. Pixel-perfect collision is an unusual approach for shmups - generally these use hitboxes (often considerably smaller than the entities, for the player at least).

I'd generally go for circle-circle collisions, possibly with circle-poly collisions to allow more complex boss shapes (using an aggregation of circles and convex polys) for a game like yours. That would, of course, mean you'd need to specifically define your hitboxes for each entity.

  • \$\begingroup\$ Thanks for the comment. With regards to having the smaller hitbox, I did think about this, but it would not work with what I am aiming for. I've added some extra information about this to my original question, sorry about the confusion. With regards to the circle-poly collision, this may cover what I need, but I am concerned that it would not meet the precision I would like, for example, if one enemy type is tall and thin, I would like a bullet to miss them by flying parallel to the enemy, which a circle hitbox would give a false positive to (potentially) \$\endgroup\$
    – Lyise
    Jul 2, 2012 at 16:09
  • \$\begingroup\$ Well, then, you can give that enemy a polygon hitbox - that's the sort of thing I'm talking about. Circle-circle, circle-poly and poly-poly are all straightforward to implement, define, and manipulate (for example, if you want your ship to bank as you move left or right, you might implement that hitbox-wise by simply scaling it down along the X-axis). metanetsoftware.com/technique/tutorialA.html is a good tutorial for collision algorithms using these shapes. \$\endgroup\$ Jul 2, 2012 at 16:39
  • \$\begingroup\$ Thanks for the information and the link, I think I'll go for the polygon hitbox approach where the Z axis is ignored in collision detection as you suggest. \$\endgroup\$
    – Lyise
    Jul 2, 2012 at 16:48

You must log in to answer this question.

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