Description of the game:
------------------------
Freecell's Rules:
-----------------
* There are 8 stacks of cards, 4 freecells, and 4 foundations. The game
is played with one deck.
* At the beginning of play, the cards are dealt to the stacks (4*7+4*6).
The faces of all the cards are visible at the beginning of play.
* A freecell can hold one _single_ card.
* The foundations are built from ace to king and the object of the
game is to move all the cards to the foundations.
* A card can be placed on top of a card that is of the opposite colour,
and is higher in rank by 1, assuming that the latter is at the top of a
stack.
* An empty stack may be filled with any card.
* An atomic move consists of:
- moving a card from a stack to a freecell.
- moving a card from a freecell to a parent card on a stack.
- moving a card from the top of a stack on top of a parent card on a
different stack
- moving a card from the top of a stack or from a freecell to the
foundations.
Strategies:
-----------
* A sequence of more than one card can be moved by moving the top cards to
the freecells or to unoccupied stacks. The latter is commonly called a
sequence move or a "supermove" if it involves temporarily putting some
cards in a vacant stack.
* Sometimes, it is useful to move cards to the freecells or temporarily
to an empty column, so the card below them can serve as a basis for a
sequence.
Pseudo-code for DFS:
-------------------
Solve-State(state, prev_states, ret)
if (state == empty_state)
Push(ret, state)
return SOLVED
for each move possible on state
new_state stack moves are being outputted with the number of
cards that are moved.
* Freecell Pro, OTOH, used to ignore the number of cards and expected such
moves to comply with what the original Microsoft Freecell would do in that
case.
* This caused problems in playback of a large percentage of the games in
its integration with Freecell solver.
* A post I made to the mailing list about it
(http://groups.yahoo.com/group/fc-solve-discuss/message/197) sparked a
very big flame-war that diverted to cover other topics.
* I actually was happy that there was some action there:
(http://groups.yahoo.com/group/fc-solve-discuss/message/219)
* Usually the only thing that happens is that I announce new releases or ask
them questions and no-one or few people reply.
* Eventually Adrian Ettlinger (a FC-Pro hacker) have extended Freecell Pro
to make use of an optional number of cards to move argument. This made
playback of Freecell Solver solutions perfectly smooth.
The Story of the User API:
--------------------------
* Starting of Freecell Solver 1.0.0, FCS had a set of functions
entitled freecell_solver_user_ (after their prefix) meant for integration into
an existing software.
* When Stephan Kulow integrated them into kpat (a solitaire suite for KDE),
he did not use it, because it did not gave him everything he needed. Instead
he used the more basic internal functions.
* I told him that "I would sleep better at night" knowing that fcs_user_ will
be used, and asked him to implement the missing parts himself, and send me
the patch. He did.
* Markus Oberhumer (of PySol fame), created a Python interface for the
library, and again sent me some functions he wrote.
* Eventually, I converted the executable itself to use fcs_user (while adding
a lot of functions in the process) to make sure I give the embedding
application all the functionality that I use.
* I also ended up creating an API to analyse a command line and configure
a solver instance accordingly. This made writing programs that behave
in a similar manner to the fc-solve executable so much easier.
* I found it encouraging that , an engineer who worked on Freecell
3D, was able to integrate fcs_user_ without my help, and just
informed me of the release of F3D.
Auto-confiscation and Friends:
-------------------------------
* Once upon a time Freecell Solver was distributed only with a makefile
for GNU make, and everyone were happy.
* When Stephan Kulow embedded its code into kpat, he adapted the makefile
to use the standard KDE autoconf-based build process.
* Somewhat afterwards, I decided that I want the build process to be more
portable and modular, and to give me the ability to build a shared library.
* The solution - Converting to Autoconf, Automake and Libtool.
* How to do that is out of the scope of this article. I can just say it is
not very straightforward, and required me a lot of tweaking and trial and
error.
* Then I decided building an RPM out of it would be nice. So I created an
RPM spec for it.
* Again, it required quite a lot of tweaking and experimenting. (Tzafrir's
Lecture (URL) and web-resource greatly helped).
* I eventually integrated generating an up-to-date RPM SPEC into the Autoconf
process, and thus, was able to build an RPM by issuing:
./configure
make dist
rpm -tb freecell-solver-*.tar.gz
from the distro. (link to what Joel Spolsky says about building a package in
one command).
* A corresponding Debian package has been initially created by Yotam Rubin and
is now maintained by Risko Gergely, who also uploads it to the Debian pool of
packages.
The Freshmeat Effect (and how to avoid it)
------------------------------------------
* When I created the first version of FCS, and gave it the final touches,
I decided to call it "Freecell Solver" in order for it to have a descriptive
title.
* I posted announcements for the first release and subsequent (usually stable)
releases on Freshmeat, and so made many people aware of it.
* Starting at the very first days, a Google search for "freecell solver"
yielded its homepage as the first link.
* Today, the situation is much worse: now most of the Google hits have
something to do with it.
* The query "freecell solver" is generic enough that someone may wish
to find any of the available Freecell Solvers.
* Solution: do your best to give an original name for your program, so it
won't clog up searches. Abbreviations, or acronyms or puns or just something
meaningless which you like, work best.