Visual offset for Tilemap layers

[CarlCochet]

Alright, there might be a better solution that already exists so I prefer to open this discussion before making a proposal.

Here's my use case: I have a large amount of tiles (almost 4000) distributed in almost 40 sheets in my TileSet. But these tiles are all unique, no management of height whatsoever. I need to create isometric terrains that support different heights.

To give this impression of height, I can use layers and modulate their Z Index to display higher layers on top as demonstrated in this screenshot:

My problem however, is that I need half and quarter steps for the height as well, not just full block height. To fake a half height, I can technically divide the tile size by 2 and then use tricky tile placement to give this impression, as showed here:

However, now if I want to have the quarter height I need to divide the tile size by 4 and it becomes even more complicated to use! Not only the level designing becomes tedious, but potential terrain interactions through code will become an absolute mess to try and compensate for all these tricks.

I tried asking about this problem on the Discord but got no answer to any of my questions so I figured I'd explain here my potential solutions:

• Divide tile size by 4 and struggle through hell to design the levels and make the game work with it
• Create 4 versions of each tile to match each height, end up with 16000 assets and 160 tilesheets in an absolutely unmaintainable and unusable TileSet
• Add a new functionality to the Tilemap node by providing a visual offset to each layer

So first I'm obviously wondering if there is a better current solution to this problem than the 2 I mentioned. I don't know how common this problem might be so I'm not sure if it has already been tackled frequently.

And if there is no better solution, what do we think about this idea of visual offset?
The nice thing is obviously that it would add flexibility to the Tilemap node, while the potential downside would be that it would add another parameter to each layer which might clutter the interface a bit. I don't know how doable this feature even is, I've yet to look into the code.

[azur-wolve]

it sounds like the problem is on the asset making side, not the engine
sprites are supposed to be designed with all those problems in mind

[CarlCochet]

If you need a better understanding of the kind of height manipulation I need to do, here's an example of a map I made for this project:

[azur-wolve]

not sure if this could be useful → https://github.com/godotengine/godot-demo-projects/tree/3.4-b0d4a7c/misc/2.5d
its for Godot 3, but as is on GDScript isn't hard to port to Godot 4

(in the example image you shared all blocks are the same size, that simplifies all)

[CarlCochet]

Hmmm this could technically be a solution, however I don't see how you could use a TileMap with this, meaning I'd basically be making a map by placing a ton of individual sprites, right? I'm not saying it's impossible, but that hardly sounds ideal as a workflow. If anything, it sounds more complicated than creating a different TileMap for each height

[TeacanTzu]

out of curiosity, have you found a solution for your project?

[CarlCochet]

Sadly I could not find a better solution than having a TileMap for each height. It's not ideal, but for my use case it does the job.

Now to be honest I've been mostly busy writing our animation system recently so I haven't looked into many other solutions

[TeacanTzu]

Something like this would be such a big improvement.

One thing that would have to be taken into consideration is how local_to_map() and similar methods would work.
if its purely visual it might lead to unintuitive results. But even then, it would be a big step into the right direction.

Another use for this would be a Hexagon grid with flat sides like this:

Usually in isometric you have to go a "full-step" up to avoid this issue but in this case you would have to go 2 steps up.
Godot now supports hex-grids so it should also provide the solution to this problem.