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.

ファイル、テスト、エントリポイントは指定されていません。タイル側のマッチングロジックを特定し、サイドコードがどのように生成・比較されるかを追跡したうえで、対称なサイドが引き続き自身と一致し、非対称なサイドが反転表現とのみ一致することを検証してください。

索引モデルが issue の本文から書いたものです。