The optimal-play engine behind every puzzle and every star rating.
Quadle is a game of perfect information: the whole board is visible from the first second, nothing is hidden, and nothing is random once the puzzle is set. That means every board has a best possible answer — a solution that uses the fewest tiles — and there's a program that finds it. It's the same engine that guarantees every puzzle you're served is solvable, and it's what your efficiency rating is measured against. This page explains how it works, starting from the rules and building up to the neat piece of mathematics at its heart. No background required.
A puzzle is a four-by-four grid. Some cells already hold sealed tiles (the ones you're trying to capture); the rest are empty. You hold a hand of tiles, each printed with four numbers from 1 to 9 — one on each edge: north, east, south, west. When you drop a tile onto an empty cell, each of its edges is compared with the facing edge of whatever sits in the neighbouring cell. If your edge is strictly greater, that neighbour flips colour. You win when every tile on the grid is green, and the solver's job is to do it in as few placements as possible.
The obvious approach — try every possibility — falls apart fast. For each solution the solver has to decide three things at once: which tiles from the hand to use, where to put each one, and in what order to place them. Because a placed tile can flip tiles that are already green — including your own — order genuinely matters, and the number of possible orderings grows explosively. A naive search would be checking billions of sequences on even a modest board. The trick isn't a faster computer; it's realising that most of that ordering doesn't matter at all.
Almost the entire difficulty of the puzzle evaporates once you notice two things about how flips accumulate. Both come down to a single idea: a tile flips back and forth, green to grey to green, so what decides its final colour isn't when it was flipped but simply how many times — whether that count is odd or even. This is the parity idea some players discover on their own, and it's the foundation the solver is built on.
A sealed tile starts grey. Every time an adjacent placed tile beats it, it flips. Grey becomes green, green would become grey again, and so on. So a sealed tile ends up green if and only if it is beaten an odd number of times over the whole solution.
Here's the crucial part: a sealed tile never gets placed, so it never flips anyone else and its fate depends only on how many of its neighbours beat it — never on the order they arrived. That single fact removes ordering from the entire question of capturing the board's sealed tiles. The solver can decide purely which tiles go on which cells, count how many times each sealed tile gets beaten, and keep only the arrangements where every one of those counts is odd. It doesn't have to think about sequence at all for this part.
Better still, it can bail out early. As the search fills cells one by one, the moment it places a tile on the last empty cell touching a particular sealed tile, that sealed tile's flip-count is locked in. If it's even, this whole branch is already doomed and the solver abandons it immediately instead of wasting effort finishing an arrangement that can never win.
Your placed tiles start green the instant they land. For the board to end all green, each of them has to stay green — which means each placed tile must be flipped an even number of times (zero counts as even). This is the mirror image of the first law, and it's the only place where order still has anything to say, because the only things that can flip one of your tiles are the other tiles you place next to it.
Zoom in on two of your own tiles sitting next to each other. Compare their facing edges. If they tie, neither can ever flip the other and there's nothing to decide. If one strictly beats the other, then exactly one of them — the loser — is at risk, and whether it actually flips comes down to a single yes-or-no question: was the winner placed after the loser? Place the winner later and the loser flips; place it earlier and it doesn't. Every contested edge between two of your tiles is therefore just one bit of information: flip, or no flip.
Now the puzzle has been boiled down to something surprisingly clean. Each contested edge is a switch that's either on or off. Each of your placed tiles carries a rule: the number of its own switches that are "on" must be even, so it stays green. "An even number of these switches are on" is exactly what mathematicians call an XOR equation — addition where you only care about odd versus even. Put all those rules together and you have a system of XOR equations, one per placed tile, over a handful of switches.
Systems like this have a tidy structure: the set of all switch-settings that satisfy every rule at once forms what's called a null space, and there's a standard, fast procedure (Gaussian elimination, done with XOR instead of ordinary arithmetic) that produces a small set of building blocks from which every valid setting can be assembled. Instead of blindly trying every combination of switches, the solver generates only the settings that already obey all the even-flip rules. On a real board that's usually a tiny number of candidates rather than an astronomical one.
A valid switch-setting says, for every contested edge, whether the winner must come after the loser or before. Those are ordering constraints: "place this one before that one." The last step is to check whether all those constraints can actually be satisfied together — whether there's a genuine sequence that respects every one of them. That's a classic operation called a topological sort. If the constraints contain a cycle (place A before B, B before C, C before A), no order can satisfy them and the solver moves on to the next candidate. If they're cycle-free, the topological sort hands back an actual, playable order of moves — a real solution.
All of the above finds a solution that uses a specific number of tiles. To make it optimal, the solver wraps everything in a simple outer loop: first it asks whether the board can be won with a single tile, then with two, then three, and so on. The very first count that works is, by definition, the fewest tiles possible — the optimal solution. This technique is called iterative deepening, and it's why the tile count the solver reports is a true minimum, not just a lucky low number. (It also quietly dedupes identical tiles in your hand, since swapping two copies of the same tile changes nothing.)
Before any of the heavy lifting, the solver does a cheap sanity check. If some sealed tile is so strong that no tile in your hand could beat it from any adjacent cell, the board is unwinnable and there's no point searching — it says so at once. Small checks like this stop the engine from grinding away on hopeless positions.
Clever algorithms are exactly where subtle bugs like to hide, so the solver keeps a completely separate, deliberately dumb component alongside it: a plain simulator that takes the proposed sequence of moves and actually plays them out on a fresh board, one placement at a time, flipping neighbours the naive way. If the simulator doesn't agree that every tile ended up green, something is wrong. The fast, mathematical path and the slow, literal path have to reach the same answer — a safety net that keeps the whole thing honest.
Two reasons. First, it's the reason you never hit a dead end: every puzzle Quadle serves has been run past this engine and confirmed solvable before it reaches you. Second, it's what gives your efficiency rating meaning. When the game tells you a board could have been solved in three tiles and you used five, that "three" isn't a guess — it's the provably smallest number, found by the process above. Beating your own solution, and closing the gap to the optimum, is the quiet second game hiding underneath the puzzle. If you'd like to get better at it, the strategy tips in the How to Play guide are a good place to start, and the About page tells the story of how the whole idea came together.