Who makes this, and how
How we build and test these games
Aces Up Solitaire is made by two people: Brian Hamilton, who writes the game logic, and Karan Hamilton, who reads every page as a player before it goes live. This is what happens between those two things.
The first problem
Choosing which version of a game to build
Solitaire has no governing body, and it never has. Games like Golf, Canfield, Scorpion, Klondike and Aces Up have been printed, taught and coded with meaningfully different rules for well over a century. Whether a stock recycles, whether a king is the only card that may fill a space, whether a foundation card can come back down — each of those turns a hard deal into an easy one.
So the first decision for any new page is which version to implement, and the second is to say so plainly. Every game page carries a "this version" box listing exactly what the implementation does wherever published rules disagree. If a page here plays differently from the version you learned, that box is where you find out why.
Editorial policy
We do not publish win rates
Almost every solitaire win percentage you will find online describes a different ruleset from the one it is printed on. A Klondike figure measured on draw-three with three passes says nothing about draw-one with unlimited recycling. A Pyramid figure from a three-pass version says nothing about a one-pass game.
Rather than borrow numbers, we leave them out and explain the structural reasons a game is hard instead. The two exceptions are cases where the answer is a property of the rules rather than a measurement: Clock Patience wins exactly one deal in thirteen because the game is won only when the fourth king is the last card turned, and FreeCell is very nearly always solvable, a result established by working through all 32,000 of the original numbered deals.
If we ever publish a measured figure for a game here, it will be measured against that exact page and described as such.
How a deal is made
The shuffle is genuinely random
The games run in your browser in ordinary JavaScript. Starting a game builds the correct deck for that variation, shuffles it, and deals it to the page's stated rules. There is no account, no download, and nothing is sent anywhere.
Deals are not filtered. Most pages here will hand you shuffles that cannot be won, because that is what the game does — and a page that quietly removed them would be lying about its own difficulty. The one exception is Easy Solitaire, where a solver checks each deal and discards the unwinnable ones. That is a switch you control, it is on by default, and the page says so.
Before a page ships
What actually gets checked
Some of this is automated and some of it is a person looking at a screen. Both matter: an automated check will not notice that an example contradicts the rules, and a person will not reliably notice that a table has broken its container at 390 pixels.
| Rules | |
|---|---|
| Automated rule tests | Seventy-four scripted test files, one per game, run on every change. They assert the legal and illegal moves, the deal, win detection, and the awkward cases — wrapping foundations, blocked cards, empty-space rules, redeal limits. |
| Manual invalid-move recovery | Select a card, attempt an illegal destination, then select a different card. A game that needs a refresh to recover from a rejected move does not ship. |
| The page | |
| Static output check | Confirms every expected page built, every internal link resolves, and nothing points at a 404. |
| Internal link check | Flags any game named in the prose that is not linked to its page, and catches links that have lost the space next to them in the rendered HTML. |
| Layout audit | Loads the built page at 360, 390, 430, 768 and 1280 pixels and fails if anything is wider than the viewport, if a table escapes its scroll container, or if a diagram label is clipped by its own artboard. |
| Print check | Where a page offers a printable rules card, the output is generated as a PDF and the page count verified. |
| The playable board | |
| Mobile audit | The rendered board is checked on narrow phone widths after a real shuffle, not from empty placeholder markup. Horizontal scrolling on a phone is a blocker, not a follow-up. |
| Reading pass | Karan reads the page as a player: do the examples match the game, is the rule version clear, does the strategy help someone actually make a better move. |
The rule tests are the ones that matter most. Card games fail in quiet ways — a foundation that accepts a card it should not, a wrap rule that works in one direction only — and those are exactly the bugs a casual play-through misses.
Wording
Why difficulty is described, not scored
You will not find a five-star difficulty rating here. What you will find is a description of why a game is hard: how much is hidden, how strict the movement is, how many second chances the stock gives you, whether foundations are one-way.
Those are the things that actually decide it, and unlike a star rating they tell you whether you will enjoy the game. Someone who dislikes losing to a shuffle wants to know about hidden cards, not that a game scored four out of five.
When we get it wrong
Corrections
If you find a rule that behaves differently from the page, a move that is rejected when it should not be, or a board that breaks on your phone, we want to know. The process is unglamorous: reproduce it, check it against the stated rule version, fix the logic or the wording, rerun the checks above, and publish.
Report anything through the contact page. The most useful reports name the page, your device and browser, the card positions if it is a move bug, and what you expected to happen instead.