The issue with asymmetric tiles and an easy solution

the issue with the tiles in hand is the asymmetry

when you have a symmetric side on the tile, they can match to themselves (meaning the key you assigned to them), like in the first row here:


But as you can see in the second row, when dealing with tiles with asymmetric sides, the matches are incorrect. The logic used to match sides (having the same code) is not valid for asymmetrical sides, as it allows them to match themselves which is wrong visually.

A **quick fix for this** is to use a more complex code to identify sides and update the logic that finds that two sides match. My quick fix is to use a 3 character key for each side: '000', '111', '222', '333', ... , 'aaa', 'bbb', 'ccc', etc and for the asymmetrical sides use values as '001' and '100' for their mirrored side. When matching sides instead of comparing their code, you must compare their code vs the reversed string of their code. In this way, '000' matches '000' (which keeps symmetrical sides working just fine) but '001' will only find a match in the reversed key '100' fixing asymmetrical sides.

In the previous example 4 becomes '001' and 5 becomes '100', allowing for them to match to the correct side but not themselves.

_Annex:_
My suggested solution was to create a method that figures out 3 pixels colours for each side of the tile: left, center and right. Once you have them create an array with those 3 values. To connect a tile to another, just compare the array to the reverse order of itself. This implements the symmetrical / asymmetrical solution and will allow for interchangeable tiles on the fly.