ID:2024109
 
The mathematics behind autojoining tiles are somewhat of a passion of mine, which is why I wrote a seminal article on the subject and developed the IconCutter utility. But recently I've had some newer ideas that might help autojoining escape its "boxy" look.

If you've never used the IconCutter utility, here's the gist: If you setup an icon file with states labeled 0, 17, 68, 85, and 255, the utility can cut those up and merge them to create all of the states you need for a 47-tile autojoining icon. It does this by cutting each "template" icon into four corners, and pasting the appropriate corners together.

But if you compare the results of this to, say, Foomerian joining, you may notice that joins with fewer states can achieve much wider curves, so a corner for instance looks more like a quarter-circle than a rounded box.

To allow for more variety in the resulting icons, I had a thought: What if you could supply more than just the basic five states?

For instance, if your tile connects to the north, northeast, and east, its state would be 7. What if you wanted this to be a nice wide curve? And state 5, which only connects north and east, should also look like the nice wide curve but should simply have the one interior corner. So I thought: What if you provided states such as 7, 28, 112, and 193 for all the closed corners, and those could be used for the cutting also? Then a utility like IconCutter could take three corners of that icon, and merge it with the remaining corner from state 85.

This, therefore, is my proposed new algorithm for a future edition of IconCutter:

- For each target state, it may be built by the following rules (in order of priority):

0) Any time an individual corner has to be used, look for its "expected" template first, then look for any matches elsewhere in the file if one isn't found, choosing the lowest numerical value.

1) If the state exists in the template file, copy it verbatim.

2) If any template state exists that matches exactly three corners, copy those three corners. (Conflicts will be solved by going with the first state in numerical order.) Then copy the fourth corner from its proper template. For instance, if state 7 is present and the target is state 5, copy the NW,SW,SE corners from state 7--which match--and the NE corner from state 85.

3) If two templates are found such that one half of the target matches one template, and the other half matches the other, copy the two halves and merge them. (Again any possible conflicts are handled in numerical order.)

4) If one template is found that matches half of the target, copy it and handle the remaining two corners individually. (Conflicts resolved numerically.)

5) Handle any remaining cases according to classic IconCutter rules, taking each corner individually.

The upshot of this arrangement is that you can take any Foomerian join icon set, add a state 0 that lines up with the possible edges, and get a much nicer result than the classic IconCutter would ordinarily produce.
Autojoining isn't really my thing and I don't quiet understand how it works honestly so I can't give any feedback on that matter but I'm curious, could autojoining be possible as a built-in feature in the mapping tool?
Auto-joining is great both for map makers and for games that allow the players to change the map as they play.