# FreeCell: How many cards can be moved at once?

I'm working on a FreeCell implementation and I'm currently stuck determining how many cards the user is allowed to move from tableu to tableu at once. I've seen multiple formulas for this, but no explanation them. (empty_columns is decreased by 1 if we move to an empty column)

• `2 ^ empty_columns + free_cells`
• `2 ^ empty_columns * (free_cells+1)`
• `(empty_colums+1) * (free_cells+1)`

What I'd like to know is if one of these is correct or (even better) anyone knows a small algorithm to move cards like the in microsoft implementation

I'm asking this in boardgames.sx because this question is not about the implementation itself, but about the game mechanics.

## Technically, one

In FreeCell, you are only allowed to move 1 card at a time, either to or from a free cell or from one stack to another.

That said, it is trivial to move an entire stack of N+1 cards, where N is the number of free cells, by moving N cards to the cells, moving the last card to the new stack, and then pulling down the stored cards onto the new stack.

Most computer implementations of FreeCell allow you to move entire stacks without having to step through the intermediate storage on the free cells (as long as there are enough free cells). An implementation without this ability would be totally playable, but it would be aggravating to use because simple actions would take significantly more work on the part of the player.

Empty columns can be used as free cells, simply adding 1 to your free cell count. But they're also much more powerful than that, because they can hold stacks.

If you have a single empty column, you can transfer N+1 cards to that column, N+1 cards to the new stack, and then transfer the N+1 cards from the formerly empty stack onto the new column, for a total of 2*(N+1) cards moved. Obviously, this only works if you're not transferring cards to the empty column, in which case you're limited to only using the free cells, for N+1.

If you have two empty columns, you can transfer 2*(N+1) cards to that column (using the other empty column, N+1 cards to the second column (since you no longer have an empty column to use), then N+1 cards to a new stack, then reverse that process to pull all 4*(N+1) cards onto the new stack.

With three columns, the third column will be able to store 4*(N+1) cards, leading to (4+2+1+1)(N+1) = 8(N+1) cards being movable.

I hope you can see at this point that the trend will continue, and the total formula is (2^M)*(N+1), where M is then number of empty columns and N is the number of empty stacks.

All of that said, transfers that utilize columns to their maximum effect are more complicated, less common, and less labor intensive than just using free cells. If your implementation forces players to use columns manually it won't have the same excessive effect on quality of play that not using the free cell shortcut would have. Experienced players would probably be unhappy, but it would still be playable.

Additionally, it's not necessarily obvious to new players how to get the maximum transfer using 2+ empty columns, so by doing those maneuvers for them you are possibly allowing players to make moves that they couldn't figure out on their own. Remember, the goal here is to shortcut routine, obvious, and boring moves without actually providing strategic aid to the player. That's a judgement call on your part.

My vague memories of Microsoft's earlier implementations was that it either only shortcutted free cell moves, or free cell + one empty column moves, and if you wanted to use more than one empty column you had to figure it out yourself. I don't remember for sure, though.

• Thank you! So that's equivalent to formula #2 in my original question! I can see how allowing this maximum of auto-card-moves might lead to intransparency; is there a less potent formula you'd suggest instead? – gir Feb 18 '19 at 19:24
• this FAQ I've just discovered also describes (2**m)(n+1) as the maximum – gir Feb 18 '19 at 19:26
• @gir as I sort of hinted at, I would lean towards using the free cells + one empty column (2*(Cells +1), with column, Cells+1 without). That said, the current Microsoft implementation seems to allow the full (2^m)(n+1) move, so using that one wouldn't raise any eyebrows. – Arcanist Lupus Feb 18 '19 at 19:59
• neat! I'll probably make this a compile time flag and play around what feels nicer. If anyone's interested, klondike and spider are already implemented: gir.st/sol.htm (requires a linux/bsd/osx system) – gir Feb 18 '19 at 20:02

Any move other than a single card requires enough free cells, either in an empty column or in the talon (the four single spaces above the tableau) to hold the cards. If, through some miracle of randomness, you have a stack of six cards in the as-dealt tableau and want to move them, you can't -- because there are only four spaces in the talon, and you'd have to move five cards to the talon to move a stack of six.

Now, if you have an empty column, you can move enough cards to fill the talon, then stage them back to the empty tableau column, fill the talon again, then unload all of those cards (by reversing the process) to their new destination. If you have two free columns, you can do this to load the second column, then load up the first column and talon before starting to unload to the destination. If you started with two free columns and an empty talon (rather unlikely, but not at all impossible), you could move fifteen cards -- loading two empty columns with five each, then the talon with four, and moving the fifteenth card directly.

Of course, you'll never do that, because the longest sequence of cards you could ever move would be twelve (king down to deuce), and that could only be moved to an empty column (and would still require two additional empty columns).

• Thanks, this helps. So what do you thinkof this formula: `emtpy_talon * (1+free_columns) + 1`? I think this maps what you're saying in §2 ("fill talon, move to tableau, repeat"), or am i still mistaken? – gir Feb 18 '19 at 19:06
• That sounds right. – Zeiss Ikon Feb 18 '19 at 19:08