Ability to fine-tune auto-layers or reference multiple IntGrids?
I'm not sure if I'm making a feature request, or asking about a feature that already exists but is hard to discover. In any case...
The existing methods for transforming an IntGrid into an AutoLayer seem pretty easy to use and efficient when dealing with broad, sweeping rules and a few obvious corner cases like, well, corners.
But real game maps seem to have a lot more subtle variation that isn't exactly random and is not that easy to encode in a single int value without, effectively, turning that int into a "tile index" in which case you might as well drop the autolayer. At least that is how it appears, maybe (I hope) I'm just missing the simple solution.
By way of example, let's say we're looking at just the peak of a mountain. The contour could look like any of the following (apologies for the crude ASCII art, but it should get the idea across):
Example 1
______ ______
__ / \_____/ \__
Here we have flat tops and sloped sides. It's pretty obvious what goes into every tile; either left-slope, right-slope or bottom-half.
Example 2
/\ /\
/ \__/ \__
In this case, the tops are clear peaks. The top row is more challenging than the bottom row because the top row doesn't have a clear "left and right neighbors" rule, but it still sort of works without the center tile, if only by coincidence. However, it gets a lot more complicated if there's no spacing:
/\/\/\ /\/\/\
__/ \_____/ \__
It's a simple "jagged surface" but there's really no way to specify in the autolayer rules that it's supposed to be jagged. If we're marking terrain, it's all just "mountain". The data to represent this is exactly the same data we would have used in example 1.
And to make things more exciting, we might have single-tile variants:
Example 3
_^_ __^^^__ _______ ___
/ \___/ \______/ \___/ \
It might not be obvious from the ASCII art, but in terms of how we label the tiles, the right side is an exact mirror image of the left side; let's take "M" to be "mountain" and "S" to be "sky":
SMMMSSSSSMMMMMMMSSSS | SSSSMMMMMMMSSSSSMMMS
MMMMMMMMMMMMMMMMMMMM | MMMMMMMMMMMMMMMMMMMM
I put the | to show clearly where it's mirrored, but obviously the grid is continuous. The thing to note here is that "mountain" does not differentiate between "flat" and "jagged", given that the ^ is only a single tile. And if I go down the route of defining all the different ints for all types of "mountain tile" then I'm essentially just drawing out the tile set, with the added downside that it's possible to create nonsensical runs.
There are two hypothetical ways I can see of resolving this; either
(a) have a way to tweak the output of the rule, and just override the tile that was chosen. Maybe there is already a way to do this? I know there is "baking" but that's a pretty blunt instrument, baking should be reserved for when you are totally done with the map and just want to optimize in-game performance.
or (b) be able to define rules that are based on two (or more) intgrids. In the case above, what we really have is a function of two different and largely independent variables: Terrain (Sky/Mountain) and Slope (or Collider if you prefer). I can imagine level designers far more talented than myself wanting additional variables like material, elevation and so on.
Are either of these possible today? If not, would they be difficult to add? Or is there some simpler, more direct route to accomplishing single-tile variants (aside from sheer randomness) that everybody else is used to?
P.S. In case it matters, what I'm actually doing right now is just painting the tiles manually, and using an enum for colliders. But this is fairly limiting, since we only get one enum per tile set, and enums can't be incorporated into autolayers. I'm using the IntGrid system as a sort of surrogate enum and thought, if I'm going to paint the whole map with integers anyway, it would be more sensible to just switch everything over to autolayers, but these little rule-defying incidents keep popping up and overall it's looking infeasible to finish the conversion.