Blue is a test program that comes with the ncurses library. It was originally written by ... . It is good as test program but not very interesting as a game to play. However after a slight change of the rules it became a quite challanging solitaire. After playing with a deck of cards i realized i needed to plan a strategy to solve the game and to manage its complexity. A computer program with a graphical interface was the ideal tool. So the new game Blue was created.
My initial program was very crude, and buggy too. Kyungmi helped to make it better, to add functionalities (eg, the "history"), and to improve the interface. Probably it still has bugs, but it is now in a reasonable shape to play with.
The rules of the game:
To help play the game the interface allows to plan a "strategy", ie, an intermediate layout from which the final result can be achieved. The program starts in the "stategy" mode, in which the player can draw the intermediate card layout by clicking over a card, or by dragging with the mouse from an initial card. In this mode it is also possible the swap the aces among themselves.
Next the player, switches to "play" mode, and can move the cards according to the game rules. He/she may either drag and drop a card with the mouse, or double click on a card (in this case if there are two possible places where the card can go, the program beeps and marks the two places).
It is possible to move back and forward in the "history" of the moves. Finally the game status can be saved in a ascii game-file (viewable with any text editor) which contains the initial layout, the current layout, the strategy, and the history of the moves.
The program Blue
blue.tgz (19385 B): sources of the game.
pixamp.tgz (30170 B): card pixmaps.
games.tgz (2603 B): a few solvable games.
to-do.tgz (757 B): games that i could not solve.
The program Test-Blue
After playing a few games i began thinking about the properties of the game. It is simple to see that there are layouts that are not solvable: for example a layout with scrambled cards, the empty spots at the four rightmost position of one row and a king just before them. In practice however very often the game is solvable. So one interesting question is What is the probability that a layout is solvable?. I do not know the answer to this question. In a very simple case, two suits and three cards each (ie, a 2x4 layout) about two thirds of the games are solvable, and one third is not. I suspect that when the number of suits and that of cards are higher the probability of a solvable layout is higher.
Although i do not know how to estimate this probability, i made a program that attempts to find if a layout is solvable. The program test_blue is a wrapper that reads a game layout from a gamefile and, for each ordering of the aces, calls a routine that verifies the solvability of the game. This routine is contained in the file check_blue and examines exhaustively the board configurations that can be reached from the initial layout. The program keeps track of the examined configurations, in order not to repeat a dead check. However the number of configurations is too large to stay in memory, and the program keeps only a limited number of them and implements a policy to discard the others. Therefore the search is suboptimal. In many cases the program manages to say that the game is solvable. But it may end without deciding whether the game is solvable or not because of the memory limitation. The amount of memroy can be set with a define at the beginning of the file check_blue according to the RAM of your machine. It is expressed in 4K pages: roughly, 16 K is ok if you have 128 MB of RAM. The more RAM the more pages.
utils.tgz (8388 B): utility programs.
Marco Corvi - 2000