1
\$\begingroup\$

I'm building a game in C/C++ (been alternating between the two), but one of the biggest problems I've run into is collision detection. The game is isometric and exists on a 2x1 grid (e.g. the base tile is 32x16px).

Most creatures in the game use ellipses as collision masks (similarly 2x1 sized, default size is 32x16), whereas static objects use rhombuses for masks (again, 2x1, 32x16 default). How do I detect the collision of these two distinct shapes? Also, how do I detect collisions between two ellipses and/or two rombuses?

I've looked at the Separating Axis Theorem, Voronoi diagrams, and all kinds of other things, but I am having trouble understanding them (which is a pretty essential step for C/C++). Can anyone help me to understand these techniques?

Improve this question
\$\endgroup\$
3
  • 3
    \$\begingroup\$ Remember that the shape you draw to the screen doesn't have to be the shape your world "is". Isometric games often represent a world with a regular square grid, and just project it to the diamond form for display purposes to model looking at the scene obliquely. Sticking in pre-projections space can make a lot of your math simpler & more uniform (eg. circles & squares instead of ellipses & rhombuses) \$\endgroup\$
    – DMGregory ♦
    Oct 4, 2017 at 22:39
  • \$\begingroup\$ Along the lines of @DMGregory 's comment about simplifying things by utilizing the internal game model instead of relying on the rendering shapes, I wonder if you're able to disregard the geometric calculations entirely. Might it be sufficient for your purposes to simply treat it as "player wants to move to cell [x,y], is that cell already occupied?" \$\endgroup\$
    – A C
    Oct 4, 2017 at 23:12
  • \$\begingroup\$ I was considering going with that model, but my game doesn't snap to the grid. Since it's an open-world RPG with fairly free movement, I feel like my players will feel cheated if they don't get good collision. How much of a performance hit am I really looking at with these kind of collisions? \$\endgroup\$
    – WulffHunter
    Oct 5, 2017 at 4:21

1 Answer 1

Reset to default
1
\$\begingroup\$

Exactly because that kind of problems we have two coordinate system, one is the view coordinate system (the isometric one) that you uses to draw and the other is the world coordinate system where you do the mapping (a regular Cartesian plane).

Collisions should be handled in the world coordinate system. You also need to write 2 functions to translate coordinates in those two spaces: world2view and view2world.

The exact details of those two functions depend only of your isometric camera angle.

Improve this answer
\$\endgroup\$

You must log in to answer this question.

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