[4.0] Terrain does not handle tile with no bits set

[derek126]

Godot version

4.0.dev (26facc0)

System information

Windows 10

Issue description

I created a new terrain and setup the bitmasks I think correctly. I placed a single solid dirt tile (highlighted in orange) and I expected it to turn into one of the single dirt tiles (highlighted in green), but instead it was surrounded by more tiles.

When looking at the terrain in the TileMap tab the single dirt tile is not shown in the list of tiles.

I expected this to work like an autotile where if I placed the single dirt tile it would adapt based on surrounding tiles. Not spawn more tiles. Also that a tile with no bits set would be recognized as a tile surrounded by no other tiles.

Steps to reproduce

1. Open the tilemap in the attached project
2. Make sure the TileMap tab is selected at the bottom, then select Dirt under Terrain Set 0
3. Select the first dirt tile (orange) and place it. Notice how 4 more tiles are added and the tile is not turned into the single dirt tile (green)

Minimal reproduction project

TerrainTest.zip

[calebmhartshorn]

Similar issues here with both other terrain modes (Corners and/or Sides).

Additionally, the selected tile in the terrains list seems to effect the issue. Though I can't say what the selected tile would intuitively do in a terrain list? Here's the issues I'm seeing:

• Terrain placement not updating surrounding tiles
• Terrain placement adding extra (frequently nonmatching) tiles around itself as described in this issue
• Terrain placement deleting surrounding tiles
• Terrain placement overriding non-terrain surrounding tiles

[groud]

I created a new terrain and setup the bitmasks I think correctly

You used the wrong terrain mode. You should use the 3x3 mode when you need to update the tiles at the corner of another. The side-only mode only mainly works for "wang tiles" type of setup.

I expected this to work like an autotile where if I placed the single dirt tile it would adapt based on surrounding tiles. Not spawn more tiles. Also that a tile with no bits set would be recognized as a tile surrounded by no other tiles.

