How We Test Solitaire Games

Too many solitaire sites publish rules they have never verified against an actual implementation. They copy Wikipedia, paraphrase a 1950s rulebook, invent a win rate out of thin air, and move on. Readers end up with rules that disagree with the game they are trying to play, strategy advice that has not been tested at the table, and win-rate figures that have no source behind them. We built SolitaireStack.com to do better, which meant building a testing process that runs on every game we cover and that we can point to in public. This page is that process.

Every game on the network is evaluated against three pillars before we publish rules, strategy, or a win rate for it. A game does not ship to readers until all three pillars are green.

1. Rules accuracy. Do our documented rules match authoritative historical sources, and do they match the game engine a reader will actually play in the browser? Both directions have to agree.
2. Gameplay fidelity. Does the implementation feel right? Do the moves a good player would expect to make actually work? Do edge cases resolve sensibly?
3. Player experience. Is the game playable on every device we support, at every skill level, and for players using assistive technology?

For every variant we cover, the Rules Desk cross-checks the documented rules against four categories of source: Hoyle's Rules of Games, Pagat.com, historical manuals where they exist (Cadogan's Illustrated Games of Patience from the 1870s is a frequent reference for patience-family games), and Wikipedia as a secondary source only. When the sources disagree — and they often do, because solitaire rules have drifted across a century of publication — we note the discrepancy directly in the article, name the disagreement, and say which rule our engine implements.

The second half of rules verification is cross-checking the article against the live game engine. If our article says "you can only move sequences in alternating colors," but the engine allows same-color moves, one of them is wrong. We fix whichever side is wrong. Sometimes the article needs updating because we misread a source; sometimes the engine needs a patch because a rule was implemented loosely. The important thing is that the two are never allowed to drift. A reader who learns the rules on our site should never sit down to the game and discover the controls disagree with the guide. This cross-checking happens for every game on the network — not just the flagship titles — and we rerun the check after any engine change that touches movement validation.

A short list of the ambiguities we have run into, all of which end up documented in the relevant rules pages: whether a partial suit run counts for scoring in Spider, whether Klondike allows unlimited redeals or caps them at three, whether FreeCell auto-moves a card to the foundation as soon as it is legal or waits until both opposite-color ranks are already there, whether Golf wraps from King to Ace, whether Yukon allows moving a single card or only a group, and what happens in Canfield when the reserve empties. None of those questions has a single universally correct answer across published rule sources. Our job is to pick one, document why, and make sure the engine actually plays that way.

For every game where we publish a win rate, we tell the reader where that number came from. There are three legitimate sources: a simulation we ran ourselves, published academic research, or an estimate derived from first-principles analysis. We always say which.

For simulations, we disclose the sample size (N) and report a 95% confidence interval by default. A claim like "Klondike wins 82% of the time" is useless without a methodology; a claim like "Klondike draw-3 wins 82.4% of the time across N=10,000 simulated deals under greedy-with-lookahead play (95% CI: 81.6%–83.2%)" is something a reader can audit. That is the standard we hold ourselves to. For estimates we say so plainly and mark them as such inline.

When prior academic research exists, we cite it directly. The most famous example in this family is FreeCell: the game is solvable on approximately 99.9987% of the 32,000 Microsoft deals (Don Woods' and Michael Keller's exhaustive solver analyses found exactly 8 of the 32,000 original deals were unwinnable). We link the source, note what was measured, and do not round the figure into a vaguer claim. When we cannot find published research and we have not run our own simulation, we do not publish a win rate at all. The phrase "roughly" is not a methodology.

Before a game goes live, members of the editorial team play it across the full difficulty range the game supports. For Spider that means 1-suit, 2-suit, and 4-suit. For FreeCell that means classic four-cell as well as any restricted-cell variants we ship. We play unhinted, we play with hints, we play on desktop, and we play on phone. Each playtester keeps a log of what they noticed: average game duration, frustrating UI moments, animation timing issues, and — most importantly — edge cases that the written rules do not cover.

Edge cases are where solitaire rules break down most often. A few examples we have documented: what happens if you run out of cards in Spider before completing a suit, how auto-move thresholds behave in FreeCell when the foundations are close to equal, whether Klondike draw-3 redeals have a hard limit, and how Golf handles wrapping from King to Ace when the engine allows it. Every game page on the network includes a short "what we noticed playing this" section written from those logs, because unvarnished playtesting notes are the most honest signal we can give a reader about a game.

Every game is tested against a browser and device matrix before launch: desktop Chrome, desktop Safari, desktop Firefox, iPhone Safari, and Android Chrome. We check drag handling, tap responsiveness, animation frame rates, and keyboard navigation. We run a screen-reader pass with VoiceOver on macOS and iOS, confirming that card state, foundations, and game outcome are announced. We verify that all interactive elements are reachable via keyboard alone, with visible focus indicators. We confirm that the color palette satisfies contrast ratios and that the red/black card distinction remains legible for common color-vision deficiencies (we use pattern and rank cues, not just hue).

Rules are re-verified annually or whenever we change the game engine in a way that touches movement, dealing, or completion logic. Win rates are re-simulated quarterly when we have capacity, and always re-simulated when we update a solver or a strategy heuristic. Corrections from verified error reports are applied within 72 hours and noted in the page's change history. None of this is glamorous, but it is the difference between content that stays accurate and content that rots.

Every game page on the network carries a small metadata stamp showing the last-verified date, the reviewing desk, and the engine version that was checked. When any of those three change, the stamp updates and the page goes back into the rotation. We prefer that cadence to the alternative most solitaire sites use, which is to publish once and forget the page exists.