I have a castle wall tileset that can be thought of as 1x3 vertical slices in my world:
I want the wall, as a unit, to be registered to my engine’s foreground sorter. If the player is behind the wall, I want it to render over them. My current implementation has worked great for whole objects by just taking the bottom pixel of the sprite and using that to accurately sort its render priority in the world. Tilemaps don’t really fit into this at all… Any ideas? I am fairly new to Tiled.
My current workaround is to render the walls as their own entity and sorting the entire wall as one large game object. It works, but it isn’t very flexible.
There are several ways to do it. You could seperate the wall tiles into their own tileset, and say the tiles are 32x96 instead of 32x32 (kinda like what you are doing now).
Another way is to add a custom property to the tile itself with the height-axis of the tile. So the bottom tile would have 0, middle 1 and the top 2.
An other possibility is to have a separate tileset with numbers as tiles, and an extra tilelayer for the height data. You don’t draw this extra layer, but instead just lookup which tile it has, and use that information for the height.
All these solutions have pro’s and con’s, and as far as I know there is no perfect solution that works for every game.
Actually officially typing the walls as 1x3 tiles makes a lot of sense. I am going to do that and see how it goes.
This actually leads me to a new question. When I render each tile to my game, it will likely be its own entity with its own properties. Even in a modest level, there will be a minimum of 400 tiles on the screen. With each of them being their own entity, I would not be surprised if performance starts to become a concern. Is this talked about much?
Rendering 400 entities is not likely to become a performance problem with today’s hardware, but when all your tiles are entities then it could become time-consuming to figure out which ones to render in the first place. This is much easier to do when you store the tiles in a grid, like Tiled does when you use a tile layer. There, each tile is just a small class storing a tileset reference, a tile ID and some flags to support flipping, and you can quite trivially iterate over just the visible ones in the right order.
Depending on the granularity of heights and your game and the heights of your moving entities, it may also work well to have your tiles as a few layers corresponding to different heights, and draw your moving entities between these layers as appropriate. That way, you would only need to z-sort your moving entities, and your tiles can exist as layers requiring no sorting (bonus: you can potentially draw them to the screen with a single draw call per layer).
This approach won’t work if moving entities are tall and may need to stand in narrow corridors where they may need to both be overlapped by a lower height and overlap a higher height simultaneously, but it works well for games with small characters and big jumps in height.
