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

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)

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.

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.

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.

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.

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

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.

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.

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 😦.

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

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.

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.

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

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.

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.

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.

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.

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