Blob tiles are autotiles that match edges and corners. I know that for two different kinds of tiles, I need 47 * 2 tiles. But I have three different kinds of tiles. I thought that I needed 47 * 3! tiles, but I made them all and tried to use them, and discovered I was missing some. Like, a tile can have all three different kinds of tiles on it, and I didn't make those. How many do I need to make?
2
-
\$\begingroup\$ Blob is a little funny in that, if you think of the two tile types it mixes as "foreground" and "background", then it allows a background corner between two foreground edges, but never a foreground corner between two background edges. So there's an asymmetry in it. It's not immediately clear how that should be extended to three different tile types. Can you describe how you do your underlying authoring or tile selection? (eg. Do you set tile type at tile corners, tile edges, tile centers, or all of the above?) That can help clarify what possible permutations can show up. \$\endgroup\$– DMGregory ♦Mar 19 at 1:29
-
\$\begingroup\$ I am using Godot 4 match corners and sides. I'm not really sure how that translates to what you're asking. I think I set tile type at all of them? \$\endgroup\$– EmilyMar 19 at 1:30
Add a comment
|
1 Answer
\$\begingroup\$
\$\endgroup\$
1
If I'm reading Godot's Terrain TileSets documentation right, you can potentially select a different tile for any permutation of terrain types painted in this square and the 8 squares around it.
So if you have 3 choices in each of those 9 slots, that's \$3^9 = 19\,683\$ tiles.
Apart from the grief of authoring all those permutations (if you could make one tile every 15 minutes and worked 8-hour days with no weekends, that's nearly two years of work!), that's also just too much data. If each tile is say 256 pixels wide then that's 4 GB of uncompressed texture data! 😱
So, you need another strategy.
One surprisingly effective tactic is to work on "the dual grid". This is something Oskar Stålberg champions (see a talk here where he discusses it in more detail)
Here instead of thinking of the terrain type as being defined at the center of the tile, we think of it being defined at the corners. Or alternatively (for a square grid), we think of the grid on which we place tile sprites to be shifted one half tile over from the grid we use for painting / game logic.
With this simplification, for three terrain types you need only \$3^4 = 81\$ tiles, so we've saved ourselves several orders of magnitude of work, data storage, and complexity. You can see a sample layout of these 81 tiles arranged to seamlessly match their neighbours in this answer.
However, I'm not knowledgeable enough about Godot's systems to comment on whether there's a way or how to coax its TileSets into using the dual grid this way. Maybe others can suggest strategies for this.
-
\$\begingroup\$ Thanks for the answer! However, Godot doesn't use all 256 tiles for a single tileset, it only uses 47. So I think the answer is actually 3*(4*pow(2,7)+2*pow(2,6)+1*pow(2,8)+4*pow(2,6)+4*pow(2,5)+1*pow(2,4)+4*pow(2,3)+8*pow(2,4)+4*pow(2,1)+4*pow(2,5)+4*pow(2,2)+4*pow(2,3)+2*pow(2,2)+1*pow(2,0)) tiles. Which evaluates to 4947 tiles. That will only take me 155 days to complete! I guess I should look into using less tiles lol \$\endgroup\$– EmilyMar 19 at 3:43