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:

1. A stack of 52 cards is used; 13 cards for four suits.
2. The cards are layed out in four rows, thirteen cards per row.
3. Next the aces are placed to the left of the rows, so that there are now four rows with 14 slots, the aces in the leftmost slots, and four slots without card. This is how the program presents the game to the player.
4. The purpose of the game is to reorder the cards in increasing order, ace, two, three, an so on up to the king, so that at the end there are four ordered rows, with an empty spot at the rightmost position each.
5. Any card (except the aces) can be moved to an empty spot, either before the card with same suit and higher by one in value, or after the card with the same suit and lower by one in value.
6. Before moving the cards, the player can rearrange the aces in whatever ordering he/she likes.

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.

1. Extract the files: for example   tar -xzf blue.tgz
2. cd to the newly created directory blue and edit the makefile for the directory with the card pixmaps.
3. make
4. Play: ./blue

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