New TileSet terrains system should reintroduce "center" bit/terrain type

[wareya]

Describe the project you are working on

Multiple 2d games.

Describe the problem or limitation you are having in your project

As noted in #1769 (comment) and #1769 (comment), the current terrains neighbor/peer system doesn't have a concept of "tiles having an inherent terrain", and instead seems to purely work on a wavefunction-collapse-inspired edges system. As I mention in #1769 (comment), this makes it impossible to do certain things that the pure blob/bitmask system used in 3.x could easily do.

As noted:

In 3.x, things like this, where you can have lone tiles in a sea of other tiles, are relatively easy to do if you're willing to get dirty and make multiple tilesets:

The new terrains system doesn't understand this type of setup, because it can't tell the difference between "grass surrounded by sand on all sides" and "sand surrounded by sand on all sides". It picks at random.

(The tileset used here can't replicate exactly what is displayed in the 3.x screenshot above, because it's based on the 48-tile blob set instead of the 256-tile blob set, but it should be clear that the algorithm can't even get as close as it should be able to. For reference, using the 48-tile blob set in 3.x would look like this image.)

Also, the system of changing neighboring tiles to match what the placed tile looks like causes unintuitive tile selection quirks like godotengine/godot#54587 godotengine/godot#57783.

These problems ultimately stem from having removed the concept of tiles having an inherent tile type or terrain type, and instead purely trying to fit them together by their edges, like wavefunctioncollapse. This works well enough with WFC because every edge pair in WFC is a unique identity, but in terrains, it results in too little information for the algorithm to behave as users expect. Also, it is very common for tilesheets to have lots of identical tiles, and selecting between such identical tiles from the tilemap terrain set list right now is basically impossible.

Describe the feature / enhancement and how it helps to overcome the problem or limitation

Terrains are a big improvement, and are capable of handling multi-neighbor-type scenarios that the old autotile system couldn't ever handle, so they shouldn't be replaced with the old system. Instead, tiles should regain the concept of having an inherent tile type, and tile selection should match edges up with tile types instead of with other edges.

Painting with terrains should should be based on selecting terrain types, similar to how the 3.x system was based on selecting autotile atlasses, instead of being based on selecting a specific tile from the atlas and rewriting all the tiles around it to exactly match that one tile. Users shouldn't need to pick out specific individual tiles within a terrain type if they don't need to.

In other words, the "terrain type" of a tile should never be changed without specifically painting over that particular tile; tiles should be picked within their terrain types to match their surrounding terrain types, like 3.x bitmasks but with terrains instead of "on" and "void".

Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams

The Terrains property of the Paint Properties editor in the Tiles tab of the TileSet subpanel should allow users to place center bits on tiles, which specify what the inherent terrain type of the tile is. Alternatively, there could be a separate Terrains property that specifies the terrain type of each tile, and the current Terrains property would be renamed to something like Terrain Neighbors, but this would make it less clear how the Terrain Set system works.

The Terrains tab of the TileMap subpanel should be changed to be a list of terrain sets instead of a tree list of terrains inside of terrain sets. Selecting a terrain set would populate the tile list with icons for each of the terrain types in that terrain set, and selecting them would be functionally similar to selecting autotile atlasses in 3.x. Painting with a terrain type selected would behave as described above. ctrl+clicking a tile in the 2d scene editor would automatically select the terrain associated with that tile. Erasing tiles should also replace their neighbors with tiles that peer with the 'No terrain' terrain like how erasing tiles in 3.x replaces neighboring tiles with tiles that peer have empty bitmasks on that edge; this does not currently happen in master.

Care must be taken to ensure that a 48-tile-per-terrain-type workflow is still possible despite its shortcomings, analogous to the 3x3 minimal autotile mode in 3.x. I don't have any opinion on whether this should be a new corners/edges mode or some kind of automatic smart fallback behavior.

If the current WFC-like edge-based autotile algorithm is still desirable in addition to the proposed inherent-terrain-type-based system, there could be a checkbox somewhere that switches between the current tree list view and the proposed list view, but the tree list view would filter by inherent terrain type instead of neighboring terrain type. Also, every variant of a given edge configuration should be displayed, as independent tiles, not just one as is currently the case in master. In this mode, painting with an individual tile selected would use the current purely edge-based autotile algorithm, replacing neighbors with ones that match the placed tile. Erasing tiles in this mode should use the inherent-terrain-type-based algorithm, not the WFC-like edge-based algorithm.

Tilesheets used here for completeness's sake:

(48-tile set)

256set.zip
(256-tile set)

(inputs to tilepipe to generate the 256-tile set)

If this enhancement will not be used often, can it be worked around with a few lines of script?

I don't think the necessary APIs are exposed for completely replacing the TileSet editor and tile selection logic.

Is there a reason why this should be core and not an add-on in the asset library?

This is a change to built-in TileSet functionality.

[arkology]

Actually I faced the same problem, but I don't use Tilemap node, only TileSet resource (and thanks to that I found a way to workaround this problem)

[Calinou]

@Dan-Gamin Please don't bump issues without contributing significant new information. Use the 👍 reaction button on the first post instead.

[Calinou]

Closing in favor of godotengine/godot#57783, as this is actually a functional regression from a previous release (which is better tracked on the main repository).