How we make and test our games

Why this page exists

Most explanations of a card game on the web are written from other explanations of that card game. Nobody deals the cards; nobody has to resolve the awkward case; and so the same handful of errors gets copied from page to page for years and hardens into received fact. You can watch it happen: three of the biggest card-rules sites will tell you a black three freezes the discard pile in Canasta, and it does not — it blocks the next player for one turn and then stops mattering.

We are not in a position to copy, because before a game gets a page it has to get a working engine, and an engine cannot be vague. That constraint is the whole quality story of this site, so it seems fair to describe it rather than just claim the outcome.

Where the rules come from

The reference of record is Pagat, John McLeod's card-games archive, which is the closest thing the field has to a serious primary source. Where a game has a documented standard form we follow it and say which one: the Canasta on this site is Classic Canasta, not the later Modern American version that caps melds at seven and gives sevens and aces special powers, and the page says so, because a table playing one against the other will argue all evening.

Where the wider web disagrees with itself, we say which reading we follow and why — and where the game itself genuinely varies from household to household, which a great many of them do, the page says that instead of inventing a single right answer. Where we had to make a call ourselves to stop a game running forever, the page tells you that too. Rummy's discard pile is recycled exactly once here, and then the hand is blocked and nobody scores; that is our decision, not a law of rummy, and it is written down as ours.

The engine comes before the page

Every game here is written first as a pure rules engine: a self-contained module that knows nothing about screens, clicks or drawing cards. You hand it a position and an action and it hands you back the next position, or it refuses and tells you why. There is no interface in it at all, which is precisely what makes it testable — a game that can only be checked by a person sitting and playing it will only ever be checked as thoroughly as someone had patience for.

Writing the rules this way forces every awkward question into the open, and the awkward questions are exactly the ones the copied pages skip. What happens when the stock runs out and nobody can move? Can you discard the card you just picked up? What if it is the only card you hold? Can you complete the canasta that lets you go out on the very turn you go out? Every one of those has to be decided and written down before the game will run at all.

Three passes before a game ships

Fixtures come first: specific positions worked out by hand, where we already know the answer, checked against what the engine says. Scoring hands, edge cases, the rules that interact badly with each other.

Simulation comes second, and is where most of the value is. The engine is made to play itself — thousands of complete games, sometimes tens of thousands — with the computer players choosing moves and a harness watching every single position for something impossible. Is every card still accounted for? Is every meld on the table legal? Does the player whose turn it is have at least one thing they can legally do? A second sweep plays deliberately badly, choosing at random from whatever is legal, to reach the positions a sensible player never would.

The browser pass comes last. The finished board gets driven automatically — clicking through real turns — while we measure two things: that no part of the table jumps or resizes mid-hand, and that the board actually offers every kind of move the rules allow. That last check exists because of a specific failure, below.

What the machine actually caught

These are not hypotheticals. Each of these was live in a finished-looking game and was found by a check rather than by a person noticing.

A correct game can still be broken

The most useful thing we have learned came from Casino. Its engine supported building — the move that gives the game its name — perfectly. The simulations exercised it constantly, about two and a half builds per round. Everything about the rules was right.

Then we drove the actual board for 77 turns and counted what a player could do. It made 46 trails and zero builds. Not because building was disallowed, but because the buttons only appeared once you had selected cards on the table, and nothing on screen ever suggested you should. The rule was implemented, tested, correct — and absent from the game as anybody would actually experience it.

The fix was an affordance rather than a rule: table cards that could form part of a legal build now carry a dashed gold edge, and the phase line names the move. The same sweep afterwards made ten builds at six different values. Every game built since gets that pass — drive the real board, count how often each kind of move actually happens, and treat a move that never fires as a bug even when the rules are perfect.

We test the advice, not just the rules

Strategy sections on card-game pages tend to repeat whatever the last page said. Because the computer players here are ordinary code, we can settle those claims instead: teach one side a maxim, leave the other side alone, deal both the same cards at the same table, and play it a few thousand times. The results have been humbling more often than not.

What none of this guarantees

It would be easy to read the above as a claim that the games here are perfect. They are not, and the honest limits are worth stating.

If we have it wrong

Being right is the entire point of the exercise, and a card-table argument settled by a wrong page is worse than no page at all. If a rule here contradicts what you know, we would genuinely like to hear it — particularly if you can say where your version comes from. Write to us at [email protected].