This is a limitation of the current approach, that relies on placing a given tile and updating it's surrounding. I am not against adding support for doing what you are suggesting, but it's a lot of work. (That's why I marked the issue as an enhancement)

Select the first dirt tile (orange) and place it. Notice how 4 more tiles are added and the tile is not turned into the single dirt tile (green)

This is thus expected, considering the current approach.

[derek126]

You used the wrong terrain mode. You should use the 3x3 mode when you need to update the tiles at the corner of another. The side-only mode only mainly works for "wang tiles" type of setup.

This setup was only to recreate some of the issues I have had with the terrain system. Single tile (no bitmask) does not work and that other tiles are undesirably created. My original setup looked something like the following

[derek126]

After testing more today I am not sure we will be able to use the terrain system as-is unfortunately. Everything is so much better about tilesets and tilemaps in general (great work!), but for our procedurally generated worlds the unpredictability of added/removed tiles and the inability to have a single tile (players can "mine" and place tiles) it just makes it not a good fit for these kind of worlds.

[SpeCter]

I created a new terrain and setup the bitmasks I think correctly

You used the wrong terrain mode. You should use the 3x3 mode when you need to update the tiles at the corner of another. The side-only mode only mainly works for "wang tiles" type of setup.

I expected this to work like an autotile where if I placed the single dirt tile it would adapt based on surrounding tiles. Not spawn more tiles. Also that a tile with no bits set would be recognized as a tile surrounded by no other tiles.

This is a limitation of the current approach, that relies on placing a given tile and updating it's surrounding. I am not against adding support for doing what you are suggesting, but it's a lot of work. (That's why I marked the issue as an enhancement)

Select the first dirt tile (orange) and place it. Notice how 4 more tiles are added and the tile is not turned into the single dirt tile (green)

This is thus expected, considering the current approach.

Any idea when and if this will get back? Compared to 3.x this feels more like a regression(not the whole thing, which is great but single tileset autotiling) and unfortunately makes it completely unusable for my current projects :(.

[isaacremnant]

Same issue as described in this proposal https://github.com/godotengine/godot-proposals/issues/3875 which IMO should be an issue in this repo as it's a regression on the tileset handling of 3.x. Isolated tiles are useful and required in virtually all tilemaps.

The "center bit" isn't useful for choosing the tile, except when there's only a single one... so it doesn't need to be reimplemented but the special case definitely should to be handled.

[wareya]

which IMO should be an issue in this repo as it's a regression on the tileset handling of 3.x.

I'm not 100% sure it should be posted as a regression issue, since 4.0 is the great compatibility break, but it should definitely be considered a critical blocker. Can proposals be flagged as blockers?

The "center bit" isn't useful for choosing the tile, except when there's only a single one... so it doesn't need to be reimplemented but the special case definitely should to be handled.

I have a hunch that it might be impossible to consistently get the desired behavior here without implementing a center bit.

[Calinou]

Can proposals be flagged as blockers?

No, but I added a 4.0 milestone to make sure it gets acted upon before 4.0 is released. For proposals where it's not certain that we can act upon them before 4.0 is released, I prefer using the 4.x milestone instead.

[stesproject]

Definitely it's not just an enhancement. A top down game can't be created in Godot 4 as for now.

[groud]

I am ok with implementing the center bit again. I agree it is useful in some situations, like @derek126 mining game (tough the performance of the TileMap node might not be enough to support very big worlds), but we should stop the exaggeration now. This is neither a bug, a critical blocker, nor it prevents you from making a top down game... It might some kind of games more complex to create, but anything where procedurally generated worlds are not involved are perfectly feasible.

Anyway, I see there's a lot of demand for it and the current system seems to cause some confusion. So I'll try to work on that on priority if I find the spare time to do so.

[wareya]

It is extremely important to understand that the current system can not be used the way the old system was used, from the perspective of a level designer placing down tiles. Dozens of people (counting here, previous issue threads, and discussions on reddit and discord) have explained that it's unintuitive and causes a lot of unexpected behavior. Yes, you can construct the same arrangements of tiles you used to be able to, but doing very simple single-tile-type tiling, which is by far the most common, is a lot more cumbersome. Autotiling is supposed to reduce the level designer's work, not add to it. People are not exaggerating the issues they have with the current system.

This is neither a bug, a critical blocker, nor it prevents you from making a top down game...

The usability problems being discussed here are not a joke. I do not believe that 4.0 can ship with the current system. If it did, fixing it after 4.0 would almost certainly be a hard compatibility break with 4.0, or avoiding a compatibility break would severely complicate the final system. This is what I mean when I say that it should be considered a critical blocker.

[stesproject]

It is extremely important to understand that the current system can not be used the way the old system was used, from the perspective of a level designer placing down tiles. Dozens of people (counting here, previous issue threads, and discussions on reddit and discord) have explained that it's unintuitive and causes a lot of unexpected behavior. Yes, you can construct the same arrangements of tiles you used to be able to, but doing very simple single-tile-type tiling, which is by far the most common, is a lot more cumbersome. Autotiling is supposed to reduce the level designer's work, not add to it. People are not exaggerating the issues they have with the current system.

This is neither a bug, a critical blocker, nor it prevents you from making a top down game...

The usability problems being discussed here are not a joke. I do not believe that 4.0 can ship with the current system. If it did, fixing it after 4.0 would almost certainly be a hard compatibility break with 4.0, or avoiding a compatibility break would severely complicate the final system. This is what I mean when I say that it should be considered a critical blocker.

I agree. I come from Rpg Maker and Unity and now, in the last month, I was giving a chance to Godot. I didn't like the Tilemap system in Godot 3, cause the annoying way you have to set collisions, so I was very happy when I saw great improvements to the Tilemap system in Godot 4. It's better and more intuitive, for sure, but I cannot work with it if I want to place a single tile and instead it places X more tiles around it. I spent two days to figure out how to make it to then find out there were several open issues about it. There are a lot of people arguing about this being a serious problem. Surely I won't move to Godot if the current Tilemap system doesn't change and not because it just makes working on my game harder (that it shouldn't happen), but because I cannot work at all as for now. This is me struggling to create a 1 tile large river:

https://user-images.githubusercontent.com/32966173/154036642-39e1cd92-d8de-4f88-b404-81d08f32cd7b.mp4

[MewPurPur]

I made a small sketch of perhaps a 2nd terrains mode (that could also be corners and/or sides) that resembles the old autotile but uses the new terrains. If it's implemented as such, it wouldn't break compat, just the whole terrain set would need to be one way or the other. I know I'm oversimplifying and surely demanding too much, too, it's just a draft to be stripped down or scrapped. (If I were developing tilemaps, I'd probably internally scream at this) edit to clarify it a little: Presumably there are only 5 terrains set so far, that's why I'm calling the old ignore bit that. Also, in the bit selection, the very thick outlines are selected stuff and the very light outlines are ones that can't be selected (2 because that's Self, and 6+ because there aren't terrains for those yet)

Idea:

• In Terrain Autotile, tiles are organized in terrains themselves, and you draw by choosing which terrain you wanna draw. Inherent terrain is displayed as a center bit. Let's say you want to draw River; you pick River terrain, not a configuration of Grass+River.
• Tiles check to the sides and/or corners for the connections you specify: Void, Self, Other.
• Void means it checks for tiles that aren't from this terrain set, or that aren't placed. It's on by default. (old empty bit)
• Self means it checks for other tiles from the same terrain (old red bit). Self and Void are essentially 3.x Autotile and would be the most commonly used, so they are the most accessible.
• Other lets you choose from all the other terrains the tile can connect with. This enables custom transitions: for example, if your Grass tile's peering bit has checked the terrains for Sand and Gravel, that tile will handle Grass-Sand and Grass-Gravel transitions. But selecting multiple terrains also forces a limitation of 32 terrains per terrain set... the old system would do too, in this case the simple workaround would be to have two duplicate tiles, just with different terrains on the same peering bit.
• If nothing is checked, it gets the custom behavior of an ignore bit (as if everything is checked) as otherwise it wouldn't make sense.
• The options chosen dictate how those peering bits display in the editor.
• Once you start placing tiles, if you don't have an available tile for a configuration, a default missing texture is placed on the map, and you need to work it out in the resource.
• To make it crystal clear, this can't do everything the terrain system can, and the terrain system can't do everything this one can.

This is straying away from the original discussion and I'm not claiming to have come up with a good system, but I'll open a proposal if needed.

[stesproject]

I'm of the idea that the things that already work and no one complains about have to be kept as they already are. The old bitmask system was perfect. Why has been changed? There were someone who asked for it?

@groud I don't want to annoy you because I really appreciate what you did with the new tilemap system, I think it's amazing, I'm just sharing my thoughts and my direct experience with it. You said that this new system doesn't prevent someone to make a top down game, it just make the process complex... Can you please explain how can we achieve what we want? Place single tiles and make them behave as... autotiles (check my video above). Maybe we're really exaggerating, but because we're not fully understanding this new system?

[groud]

I'm of the idea that the things that already work and no one complains about have to be kept as they already are.

People complained about it, as it was limited (as it would not allow mixing up terrains) and a little bit confusing at setup. We did not decide to change that for the sake of it. Also, the new implementation can't work the same way it used to, setting tiles is different from 3.x and had to be rewritten anyway. It's not like we could have kept it the exact way is was.

No, as it is right now, the new system cannot allow you to create single-tile wide terrains easily. It works by setting up a tile, then updating the surrounding tiles. That means that for a 1 cell wide river, you need to select the specific tiles in the list.

Anyways, I started working on it but things takes time as implementing that is fairly complex.

[MewPurPur]

I'm making a 2D platformer game, rather than a top-down where tiles are more like a tool to paint the scene. It's really really important that tiles are exactly where I place them.

Just trying to highlight why I believe it's important to have inherent terrains, not having them is unworkable for a whole genre.

[isaacremnant]

As @MewPurPur said - I've been trying to use the new 4.0 system to build levels with 1-wide features as illustrated here... but it's way too painful of a task. Nobody's going to manually select tiles to draw features, especially since the 3.x system worked just fine in that respect.

I don't want the tilemap to guess what I'm painting, I want tiles to exist where I click and match exact or closest bitmasks. Automatically creating neighbors is just counterintuitive. It's fine for broad strokes sure, but not for exact and voluntary map creation.

[Proggle]

I agree. I come from Rpg Maker and Unity and now, in the last month, I was giving a chance to Godot. I didn't like the Tilemap system in Godot 3, cause the annoying way you have to set collisions, so I was very happy when I saw great improvements to the Tilemap system in Godot 4. It's better and more intuitive, for sure, but I cannot work with it if I want to place a single tile and instead it places X more tiles around it. I spent two days to figure out how to make it to then find out there were several open issues about it. There are a lot of people arguing about this being a serious problem. Surely I won't move to Godot if the current Tilemap system doesn't change and not because it just makes working on my game harder (that it shouldn't happen), but because I cannot work at all as for now. This is me struggling to create a 1 tile large river:

Godot.4.-.Tilemap.Terrains.mp4

I had similar issues and came to github to ask about it. As is, I was very confused on what was happening, and there isn't full documentation for this system yet.

I feel like rpg maker is kind of the autotile system to beat in terms of baseline 'ability to import a new image and start slapping down tiles willy-nilly'. It's (admittedly) very constrained, but there's also been 20+ years of iteration focusing on ease of use that we should learn from - if we're making a more powerful and more flexible system, it should still be capable of doing the simplest stuff quickly and easily.

[atollk]

Like others, I have found this issue from Google + being confused by the current state of the tile system in 4.0. From what I've read, there is notable criticism of the current system and the wish to change it. I interpret @groud 's comment as that this criticism has been taking into account and some change is going to be implemented before 4.0 becomes stable.

Is there some public design / planning document on what those changes are supposed to look like? It seems to me that there have been multiple different proposals on how the tile system could be improved but none of them has been marked as "Okay, this is what we're going to have in 4.0". Considering that there seems to be strong community interest in this particular feature, it would seem odd to me if implementation starts without having some form of public discussion to decide on a satisfactory outcome first.

[Calinou]

Is there some public design / planning document on what those changes are supposed to look like? It seems to me that there have been multiple different proposals on how the tile system could be improved but none of them has been marked as "Okay, this is what we're going to have in 4.0".

We generally don't mark proposals as formally approved (unless they were discussed in a proposal review meeting, which happens every Thursday on the Godot contributors chat). Anyone is free to implement them, but the pull request may be rejected if the technical implementation isn't up to spec (or if the feature itself is rejected).

This issue has a 4.0 milestone, so it is aimed to be resolved for 4.0, but no guarantees are made.

[seocwen]

I've been trying to follow the discussions about the new tilesets and tilemaps but it's rather fragmented right now. It might do to have a specific tilesets tag or something considering the number of issues.

Today was my first time trying to work with the terrains feature. I am also of the opinion that the current system is not handling autotiles well. I don't see what use case is being solved by this implementation. Who would want it to just spawn random stuff all over the place? The current system is more like some wave-function-collapse magic wand. It looks like something you'd use for procedural generation rather than level editing.

Re-implementing the 3.0 auto-tiler within the new framework would be better, but that wasn't ideal either. The user should be able to draw one tile at time and get a predictable result.

I suggest implementing two auto-tile pens:

• One would work similar to 3.0, by merging adjacent tiles as the user draws them. I argue tiles should only merge when the user clicks and drags their cursor over the edge between them, according the appropriate bitmask. That allows the user the ability to preserve internal edges within a shape, if they want them.
• Another, pen would allow users to draw a new "blob" of terrain that only merges tiles drawn since they last started clicking and dragging to paint--all other terrain tiles would change to treat the new blob as though it were not a match, generating edges around it. This would allow users to add edges back in if they want them, and then use the other tool to merge tile blobs together.

I think that would be a relatively painless way to allow for single tile details without having to painfully place things tile by tile.

Incidentally, I think that as per issue #893, autotiles should implement flipping and transposing, which also relates to #3967. I am again noting that the the tilemap issues are becoming increasingly difficult to follow as a lot of interrelated issues currently have their own threads.

[wareya]

I proposed a compromise design between the new and old systems in https://github.com/godotengine/godot-proposals/issues/3875 (including specific UI/workflow/algorithm changes), but it was closed. Re-linking it here for visibility and to make the discussion less fragmented.

Merely re-adding a center bit is not enough. The tile placement algorithm has to be changed.

[groud]

Just to make it clear what I am working on right now:

• I am integrating back a center bit,
• As the first elements of the list of tiles associated to a terrain, I'll add two tools, a "path" one and a "connect" one. Both will first try to modify only the tiles you are moving your mouse on (though it might modify the surrounding ones if it needs to, unless we make it a settings I am not sure).
• The path tool will automatically connect the terrain you are painting to the other tiles you have painted in the same mouse stroke (so it will change the edge terrain bit accordingly). This will basically allow creating paths.
• The connect tool will connect (once again by setting the corresponding edge terrain accordingly) the painted tiles to the surrounding ones that share the same center bit. This will allow filling areas with a given terrain, while still keeping the possibility to only paint the center of a tile. If I am not mistaking, this is close to the behavior we had in 3.x..

Both of those tools will likely be exposed in the TileMap API, for procedural stuff.

As a side note, I won't have the time to do work more than what's described here. My dayjob do not leave me enough time to work on such big refactors anymore. But any contribution baked by a solid implementation proposal would be welcome (note that this part of the code deals with quite complex algorithms, so describing how things would work from the user perspective would not be enough. The internals need to be discussed too)

[atollk]

But any contribution baked by a solid implementation proposal would be welcome (note that this part of the code deals with quite complex algorithms, so describing how things would work from the user perspective would not be enough. The internals need to be discussed too)

@groud Considering that the Godot code base is pretty big, do you have some pointers to what the relevant pieces might be?

[groud]

Alright, I made https://github.com/godotengine/godot/pull/61809, if anyone wants to try it.