sprites - Top-Down mapping with GLEED2D: Collision and Faux 3D

This is just a theoretical question. I was thinking of using GLEED2D to map a top-down game (I haven't decided on what type, but that shouldn't matter for this question.). I chose GLEED2D because I was getting tired of tile-based maps, and wanted to try something new.

However, two questions come to mind: How would you implement collision, and how would you display faux 3d? (I can't come up with a better name. It's where in RPGs and other topdown games you can have a bottom wall that obscures your character if you walk up to it. Say there's a pillar on the map. On a tiled map, it takes up one tile of space that you can't move on to, but the sprite itself is taller than one tile, so it covers character when you are behind it.)

An idea I had was to use the primitive shapes such as the Path to define areas where the character should collide. But then there's the faux 3d issue, which I can't figure out. Maybe GLEED2D isn't meant for it?

Answer

Problem #1 - Collision Detection

Under the assumption that you will use Gleed2D mostly for sprite based level editing, i.e. by placing, rotating and scaling a set of rectangular sprites in the world, I would suggest one of the following approaches to collision detection depending on your needs (read to the end even if the first suggestions don't apply to your case):

1. 
   

   Use a physics engine such as Farseer or Box2D to handle both collision detection and collision response between physics bodies that are good representations of your sprite's bounds. These bodies could be simple oriented bounding boxes or some other shape if more appropriate. Good for when the collision geometry should be fairly similar to the sprite's look.

   
   


2. 
   

   Similar to number 1 but handling collision detections yourself using an OBB-OBB intersection test between your sprite's bounds. See the Separating Axis Theorem for one common way to implement this sort of intersection. That's only valid if you want to use the sprite's bounds as the collision geometry though.

   
   


3. 
   
   

   If you wanted you could also add an additional pixel perfect collision test after step 2 by checking the opacity of the pixels on the sprites against each others. For this you'd need to transform pixels into the same space first. But I wouldn't really recommend doing this, and would go with one of the other alternatives instead.

   
   


4. 
   

   If on the other hand you need different collision shapes than the sprite's bounds then I think your idea was right on track. So what I'd suggest in that case is to add a new layer on Gleed2D just for collision geometry, and draw it using the Path tool. I actually do something similar to this on my graphic adventure game engine, although I use my own editor for creating the geometry. Here's a video of how it behaves. You could always add this functionality outside of Gleed2D if needed, and it's pretty easy to do using the Clipper library as I did on the video above.

   
   

Example:

---

Problem #2 - "Faux 3D"

I'm not sure I really understood your problem, but from my interpretation, I think it's just a matter of choosing the correct drawing order for your sprites. The approach I would take would be:

1. Assign an origin to each sprite that would act as the sprite's "feet", i.e. a point in the sprite that is touching the ground. In its simplest form, you could simply pick the middle-bottom point of your sprites.


2. Sort your sprites so that they're drawn starting from the ones with lower origin Y values and moving towards higher origin Y values. This way, objects further down the screen will automatically occlude objects that are supposed to be behind them.

Example:

Note: I marked the origins on the sprites using a blue dot, and drew them top to bottom. I assume this is the effect you were talking about.