Rework tilemaps and tilesets

[groud]

Describe the project you are working on:
Godot

Describe the problem or limitation you are having in your project:
Tilemap/Tileset UX is bad

Draft proposal

This proposals aims at improving the tilset/tilemap UX with a big refactor. This proposal thus lists a lot of changes.

Global changes

• Merging the tilemap and the tilset inside the same place, at the bottom.

Tilemap node update

Move those properties to tilesets/tileset layers:

• Mode (tile shape), then add new options ("offset square" and "hexagon")
• Cell size
• Y sort and tile origin
• Collision and occluder related properties (moved to their respective tilset layers, see below)
• Cell clip UV (while it does not seem doing something, it is apparently useful for tilsets with filtered textures)

Remove:

• Compatibility mode
• Centered texture (not sure for what it is useful for)
• Custom transform (Replaced by a skew parameter for all modes)
• Half offset = replaced by new "offset square" and "hexagon" tile modes.

The rotation, translation, etc... of individual tiles is now handled inside the tileset, with the possibility to create "alternative versions" of each tile

I plan to add dragable handles to increase/decrease the size of the working area, similar to what LEd implements. It should make it easier to work with the bucket fill for example.

Tilemap editor

With this proposal, the two editors get merged at the bottom. Consequently a switch allows switching between the tilemap and the tileset editor.
In the tilemap editor, the common tools to edit tilemaps are present (paint, rectangle, bucket fill, etc...) in a toolbar.
With possibly some tool-specific options in the toolbar too.

Proposals:

• Add the possibility to select multiple tiles at the same time in the bottom panel, to paint a pattern,
• With the "use random tiles" option, instead of painting the pattern, the tool used randomly choose tiles out of the selected ones,
• When selecting a tile, a panel on the right appears where you can select alternative tiles,
• You can either paint "tiles", "terrains" or "scenes". Once configured correctly, terrains are basically acting like autotiles.

The scenes tabs is missing on the picture, but the idea would be to have a list of scenes to paint as if they were tiles.

The tileset editor

With a button on the top right of the tileset editor, you can open the tileset resouce in the inspector.
This allow modifying properties global to the tileset (tile mode, cell size, etc...).

The source panel

The source tab in the bottom tilset editor simply allows to use textures in the tilset. For each source, you have two properties:

• Offset: offset at the origin of the texture,
• Separation: space between each tile in the texture.
  No need to choose a tile size, this is defined by the tileset's size property.

Possibly, this panel might be also used to:

• remove some unused tiles from each source,
• create some alternative tiles for each tile, by potentially rotating or flipping them.

The tileset layers

The new tileset editor introduces the concept of Tileset Layers. A tileset layer is simply a way to add a set of properties assigned to each tile.
All tileset layers are optionally added to a tileset, each added layer provides a single feature to the tileset. For example, adding a "Tilset collision layer" to a tileset allows it to handle collisions.
Occlusion or navigation have also their dedicated tileset layers.

Tileset layers are global to the whole tileset resource, whatever the source image you use, the tileset layers are the same.

Tileset layer properties are edited in a dedicated tab in the Tileset tileset editor. There, you can edit a set of properties global to the whole layer, and add or remove layers. This is an example where the Terrain layer would be edited:

Here follows the list of possible tileset layers.

Collision layer

Info:

Handle collisions for one type of physic objects

Limited to 1 layer for now, but possibly we could add more, for each type of phisycal material to handle (like "water" only slowing down the player while "wall" would block them)

Layer properties:

• is area (?)
• collision mask
• collision layer
• friction
• bounce
• use kinematic
  etc...

Tile properties for this layer:

• A shape

Occlusion layer

Info:

Handle occlusion for one light layer.

Limited to 1 layer for now, but possibly we could add more if it is uselful ?

Layer properties:

• layer

Tile properties for this layer:

• A shape

Navigation layer

Info:

Handles navigation.

Limited to 1 layer for now, but possibly we could add more if it is uselful ?

Layer properties:
None

Tile properties for this layer:

• A shape

Probability layer

Info:

