This is where I started back in middle school in 2003, and this is where I have once again found myself... I've built a lot of cool things when it comes to programming, but this concept still eludes me.

I'm trying to create a tower defense game, and there will be a ton of occluded objects on the map. What I want to accomplish is something with this level of complexity:


I really do not have any idea of where to go in terms of determining occlusion. This has been a pretty big pitfall at the moment, and it has set me back quite a bit. One idea I had was to give each tile a depth value based on the corresponding layer tile belongs to, and 4 collision boundaries: one on the left, right, top, and bottom border of each tile. The collisions will only apply to dynamic objects (characters, animals, enemies, etc.) if their depth value is congruent with the tile's depth value. This work wells when you have multiple layers of tiles stacked on top of one another when dealing with collision detection, and complete tile occlusion between the character and the tiles that belong to the layers above and below the character.

Here are the two issues I face:
1) Trying to get the character to change it's own depth by stepping onto certain "gateway tiles" that act like stairs between the layers. I'm not exactly sure where to take this concept...

2) Occlusion between the player and the tiles in the same layer as the player sprite when they are intersecting. This is my biggest issue. If the character is below the tile's intersection box, the top of the character that may be intersecting the tile should be drawn in front, but if the tile is above the

I'm getting imperfect results right now... Not quite sure where to go with this. Does anyone have any links or advice on how to get the depth and collision right based on the tile's depth?

The image above is a scene from Final Fantasy VI, which uses grid-based movement like Pokemon. At best, I'm looking for something along the lines of how Golden Sun handles depth occlusion and collision detection

">here.

Hopefully, I've made myself clear. I've been up for a while. I'll stop by later to check this post and revise it if necessary.

Perhaps I'm not quite understanding the question but here are my thoughts.

1) Do you mean the actual stairs (not pictured below)?

Is there any reason you're not drawing from the top of the screen down? This way when you draw something "below" it then it will draw over the tile above. The game you show forces the character to walk strictly on the square tiles (not like The Legend of Zelda where you could walk on half a tile). Since a character can only walk on a single tile (and the transition between tiles) you would just draw the character right after drawing the tile row in which they are standing. (I say after the row because of the transition). Anything below on the screen (like the tree for example) will be drawn after the character and will occlude them.

I couldn't tell you anything about Golden Sun as I've never heard of it before.

Quote:Original post by Vincent_M
What I want to accomplish is something with this level of complexity:

That is not top-down; it's a projection. Which is where the depth comes from.

Quote:I really do not have any idea of where to go in terms of determining occlusion.

Store separate data for the height of the environment. Store the 3D position of movable objects, perform calculations in 3D, and transform to 2D only for drawing. Draw sprites in order of the projected Y-coordinate of the bottom of the sprite (from top of screen to bottom).

I don't understand what you want. It seems like you want pointers on how to design multi-plane 2D maps, but the maps of the Golden Sun video and on the Final Fantasy VI screenshot you posted are all single-plane. (Although FFVI *does* support multi-plane maps, go to Jidoor, to the North of the Opera House.) My multi-plane maps, I mean maps like Zeal's Palace in Chrono Trigger where there are tiles you can walk over or under.

If it is never possible for a same tile location to be walkable at two levels, which is most likely the case for a tower defense game, then you should really avoid having to program a multi-plane tilemap system and just store, for each tile, 4 bits (or booleans) that tells the game from which side passage over a tile is blocked, and tile priority is defined by the layer the tile is on.

Doing multi-plane maps requires that you assign a Z-plane and a priority setting on a per-tile basis, and "cut" sprites in certain situations to avoid priority bugs, so it decuplates the complexity of your tilemap system. It's totally doable though, I've done it and it's not buggy at all.