Godot 4 Autotiler (pre-alpha)

[young copper]

This will be a drop-in terrain tile updater plugin, with a faster, more accurate and more deterministic matching algorithm than the built-in engine. This is a preview of what it can do. Any thoughts and feedback are welcome.

It works without any extra setup, using the same terrain sets and bitmask data that engine does. It has both script and plugin interfaces, but it is not intended as a full overhaul (unlike other similar plugins like Better Terrain). Its main editor function is an update button, which can be handy to avoid manually re-painting, but its greatest use case is for procedural generation via script.

It also brings back some features from Godot 3.x:

• full 256-tile corners and sides mode
• wildcard bits
• shared peering terrains (a more basic form of the _is_tile_bound())
• ability to update tiles and fix errors after the fact

This was created as a proof-of-concept and I am hoping it may help guide future directions for the engine's algorithm. I really liked the new terrain system (even creating a plugin, TileBitTools, for it) and was disappointed to discover that the matching algorithm wouldn't be sufficiently accurate for my needs. Rather than give up on Godot 4's terrain system, I began tinkering my own matching algorithm. There are many approaches to creating a solver like this, and I hope this example will at least show that a back-end capable of high-quality matching is possible without breaking compatibility or compromising speed.

It is not quite ready for a testing release yet (it needs UI work, clean-up and optimization). But the current results have been very promising, so I wanted to share a few examples.

This is a corners tileset with 3-terrain transitions

The engine algorithm requires 3 updates for this map (one for each terrain). When you update only the visible terrains, you get bad transitions. When you overlap the terrain updates (making every cell water, then making every grass and dirt cell dirt, then making every grass cell grass), you get good quality transitions but slower performance.

The Autotiler plugin updates in one function call. In this case, the results are similar to to the engine (with overlapping terrains) except for it standardizes matches to empty tiles. It is still slow, but faster than the engine likely due to the way to selects tiles (lookups rather than iterators whenever possible, and aggressively narrowed search fields). It is capable of backtracking, but most maps, including all these, do not require it.

This is the same corners tileset as in the proc gen examples. When used in the editor, it is sensitive to draw order (grass on dirt makes it select a third terrain as transition, even through dirt to grass transitions exist) and it works poorly with the pencil tool since it cannot fix the errors that come from painting corners tiles one at a time. The update button re-selects all the tiles in the layer, using pre-calculated transitions to select the best possible tile.

This is a corners-and-sides tileset. All terrains transition to yellow, and yellow transitions to empty. But even though all the transitions exist (via yellow), when painting one terrain over another, the engine picks non-matching tiles (even for yellow, which it matches to empty instead). The update button fixes this.

[half cedar]

Did you add a proposal \ request to see if this could be made core?

[young copper]

Not yet but that’s the plan! There seems to have been a lot of friction with previous similar proposals, so I want to prove it’s a working plugin first and that there’s demand for it. (It’s also in gdscript, though I’ve tried to write it similarly enough to the core algorithm that it can be easily ported). Also, this way, if it gets rejected or delayed, there will still be a working plugin implementation people can use.