Allow assigning probabilities to tiles when they are picked randomly to be placed.
This is used either when using the "select random tiles" options or when tiles are automatically picked by the terrain painting tools.
When several tiles are possible to be placed, the higher the probability value, the higher the chances for this tile to be picked.

Limited to 1 layer.

Layer properties:
None

Tile properties for this layer:

• A float value

Z-Index layer

Info:

Allow assigning a z-index to tiles.

Limited to 1 layer.

Layer properties:
None

Tile properties for this layer:

• An integer value

Terrain layers (several types of layers: 2-edges, 2-corners, 3x3, or even special patterns for half-offset and hexagons)

Info:

This layer allows to create autotiles. A set of terrain types (water, sand and grass for example) are needed, then applied to part of tiles.
This would work like what Tiled does, and is very similar to bitmaps we have now.

All tiles marked of a given terrain then might be picked by the corresponding painted terrain in the tilemap painting mode.

While the previous system handled autotiles separately, now all tiles can take part in autotiling. Also, the terrain thing allows mixing different autotiles.

Limited to 1 layer per type of autotiling (usually you don't have to mix them but it might happen).

Layer properties:
A set of terrain types, needing each:

• A name
• An icon (this likely shoud be picked automatically by selecting the tile with the highest amount of corresponding terrains)
• A color -> this is needed to identify the terrain on the tileset

Tile properties for this layer:

• A pattern identifying which part of the tile are of which terrain.

Metadata layers

Info:

Allow assigning custom metadata to tiles.

Unlimited amount of layers.

Layer properties:

• Type of the metadata

Tile properties for this layer:

• Value of the metadata

The scene tabs

In the tileset editor, you can also define a set of scenes to be used as tiles. For consistency, those scenes act as normal tiles, so both a scene and a normal tile can't be present on the same place at the same time. You need two tilemaps for stacking a scene on a normal tile. There, you can also provide an offset to position your scene correctly.

Even if the mockup does not display it, I hope to be able to have a preview for each scene.

Editing tile's properties

As you can see from the pictures above, each layer has its own dedicated way of editing the tiles properties.
The common approach is to have a value selection on a left panel (with the possibility to save favorite values), then paint this value on the tileset.
Only the terrain editor will likely add the possibility to paint directly with autotiles sub-tiles, it would be annoying to have to choose a shape for the whole tile everytime.

---

Personal notes on eventual use cases to support:

• Improvement to tilemap editor with 3x3 autotile bitmask godot#31003
• Special TileMap edge mode for autotiles #310

[KoBeWi]

One of the most common requests I've seen for TileMaps is an ability to have "scene tiles", to allow instancing game objects by painting tiles. Sure, this is possible with the Custom int layer and a script that will instance the nodes based on the value, but a built-in support could allow for object previews, i.e. when you paint a scene-tile, the scene could be instanced in the editor as a preview (similar to what drag and dropping on viewport does). This makes it easier to place objects and it's something difficult to achieve with a script.

I mentioned it in my old proposal.

[groud]

One of the most common requests I've seen for TileMaps is an ability to have "scene tiles", to allow instancing game objects by painting tiles. Sure, this is possible with the Custom int layer and a script that will instance the nodes based on the value, but a built-in support could allow for object previews, i.e. when you paint a scene-tile, the scene could be instanced in the editor as a preview (similar to what drag and dropping on viewport does). This makes it easier to place objects and it's something difficult to achieve with a script.

Ah yes, this likely could be simply achieved by adding a new tab in the tilemap editor mode. user could simply drag & drop scenes in this tabs to paint scenes with it. I'll add it to the proposal.

[chucklepie]

Here's my input for the proposal:

1. There needs to be a better way to add collision (or occlusion/navigation) polygons. At the minute if you have 50 tiles you have to create 50 polygons by hand.

2. Collisions on a tilemap are just on the tilemap, so your entire map is just 1. If you want a per tile mask this cannot be done. You create collision polygons per tileset tile so it must be possible (with the caveat of a performance hit obviously) to provide a collision mask for any tiles, e.g. keep the 'tilemap' but make each tile inherit it with the ability to override.

3. Creating multiple layers with multiple tilemaps is really a hack, there should be layers (which is how almost all external tilemap editors work) then there will be a shared tileset, shared tile sizes and data, shared positions and more importantly a much simpler means of integrating the layers in code.

[groud]

There needs to be a better way to add collision (or occlusion/navigation) polygons. At the minute if you have 50 tiles you have to create 50 polygons by hand.

The proposal addresses this. You define the polygon on the left of the tileset, then you paint this collision shape over the tiles directly in the tileset. It is similar to what RPGmaker does, but you have more control on the shapes you might use.

Collisions on a tilemap are just on the tilemap, so your entire map is just 1. If you want a per tile mask this cannot be done. You create collision polygons per tileset tile so it must be possible (with the caveat of a performance hit obviously) to provide a collision mask for any tiles, e.g. keep the 'tilemap' but make each tile inherit it with the ability to override.

The proposal suggests that it might be possible, maybe not in a first version (let's see), to add several collision layers to a tileset. Each layer would then allow you to have different collision properties (including masks, friction value, etc...).

Creating multiple layers with multiple tilemaps is really a hack, there should be layers (which is how almost all external tilemap editors work) then there will be a shared tileset, shared tile sizes and data, shared positions and more importantly a much simpler means of integrating the layers in code.

Most of the properties tilemaps handle are being moved to the tileset resouce, which is easily shared between tilemap nodes. Consequently, this will be a lot easier to manage.
I kind of disagree on the needs for tilemap layers. Multiple tilemap nodes are ok IMHO. With the proposal, they will simply need almost no setup (only setting the tileset resource), so they don't need much more feature than Node2Ds do.

[NathanLovato]

Great proposal, it seems to address every key issue from the existing setup. You seem to have thought about a lot of details.

I don't see anything that would be off. Can't comment on the UX's details either without actually using the tool directly. But what matters is that the overall idea is coherent and addresses the users' problems.

[chucklepie]

If settings are being made simpler and you don't want to go down the layer route, maybe what is needed is an ability to copy settings from one tilemap to another so they are always in sync, as how multiple layers would automatically be?

I guess this won't hold much sway, but in a tile editor I use it supports multiple 'layer' images per tile (e.g. background, foreground1, foreground2, etc) and that made it really easy on a per tile basis to layer foreground/background/etc tiles on top of each other without need for multiple layers/maps/tiles or resorting to static bodies. The use cases for this is if you want to merge multiple images together in any order, e.g. you have a tile and want to have dirt, snow, status effects, damage, etc. You then simply call a method to enable/disable a tile layer, e.g. set_cellv(5,Cell.FG2, true) to enable the second image associated with the tile.

I think maybe the problem with the tilemap currently and stops it being enhanced is it's a very basic format with a long value per cell holding it's position and id. This means there's a direct correlation between bytes and tiles/locations. In other tilemaps I've used, each long value can be a pointer to another struct so things like tile extensions can easily be made.

[groud]

If settings are being made simpler and you don't want to go down the layer route, maybe what is needed is an ability to copy settings from one tilemap to another so they are always in sync, as how multiple layers would automatically be?

Well, as they can share the same tileset resource, modifying one tileset resource will modify it for all the tilemap nodes sharing this resource.

I guess this won't hold much sway, but in a tile editor I use it supports multiple 'layer' images per tile (e.g. background, foreground1, foreground2, etc) and that made it really easy on a per tile basis to layer foreground/background/etc tiles on top of each other without need for multiple layers/maps/tiles or resorting to static bodies.

I think stacking a tilemap node on top of another one will work with this use case. By simply changing the tile displayed on top will (or removing it), you can achieve such result.

But in any case, with custom metadata layers, you will be able to do almost anything you want in a procedural way.

[ghost]

Will they be any removed property or method in the new Tilemap relative to the current Tilemap?

-If yes, would you please name all of them, or at least confirm that get_used_cells() and get_cell_size() won't be removed?

Thanks.
-TechnoArt Studio Team.

[groud]

Will they be any removed property or method in the new Tilemap relative to the current Tilemap?

I don't know yet, but I'll try to keep compatibility as much as possible.

[Wavesonics]

Overall this looks really great! Especially the Scenes as tiles, that will go a long way to making this usable as a level editor!

Being able to have tiles with different collision masks would be (from my experience) an extremely important feature to have. Without that we'll have to resort to stacking tile maps on top of each other again, which so many of these features are working to get away from it seems.

Everyone can tell me I'm wrong if they think so, but I think that stacking tile maps should be for pretty special cases. We should be able to do most things within a single tile map.

The last thing I can think of is what @chucklepie was talking about, having multiple layers would cover another case that would otherwise force us to stack maps. The use case that comes to mind is:
layer1 -> painting ground tiles (z index 0)
layer2 -> painting tree tiles (z index 2)

If you want your characters (z index 1) to be able to walk under the trees, you can't just have a combined ground/tree tile.

Anyway, this proposal is looking really great!

[chucklepie]

Hello again. If you're also making api changes not just cosmetic I think how people interact with tiles should be thought about. For example, if you want to get the tile a collision occurs on (pretty much what everyone wants), there is no simple means, you have to use this code, which seems overly complex and long-winded for your average user (I had to do a lot of searching/asking to figure this out):

var tile_pos = collision.collider.world_to_map(position)
tile_pos -= collision.normal
var tile_id = collision.collider.get_cellv(tile_pos)

It should really be a case of the tilemap having a good api, e.g.

var tile_id=map.get_tile_from_collision(collision)

etc.

[groud]

The last thing I can think of is what @chucklepie was talking about, having multiple layers would cover another case that would otherwise force us to stack maps. The use case that comes to mind is:
layer1 -> painting ground tiles (z index 0)
layer2 -> painting tree tiles (z index 2)

Using stacked tilemaps is the way to go for that. But with this proposal it should not be cumbersome anymore, as tilemaps sharing a same tileset will share most of their properties (they will likely 99% be like layers in fact).

If you're also making api changes not just cosmetic I think how people interact with tiles should be thought about

I have not checked the API yet, I'll see while implementing everything if I can improve some areas of the API.
But yes, for now I'd like to focus this first proposal on the editor interface first.

[MrDudeIII]

How would your restructuring of the tile size away from the tilemap and into individual tilesets interact with oversize tiles (e.g., If I have a 64x64 tree tile that needs to be part of a 32x32 tileset)? This is especially important for isometric/military perspective tilesets in my experience, so how would that functionality be replicated?

[groud]

How would your restructuring of the tile size away from the tilemap and into individual tilesets interact with oversize tiles (e.g., If I have a 64x64 tree tile that needs to be part of a 32x32 tileset)?

I would say that, for square-shaped tiles, such tree would be split into several ones. But this is not a problem as, in the tilemap editor, you would be able to select multiple tiles at once.

Regarding the case for isometric tile, that can not be used. So the solution would be here to move the oversized tiles to another texture (either a single texture for each element, or an atlas with all other items with the same size). I am not sure if it is clear in the proposal (maybe the source panel has to be reworked), but each texture source can have a different tile size, which would allow for tiles bigger than the configured tile shape.

[starry-abyss]

Great start, here are some suggestions:

In the tileset editor, you can also define a set of scenes to be used as tiles. For consistency, those scenes act as normal tiles, so both a scene and a normal tile can't be present on the same place at the same time. You need two tilemaps for stacking a scene on a normal tile. There, you can also provide an offset to position your scene correctly.

Snapping to tiles is good, but how about non-snapping scenes? Like if I wanted 5 scenes in one tile at once, would I have to use slow drag & drop workflow again?

I mean, if those scenes are e.g. trees or creatures (for grid-based ground but not grid-based gameplay), and not just passive walls.

This layer allows to create autotiles. A set of terrain types (water, sand and grass for example) are needed, then applied to part of tiles.

Does auto-tiling also apply to scenes, which might be, for example, high 2.5D walls in isometric view? Or are those walls going to be supported as regular tiles?

Also not sure if it's supported already, but it would be useful to have access to the auto-tiling functionality from scripts - if I wanted to set up tilesets in editor, but create tilemaps at runtime from procgen or from player, or apply some changes from gameplay.

A set of terrain types, needing each:
A name
An icon (this likely shoud be picked automatically by selecting the tile with the highest amount of corresponding terrains)
A color -> this is needed to identify the terrain on the tileset

Multi-coloring sounds like an eye-killer to me. How about just printing the name + bounding box (+ maybe the icon) over tileset (IIRC it's already like this), and where it doesn't fit, using just the icon?

[groud]

Snapping to tiles is good, but how about non-snapping scenes? Like if I wanted 5 scenes in one tile at once, would I have to use slow drag & drop workflow again?

Yes, drawing scenes randomly positioned on top of a tilemap is out of the scope of the tilemap editor, and thus of this proposal.
That being said, we had an idea about the possibillity to implement something to "paint" scenes at custom positions, but that's not what tilemaps are for.

Does auto-tiling also apply to scenes, which might be, for example, high 2.5D walls in isometric view? Or are those walls going to be supported as regular tiles?

No, not in this proposal. But I think this is so corner case that it could be handled via scripts.

Also not sure if it's supported already, but it would be useful to have access to the auto-tiling functionality from scripts - if I wanted to set up tilesets in editor, but create tilemaps at runtime from procgen or from player, or apply some changes from gameplay.

Yes, that would be a good idea. I'll probably have to implement a few function to paint autotiles on tilemaps, I suppose I could easily expose this to users.

Multi-coloring sounds like an eye-killer to me. How about just printing the name + bounding box (+ maybe the icon) over tileset (IIRC it's already like this), and where it doesn't fit, using just the icon?

I think you misunderstood what this is for. Basically terrains would work like the bitmasks we have now, but with several bitmasks at the same time. Right now, bitmask are drawn in the autotile editor in red, but when settings terrains, we will need different color for each terrain. Thus, you can configure this color there. Off course this color wont be displayed on the tilemap, it's only used in the tileset configuration.

[KoBeWi]

Snapping to tiles is good, but how about non-snapping scenes? Like if I wanted 5 scenes in one tile at once, would I have to use slow drag & drop workflow again?

You could create a scene containing instances of these 5 scenes and make it a tile.

[starry-abyss]

@KoBeWi Thanks, but I didn't mean Civilization-like squads. I meant free placement of any amount of any scene type anywhere. 5 locked inside a tile was just an example.

[chucklepie]

Hello, one thing I didn't realise you could not do as I've just tried inside a 'tool' script and failed is persist your changes to set_cell() and other tilemap editing features. What I mean is, when you create a 'tool' I was expecting setting cells to just persist the data back to the tilemap.

The reason for this is if you want to procedurally create tilemaps or simply use a tool to help you manage tilemaps, the only way currently is to kind of hack an external application and write a raw tscn file.

Given the Godot editor does all this, why not expose some of this functionality?

[AttackButton]

Would it be possible to have a way to automatically create collisions for slopes divided into several tiles?

Maybe the editor could have some standard predefined slope angles, like 10, 20, 30, 45 and 60 degrees.

For example, creating two tiles of 16x16 with a slope of 30 degrees angle automatically divided between the two tiles. Or four tiles of 32x32 with a 10 degrees slope angle, starting at the first/last tile on the left/right and ending at the fourth/first one.

[nikhilCad]

Please also look at #648 especially its last comment about keyboard hotkeys to add square collision boxes

[groud]

Hello, one thing I didn't realise you could not do as I've just tried inside a 'tool' script and failed is persist your changes to set_cell() and other tilemap editing features. What I mean is, when you create a 'tool' I was expecting setting cells to just persist the data back to the tilemap.

I am surprised this does not work. I will have a look.

Would it be possible to have a way to automatically create collisions for slopes divided into several tiles?

I think this use case is a little bit too specific to bother implementing a way to define a collision on several tiles at the same time. It should not be that complex to draw slopes if you have snapping on the shape drawing.
However, I agree it could become annoying when you have an object spread on multiple tiles (like the stomp on the tilsets in the proposal). I'll give it some thinking but this is not a priority to be honest.

Please also look at #648 especially its last comment about keyboard hotkeys to add square collision boxes

There will be no need for such short with this proposal. You will basically click on the "square shape button" then paint, with the left click, this square all over your tileset.

[itsjavi]

Fanastic work! I can't wait to try it. I have some feedback about all what I've read here.

Tilemap Layers
Regarding using "drawing layers" or delegate that to multiple tilemap nodes I have mixed feelings.

From one side, I want to have the freedom to have a layered tilemap with the control that nodes offer (scripting, etc.)
and from the other side when you have 100+ scenes maintaining all tilemap layers can become a nightmare.

Having a "drawing layer" feature in the tilemap editor is not a bad thing IMHO and yet we will have the option to use multiple tilemap nodes as layers. So it will be the developer's choice what to use.

The ability to combine different tiles and create a "composite tile" (e.g. solid ground + dirt, ground + snow, and other effects...) would be very helpful in terms of maintainability and reusability.

I don't know how complicated is to do that, but if you have the chance why not.

Brushes?
It's not clear for me, but can we select a group of tiles and create a brush out of it? e.g. a house, a tree that has 3 tiles, etc.
so we can easily paint them. AFAIR. GameMaker and Unity have this feature. It helps drawing repetitive groups of tiles.

Extensibility
This refactoring, does it pave the way to be able to write plugins for the tilemap editor? Will the API be available programatically?

Metadata Layers
Can you explain a bit more about the metadata layers? Will that be available programatically? For example, If player collides with a tile, to know the metadata of that tile.

Documentation
Finally, better documentation about how to use the Collision and Bitmask layers would be very helpful. It was very hard to learn how to make it work, I had to dig in google and lots of tutorials. I think Godot docs should explain this (and all layers) a bit better with more examples.

Thank you!

[KoBeWi]

I see two advantages of having layers:

1. they are easier to optimize than multiple TileMaps, because you have everything in one node (although maybe it's irrelevant)
2. we could have a shortcut to switch between layers, while you have to click the TileMaps

I think that having TileMap layers (instead of needing to stack TileMaps) allows for better integration between them and more seamless/convenient editing. When creating a level you almost always have to overlap some tiles (at least if you want it to look good), which means that single TileMap would not be enough in 90% cases.

[chucklepie]

Regarding last comment on layers. This is why I and a message above have suggested composite tiles. If you have 7 or 8 states for a tile or simply want to merge tile images (eg snow, etc) you would have to create about 20 tile maps. BTW, I've been asking many times to add metadata to tiles so you can do stuff like per tile score, astar heuristic for terrain. Etc and it got rejected, so good too see its in now, well I hope its in from what I read 😁

…

On Thu, 5 Nov 2020, 10:26 Tomek, ***@***.***> wrote: I see two advantages of having layers: 1. they are easier to optimize than multiple TileMaps, because you have everything in one node (although maybe it's irrelevant) 2. we could have a shortcut to switch between layers, while you have to click the TileMaps I think that having TileMap layers (instead of needing to stack TileMaps) allows for better integration between them and more seamless/convenient editing. When creating a level you almost always have to overlap some tiles (at least if you want it to look good), which means that single TileMap would not be enough in 90% cases. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1769 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADCERRPU3NQK2BRIUX6TNQ3SOJ4WJANCNFSM4TJC3AFA> .

[TackerTacker]

Here is a video of me creating what's called "brushes" in Construct3. It's their UI for creating autotiles.
I really like how it shows a minimalistic preview of the expected tiles. The tile selection is also nice and easy with the split view.
In Godot 3 there is only a drop down telling you some kind of name of the used autotile algorithm where the user has no clue what tiles are needed.

One more general thing about this proposal, I thought this update was about user experience ( UX ) and a big part of that is a good UI, but there is not much discussion about the UI at all. I'm not an expert at all but the UI right now is just new tabs for every feature, which doesn't sound like a good user experience to me. Is there someone helping with UX/UI who's experienced in that field? If not maybe it would be good to actively ask for help in that area on Twitter and reddit, or is it too early to get a UI/UX designer on board?! Like I said, I'm not an expert either.

[groud]

The ability to combine different tiles and create a "composite tile" (e.g. solid ground + dirt, ground + snow, and other effects...) would be very helpful in terms of maintainability and reusability.
I don't know how complicated is to do that, but if you have the chance why not.

The problem is that it makes setting up things a lot harder (needing to set picture for each tile), while stacking two tilemaps is quite easy to do. So IMHO, it's not worth implementing a "graphic tilset layer".

Brushes?
It's not clear for me, but can we select a group of tiles and create a brush out of it? e.g. a house, a tree that has 3 tiles, etc.
so we can easily paint them. AFAIR. GameMaker and Unity have this feature. It helps drawing repetitive groups of tiles.

Yes, this is planned to be supported.

This refactoring, does it pave the way to be able to write plugins for the tilemap editor? Will the API be available programatically?

We will see depending on what people need, but yes, it should be possible to create advanced tools for that I suppose.

Can you explain a bit more about the metadata layers? Will that be available programatically? For example, If player collides with a tile, to know the metadata of that tile.

For example, you have tiles that would inflict damages to the player. So you could have a "damage" metadata tileset layer that you can paint over tiles (the value would be 0 or 1 depending on whether or not the tile inflicts damage). And then, when getting a tile from the tilemap, you could get this value (from collisions, or any other way), and thus deal some damage to the user.

Finally, better documentation about how to use the Collision and Bitmask layers would be very helpful. It was very hard to learn how to make it work, I had to dig in google and lots of tutorials. I think Godot docs should explain this (and all layers) a bit better with more examples.

This will come when the refactor is done.

I see two advantages of having layers:
they are easier to optimize than multiple TileMaps, because you have everything in one node (although maybe it's irrelevant)
we could have a shortcut to switch between layers, while you have to click the TileMaps

I don't think the optimization is relevant, splitting a tilemap into 3 or 4 nodes is not that computationally expensive.
The shortcut to switch between tilemaps be implemented anyway (likely by switching between the tilemaps that are all children of the same node or something like that, basically switching between siblings). I think I will even implement a way to lower to opacity of not selected tilemaps too, that would help for that.

If you have 7 or 8 states for a tile or simply
want to merge tile images (eg snow, etc) you would have to create about 20
tile maps.

There's really little use cases where you would have to stack up to 7 or 8 images on top of each other. You could simply change the tile on the top tilemap to change the state, you don't need 20 tilemaps to do that.

[KoBeWi]

A lot of users are going to reuse the same TileSet in a lot of places and removing the current one would be annoying.

You don't need to remove it. The tileset can be replaced or picked all the same whether the field is empty or not. The only differemce is that you need to right-click it instead of let-clicking.

[groud]

You don't need to remove it. The tileset can be replaced or picked all the same whether the field is empty or not. The only differemce is that you need to right-click it instead of let-clicking.

Ah that's good then. I guess we could create a default TileSet then, though I am not sure how useful that is. I think most of the time you will want to create a TileSet as an independent resource or assign it from the FileSystem dock. It might be annoying to set it up and have to save it as an independent resource later on.

I am not strongly against it though. There's kind of a Blender's default cube vibe behind it but if users would prefer that why not.

[markdibarry]

If I could make one suggestion, I think alternative tiles are great, but I think they could be arranged a little better. In many cases, I'm making an alternative tile map. For example below is the same tile set but a slightly different color to denote a one-way collision. (they continue for awhile off-screen)

The alternative tiles are a little harder to find my way around. Or is another avenue recommended for this workflow?

[groud]

If I could make one suggestion, I think alternative tiles are great, but I think they could be arranged a little better

I guess so. I am open to suggestions for a better layout. Considering that it needs to support bigger tiles too (when you create a tile out of several small ones), and it needs the place for a button to create other alternatives, I could not find a better solution :/

The alternative tiles are a little harder to find my way around. Or is another avenue recommended for this workflow?

I guess that when you have a lot of them, it's likely easier to create another atlas using the same texture.

[KoBeWi]

The alternative tiles are a little harder to find my way around. Or is another avenue recommended for this workflow?

I agree that alternate tiles are difficult to navigate. Another thing is that you can't multiselect them as easily as normal tiles. I avoid them for this reason.

But in your case, instead of making darker tiles, you can put them on a separate tile layer and change layer modulate to darker. You can find layer settings in the inspector.

[markdibarry]

you can put them on a separate tile layer and change layer modulate to darker

That def works for the color, but I don't think you can use layers to handle alternative one-way collision shape or other properties.

I am open to suggestions for a better layout.

Yeah, it definitely seems tough to solve. Maybe alternative set and/or alternative tiles? I'll think about it.

[KoBeWi]

What if the alternate list for a tile was visible only if that tile is selected? And tiles with available alternates could have some tiny icon in a corner or some outline idk.

[markdibarry]

That sounds tricky to implement, but incredibly intuitive and friendly!

[groud]

What if the alternate list for a tile was visible only if that tile is selected? And tiles with available alternates could have some tiny icon in a corner or some outline idk.

The problem is about painting properties on them. This would make it impossible to quickly paint a property on several alternative tiles.

[KoBeWi]

For painting properties it's fine to show all of them, but when drawing on TileMap they could be hidden. Right now it reminds me of the tile list in the old editor.

EDIT:

That def works for the color, but I don't think you can use layers to handle alternative one-way collision shape or other properties.

Actually you can, using _tile_data_runtime_update() method. You need to do it via script though, but you can e.g. disable collisions on a specific layer etc.

[dugramen]

Hello, I was using the new TileMap custom data properties and was having a lot of trouble figuring out how to access that data.
Turns out you have to do something like this

var source_id := $TileMap.get_cell_source_id(layer, cell)
var atlas_coord := $TileMap.get_cell_atlas_coords(layer, cell)
var tile_data := $TileMap.tile_set.get_source(source_id).get_tile_data(atlas_coord)
var custom_data = tile_data.get_custom_data("terrain_tag")

Could you possibly add a new helper method in TileMap directly so you could simply do something like
TileMap.get_cell_tile_data(layer, cell) which returns the TileData object

[KoBeWi]

@dugramen See godotengine/godot#54549

[dugramen]

@dugramen See godotengine/godot#54549

Oh sorry, I didn't see that

[wareya]

I can't figure out how to make true lone tiles with the terrain peering bit system. As far as I can tell, the new autotiling logic can't tell between e.g. "desert tile surrounded by grass on all sides" and "grass tile surrounded by grass on all sides", which means that I would have to manually paint them. If I'm correct that there's no way for it to tell the difference, this is a serious shortcoming, and would prevent the new terrains system from being a workable replacement for the old blob/bitmask system.

Example of something that I want to be able to do (note: uses two autogenerated 255-tile tilesheets):

What happens if I try to do it on master right now (different tileset, would look a little buggy even if it worked as intended, but definitely shouldn't look how it looks here):

It can't tell the difference between sand and grass-surrounded-by-sand and picks randomly. Did I miss something with how tilesets are set up now?

Unrelated: I agree with the above feedback that the new workflow is even more unintuitive than the 3.x autotile bitmask workflow. I will say, though, that it's nice that everything actually has a menu or label or list of some sort. In 3.x there are several things that are completely invisible/opaque. In that particular regard, the UI in master is an improvement.

[groud]

It can't tell the difference between sand and grass-surrounded-by-sand and picks randomly. Did I miss something with how tilesets are set up now?

There are none regarding to the algorithm used, which only relies on connections between the tiles. I think this could indeed been improved.
It requires heavy changes though, for which I sadly won't have the time to work on. So any contribution on this area is welcome.

[groud]

Anyway, I am going to close this proposal now, there's too many topics discussed here and most of the original proposal has been implemented. Please open separate proposals/issues for each suggestion or bug report.

[seocwen]

If this is closed, now, what exactly is the probability of getting other outstanding issues looked at before beta launch? #3967 is a significant one for me, at least. Otherwise I'm more going to be hoping someone makes an imported for the Tiled software.