Terrain tool support for multiple tile sizes

Hi folks, does anyone know if there’s an open feature request for the terrain tool to support multiple “tile” sizes? If not, I’ll be happy to file it. To explain a bit: my maps are 16x16, I don’t want to change that, but in addition to 16x16 tile graphics, I also have some 32x32’s in my texture atlases. Obviously, Tiled sees the “32’s” as 2x2-16’s (a square composed of 4 16x16 tiles) but, I would like Tiled to be able to “terrain” with those 32’s as well. In this case, I’d be able to tell tiled whether a new terrain I’m making should be terrain-tile-size 16, or 32, (essentially, tile-size or 2 * tile-size). Cheers map-makers!

1 Like

Hmm, it sounds like this is something that may fit into the Wang tiles project @Benjamin_Trotter is working on this summer. To make sure we understand exactly what you mean, maybe you could provide your tileset and/or a mock-up or sketch showing what you mean in terms of terrain information editor and the desired behavior of the terrain tool?

Good point. A picture is worth a thousand words. I’ll mock this up tonight and post back shortly.

More info on the request. Here’s what a 32x32 tileset looks like in a Tiled map that has a tile size of 16x16.

These graphics were designed for 32x32 map editing as can be seen with purple highlights here that identify the ledges and corner pieces:

Because I have other graphics on the same atlas that are designed for a 16x16 tilesize, I want the tilesize to stay at 16x16. I can rubber stamp this art (and that’s what I will do). But it’d be great if I could terrain with it instead. It looks like Tiled would need an enhancement such that when defining a terrain, the size of the terrain pieces could be defined first. e.g., if I could pick terrain pieces size of 2x the tile size, it would work with my 32x32 sized graphics:

as it stands, there’s no good way to use the 16x16 terrain definitions for these particular 32x32’s. i.e., the following is clearly incorrect:

I understand this is an incomplete terrain, but Tiled is lenient and would still do it’s best to do what it can with the pieces it has (thumbs up, Tiled team). I believe that Tiled allows different layers to be different tile sizes, and in that case one might suggest that the 32x32 graphics be used on a different, larger-sized layer. That’s not desired though as the map design complexity will not be worth it, IMO. I understand this is a non-trivial request - there will inevitably be quite a few programmatic challenges (i’ve thought of a few and cringed while writing this), but hey that’s what us supporters are here for. Give ideas on the sideline and cheer, cheer, Cheer :slight_smile:

1 Like

I think it’s an interesting request, but I think it will be really too tricky to implement. I’m not entirely sure how it could be done, since there will be plenty of “unsolvable” situations where the tool somehow needs to decide what to do.

As it stands, the tool works on tiles and for each corner of each tile, the terrain type is defined. So when you change something in that grid, it can figure out what tiles to use to make sure things connect again. This breaks down when the terrain pieces are 2x2 tiles. The pieces already used on the map would not necessarily be whole terrain pieces, since you could have placed only a 16x16 piece somewhere. With that it loses the ability to determine what the current state of the terrain is at a given location. I imagine you could work around this by essentially only considering valid terrain information when you find a 2x2 block that matches one of the blocks for which terrain information was defined.

There are other problems to solve though:

  • Currently terrain information is stored with each tile. For the above system, it would need to be stored separately and define the size of its blocks.

  • I see no way to enable using terrains with differently sized blocks together. Maybe it’s not something you’d need, but the user may attempt this and needs to be somehow informed that it won’t work. On the other hand, this is not different from not being able to use terrains from different tilesets together (though that’s a problem I could imagine fixing sometime).

  • The tileset view renders a terrain overlay per tile. Its implementation would need to look quite different to enable rendering and interaction with a terrain overlay spanning blocks of tiles.

All in all it’s a major piece of work, and I’m not sure how many people would be looking for something like this. Preferably we’d find some other way to speed up map editing. I think for example that the RPG Maker way of doing terrains may suit your needs better, since it also cuts the tileset into smaller pieces (issue #1022).

Cheers, Thorbjørn. Agreed after a second look, it’s certainly a massive effort and there are inevitably stacks of higher priorities, smaller tasks for bigger gain. As for the RPG Maker tileset request (issue #1022). I’m not sure I’d use it. The RPG Maker tilesets are confusing at first glance, and even though the micro tiles should save precious texture atlas space, in practice there seems to be enormous amounts of duplicated graphics per animating tile requirements (many artists don’t animate each tile, hence the proliferation of exact duplicates). But more importantly, if I understand correctly the native tilesize would need to be 32x32 such that the micro size is 16x16; but my atlases predominantly 16x16, that format would be out of the question. Thanks again for taking such a thorough look at this!

Well, the important difference is, that in Tiled there is no “native size” and “micro size”, so the map in general would necessarily need to be “micro size”, and only the potential RPG Maker compatible autotiling tool would pretend to be editing the map by 2x2 blocks. Hence I thought this may be roughly what you are looking for. I definitely agree with those tilesets being confusing at first, though there are some blog posts out there explaining the system.

Oh, wow! if that’s the way Tiled would implement it then it does sound like what I’m looking for :+1: Subscribed for updates to #1022. :+1: