orgpolt.blogg.se

1. #MAHJONGG SOLITAIRE TILE MATCHING GENERATOR#
2. #MAHJONGG SOLITAIRE TILE MATCHING FULL#
3. #MAHJONGG SOLITAIRE TILE MATCHING PLUS#
4. #MAHJONGG SOLITAIRE TILE MATCHING FREE#

this can be a 144x144 matrix so 20k of memory plus a LEFT and RIGHT block list, also 20 k each. (top tile on stack has an empty block list)Īll valid moves require that their "current_vertical_Block_list" be empty. You have 144 tiles in the game, each of the 144 tiles has a block list. If you've found algo that build solvable heap in one turn - please let me know. However, "middle" is different for different configurations. This come up with more convenient configurations, when there are no frets at edges of very long rows, staying up until last player moves. Most of existed games seems to restrict putting first ("first on row") frets somewhere in a middle. In practice, "turtle" built in no more then 6 retries.

#MAHJONGG SOLITAIRE TILE MATCHING FREE#

These rules does not guarantee a build will always successful - it sometimes leave last 2 free cells self-blocking, and build should be retried (or at least last few frets)

#MAHJONGG SOLITAIRE TILE MATCHING GENERATOR#

Picking a completely random (legal) first move in a forward-solving generator is more likely to lead to a solvable board. E.g, you are guaranteed to fail your setup if you don't start at least SOME of your rows w/ the first piece in the middle, such as in a layout w/ 1 long row. Generating a board in reverse has more complicated rules, though. You still have the same caveats, because you can still end up with dead ends. I've done very little study of graph theory, though, so maybe there's a better solution to the DAG random traversal/search problem :)Įdit: You actually could use any of my solutions w/ generating the board in reverse, ala the Oct 13th 2008 post.

#MAHJONGG SOLITAIRE TILE MATCHING FULL#

Once you've hit the first dead end, degrade to doing full marking/edge generation when visiting each node (lazy evaluation where possible). First try to solve it with minimal memory (store selected pairs on your stack). Since dead ends are more rare than first-try solutions in the layouts I have used, what immediately comes to mind is a hybrid solution.

Keep track of your traversal history so that you never repeat a descent. Do a random traversal, until you find a leaf node at depth 72. To solve that bigger problem, treat each possible board state as a node in a DAG, with each selected pair being an edge on that graph. I don't know if it is possible to design a board where this would be the case, but if so, there is still a solution. If you end up removing a pair that resembles a "no outlet" road, where all subsequent "roads" are a dead end, and there are multiple dead ends, your algorithm will never complete. Unfortunately, depending on the board, this may loop forever. Take a different path by making sure you match pairs that will remove the original blocking tile. This allows me to use the same generator for both setting up the board, and the shuffle feature, even if the player screwed up and made a 100% unsolvable state.Īnother solution when you hit a dead end is to back out (pop off the stack, replacing tiles on the board) until you can take a different path. Once I hit 8 retries, I give up and just randomly assign the rest of the tiles. If you run into a dead end (numFreeTiles = 1), just reset your generator :) I have found I usually don't hit dead ends, and have so far have a max retry count of 3 for the 10-or-so layouts I have tried. Push each pair you remove onto a "matched pair" stack. Solve the board (forward, not backward) with unmarked tiles. None of the answers here are quite perfect, and several of them have complicated caveats or will break on pathological layouts. I know this is an old question, but I came across this when solving the problem myself.