Carc Central Community > Strategy Guide
Project 1A: Carcassonne Game Notation
wallaceprime:
--- Quote from: kothmann on June 15, 2022, 05:08:12 AM ---I think a “clean” landscape would be much easier for image processing. Are you using openCV? Some other library?
--- End quote ---
I'm brute-forcing it in C++.
I take the following steps:
* capture the screen
* do a maze-walk to find the periphery of the playing area
* search for a couple of dark grey tile placement positions (so I can find the tile size)
* calculate the tile boundaries in the playing area
* reduce each tile position to a 5 x 5 pixel matrix leaving a small border to allow for pixel misalignment
* compare each reduced tile to a list of all 2116 tile/orientation/meeple combinations (just for the base game at the moment) to find the best match
Here's a composite image of all the 5x5 pixel combinations!
It wouldn't be of any use at all for analysing photos of games played with real tiles on a table; I can't imagine players reacting to well to repeatedly being told that "you can't put the meeple on that side, it expects it on the other" or "well that doesn't work, your meeple is 2 mm away from the optimal position" and so on ;)
wallaceprime:
I originally tried looking at various locations within a tile to decipher whether it was city, road or field, but it got really tricky when a meeple almost occluded visibility of the small segment of road it was placed on, such as with a CCCR tile (so it couldn't tell if it was a farmer on a CCCF or a road meeple on a CCCR) or similarly with a RRRR being interpreted as a farmer on a RRRF tile.
I'm surprised I've got any hair left at all after all the hair-pulling that all those tweak/test iterations took! Comparing all 25 pixels seem to have worked flawlessly so far; I expect the slightly different layouts make enough difference for the matching to differentiate between them.
DIN0:
--- Quote --- but it got really tricky when a meeple almost occluded visibility of the small segment of road it was placed on,
--- End quote ---
You could either make meeple substitutes, or even better clear elevated stands for meeples.
kothmann:
--- Quote from: wallaceprime on June 15, 2022, 05:37:01 AM ---Here's a composite image of all the 5x5 pixel combinations!
--- End quote ---
WOW! This is fantastic! Thanks for sharing.
wallaceprime:
To find tile boundaries, I originally used a hue, saturation and value test to see if a pixel was a tile or not. Unfortunately, it got confused by meeples that hung over the edge of a tile; indicated with red circles below:
Rather than looking at every pixel, I used recursion to find the edges of the tile placement positions, where the function that tries to find a corner initially starts with a step size of 16 pixels, but then calls itself with half that step size when it overshoots. This way, if the edge was 63 pixels away for example, instead of checking all 63 pixels, it would only check at positions 16, 32, 48, 64, 56, 60, 62 and 63, so at just 8 positions. The tricky bit was tailoring the algorithm to ignore when meeples overhang the edge of tiles, looking ahead to see if it went back to being the background.
Ultimately, however, it was easier just to look for the dark grey placement positions:
I could then pick a couple and look for the smallest dimension and that was the tile size. I did have to go one step further, however, because BGA must calculate the corner positions in floating point, but then use them in integer form. This had the effect of sometimes causing tiles sizes to fluctuate between two integer sizes, such as between 54 and 55 pixels. This meant I couldn't rigidly use one size as, going across the playing area, the error would increase sufficiently to throw the tile boundaries off.
If any of you find this sort of stuff interesting, I'll create a new subject for it, but I know it's not everyone's cup of tea and I don't want to distract here from @DIN0's sterling work on his notation projects.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version