# How do I handle Isometric collision detection?

I would like to make an isometric run-jump style platformer. The player should be able to jump on top of platforms above the floor, hit the side of objects etc.

I'll be using a 2D game engine so I wouldn't like to emulate full 3D collision for dimensions I'm not using.

I'm thinking objects in the game should be placed using: X, Y, width, height, and Z for depth.

Using those values, how should I detect collisions?

-
I know this is a general sort of question but, I would like more detailed answers or links to good learning resources. – jdeseno Jul 25 '10 at 14:43

2 options:

• You could treat it as a 3D game with a fixed orthographic camera. Then you could use any standard 3D games resources / books / tutorials / libraries. Even if it rendered in 2D with sprites, the maths for movement etc would still be 3D behind the scene. This would give you the most accurate results.

• You could treat it as a top-down 2D game, with an added height property. For example, imagine a 2D grid where each tile has a height value. When moving from one tile to another, you only let a character pass to a particular tile if the character's feet are above or equal to the height of that tile, but if they are jumping and gravity brings them down on top of a tile, you let them remain there. With a bit more work you could make it so you can walk under bridges etc.

-

There are a lot of ways you could simplify this. For example, if you didn't allow layers (for example, a bridge you can both walk over and under, you could do all the collision detecting in X/Y dimensions, where you filter the collision set to anything of its height+depth or higher.

-

If the game is based on a rectangular grid, then this grid defines your X/Y axes. And Z can be used for height.

Collisions are then as more-or-less as easy as any 2D tile-based game.

Then you just need to convert from the grid back to isometric screen coordinates for rendering. This is fairly straightforward - but you may need to think about calculating 'depth' values, for sorting purposes (rendering the isometric scene from back to front)

-
Using Z for height goes against instinct, but it is the right thing to do on top-down 2D games. then you can reuse code between side-on and top-down games. – Iain Jul 23 '10 at 14:40

Googling around I find this demo: http://planetskill.com/iso/

WASD to move. Space bar to jump

It only implements collision with the up/down axis but adding the other collision should be easy:

If the up/down position of the next step is higher than your max just don't move. This should also let you implement jumping in a easy way.

Sample code here: http://gist.github.com/478997

-

Well you could have a separate collision layer above your level that is not visible and use that to check for collision.. You can also use this for multiple layers as long as you know on which layer the player is ;)

-

All of the above. Isometric is just a sheared 2d grid so treat it as a 2d tilemap and think of a way to encode depth. How would you do that in a regular 2d game (being able to go behind or in front of blocks when 'jumping'? You'd either store a depth per tile (depth buffer->z buffer) or you'd use multiple layers, or, if you want fancier, you'd implement a callback per tiletype (or mapposition) and would be able to do whatever you want, check depth, check equipment, warp player around, have player slowly move up, format HD.

-
Good answer Kaj -- this being the crux of the matter, I'm surprised no-one else brought it up. This is always the thing that confuses newbies about isometry, in regards to physics. – Arcane Engineer Sep 8 '11 at 19:22