Custom autotiling with support for 45° surfaces.

tl;dr: I continued work on custom autotiling logic with support for internal-vs-external subtiles and for 90°, 45°, and 27° surface combinations.

What happened last week?

Highlights

Work on a custom autotiling system for subtiles that separates exterior-to-interior art transitions across the width of two cells.
Think-through a new more-declarative design for my custom autotiling, which will make it easier to add the 27-degree cases and to modify things later on.

Work on a custom autotiling system for subtiles that separates exterior-to-interior art transitions across the width of two cells.

Create tile-set art for more 45-90 interior cases.
Encode all drawn 90, 45, and 45-to-90 degree external subtile positions for accessing in GDScript.
Finish implementing autotiling logic with only the 90-degree-angle subtiles for both external and internal cases.
Implement autotiling logic for 45-degree-only and 45-to-90-degree external cases.

Think through another possible encoding method for choosing which 45-90-27 subtile to use based on neighbor arrangements.

I am trying to find a way to simplify my logic and possibly reduce the crazy amount of if/else branching I’m typing out.
It seems like a config-object-based approach would involve more complexity and/or duplicated configurations.
It seems like a more bitmask-based approach would decrease readability.
So I ended up just going forward with my giant if/else blocks.

I revisited the possibility for an alternative approach at the end of the week.
My new plan is to configure each subtile with four enums, which represent the shapes of each of its four corners.
Each subtile will also be configured with the same traditional autotiling bitmask that Godot supports for declaring whether the subtile should be used based on the presence of neighboring tiles.
My subtile-matching logic will then find subtiles that have both the correct bitmask as well as corner shapes that fit with the neighboring corners.
I'll configure separately a prioritized list of valid neighbor-corner-shape matches for each possible corner shape.

If I am careful to add extra fallback cases to these lists, then the tile-set author should also be able to omit less-common cases if they don't want to spend the time drawing them.

I think its logic won't take as much time as the previous imperative nested-if-else approach, so I shouldn't be wasting too much time re-writing things.
But, more importantly, adding the 27-degree cases, with the exponential increase in the number of angle-transition cases, will be much more tractable with this new declarative approach.

Create a lot of new CellProximity helper functions for checking cell shapes and neighbor topography.

I used to do a lot of up-front calculations to determine the state of all the nearby neighbors.
However, I now need to expand my neighbor state checks from 5x5 to 7x7.
This would now be a lot more up-front calculation, and most of these calculations probably aren’t needed most of the time.
So I updated CellProximity to only calculate things on-demand.
Performance seems great.

Update tile-configuration to include the concept of is_collidable, and use this to automatically determine _is_tile_bound.
Create a legend for how various subtiles map to the new declarative categories.

Autotiling logic with support for 45° vs 90° surfaces.
(The 45° interior cases aren't implemented yet.)

Work on my new declarative approach for configuring my custom autotiling system.
Another game jam this next weekend: Global Gam Jam 2022!

🎉 Cheers!