A card returns to its old column, yet the game is not quite back where it started. A free cell remains occupied, the move counter has changed, or a card that reached a foundation stays there. That is a useful failure to study when learning to build stateful software. Restoring a familiar picture is not the same as restoring the information that produced it.
Use FreeCell solitaire as the reference board for this exercise. All fifty-two cards begin face up across eight columns, with four temporary cells and four foundations above them. Because there is no draw pile, you can describe a position without inventing hidden card values. That makes the game a concrete setting for thinking about snapshots, validation and recovery, not just an attractive interface to copy.
Begin with a position you can describe
For your own practice implementation, record the contents of each column in a defined order. Record each free cell as empty or containing one card, and each foundation as an ordered suit pile. Give every card a stable identity. A red six is not a sufficient identifier when your code also needs to know whether it is a heart or a diamond.
Write down what counts as game state and what does not. A selected card may belong to temporary interface state, while the actual pile contents belong to the position. Your undo policy may include a move count but leave elapsed time running. Either choice needs a clear definition. Do not discover the policy accidentally when an old screenshot and a restored position disagree.
Validate the smallest move first
Start with moving one available card to an empty free cell. Confirm that the source card is exposed, the destination cell is empty and the card is removed from its original column when the action commits. Then test moving that card back to an appropriate column or foundation. Keep those operations understandable before introducing group shortcuts.
The BVS FreeCell rules distinguish the basic one-card move from a sequence shortcut made possible by temporary space. That distinction matters for an implementation exercise. Moving a group is not simply moving several pictures that happen to line up. It needs the game’s capacity and sequence checks as well as a destination. Follow the rules of the version you intend to implement rather than assuming every FreeCell application accepts the same shortcut.
Separate a proposal from a committed change
A drag or click is a proposed action, not proof that the position should change. In your own game, let a validator examine the current source and destination before producing a next state. If the proposal is illegal, keep the existing position intact and return an explanation the interface can display.
This separation makes failures easier to locate. If a red six is dropped onto another red card, the rule check should reject it rather than move the card and later attempt to repair the board. If a free cell is already occupied, the proposal should leave both cards where they were. You can test those behaviors without depending on an animation or a particular screen size.
Watch for a copy that still shares its contents
Imagine that your position contains an array of eight column arrays. You copy the outer array to save an undo snapshot, then remove a card from one of the original inner columns. If the snapshot still refers to that same inner array, your saved position changes too. Undo can no longer restore the card even though a new outer array was created.
MDN’s Array.slice documentation identifies slice as a shallow copy and explains the behavior of shared object references. For this exercise, that is the important detail, not the method name itself. Decide how your state representation isolates nested arrays and card objects. You can use an immutable transition or a suitable independent snapshot, but verify the result with a test that changes the current state after saving the previous one.
Check the position as well as the picture
After an action, confirm that every card identity appears exactly once across the tableau, free cells and foundations. Confirm that a free cell holds no more than one card. Those are useful invariants because they remain relevant whether you render cards with images, text or a test-only representation.
Then compare the restored state with the saved state after an undo. Check card order, not merely the number of cards in each column. A six above a five is different from a five above a six even when both columns contain two entries. A visual comparison can help identify a display problem, but a state comparison is what exposes a recovery error hidden behind similar-looking cards.
Treat automatic follow-on actions deliberately
Some card-game interfaces can send eligible cards to a foundation automatically. If your own implementation supports such a feature, decide whether that follow-on change belongs to the user’s original action or to a separate history entry. Either policy can be understandable if it is explained and applied consistently.
The awkward outcome is an undo that restores only part of what the player experienced. A card returns from a free cell while a related foundation change remains, leaving a position that never existed before the action. Test the complete sequence, including any automatic behavior your application adds. This is a proposed development exercise, not a claim about the linked game’s internal code or history mechanism.
Keep the exercise useful when you change languages
You do not have to write a complete browser game to learn from this example. A small command-line model can accept a source, destination and card identity, print the resulting piles and undo the last action. Once the transitions are correct, a graphical interface becomes a separate concern rather than the place where every rule lives.
FromDev’s programming tutorial collection is a useful starting point for choosing a language and finding its basic data-structure material. Its beginner programming-book guide also includes game-based learning among the approaches it discusses. The card example fits that practical route, but the objective here is narrower than shipping a polished game: define one position, make one valid change and recover it reliably.
Finish with a failure you can reproduce
Save a minimal position that reveals one bug. For example, put a single exposed card at the end of a column and leave one free cell empty. Move the card, undo, then compare the exact state. If the failure requires an automatic action or a shared-reference mutation, include that condition explicitly. A small reproducible case is easier to understand than a full random deal.
Once that case works, add a second action and undo twice. Confirm that each saved state remains independent of later changes. Only then expand the model to more complicated moves. FreeCell gives this exercise a clear vocabulary of cards, columns and cells, but the underlying habit carries into other applications: define what changed, preserve what came before, and prove that recovery restores the right information rather than merely a reassuring picture.