Build a solver
The practitioner's corner of the wiki: validation data to check your code against, the literature ranked by usefulness, the record timeline and the methods behind it, the dead ends, and how to run the code yourself.
A ready-to-use Rust starter kit for building your own Eternity II solver: score, generate boards with real colour balance, batch-generate with pinned clues, convert every format, benchmark, and a solve→sweep→compare iteration loop, so you write only the solver. Plus a one-line setup for coding agents, and a board generator right here in the browser.
The survey the community keeps asking for and never finds: every family of attack tried on Eternity II, what each one actually reached, where it walls out, and a link to the deep page. One organising insight runs through all of them.
Every format an Eternity II board or puzzle travels in on this site and in the community: the board_edges letter string and the hints clue list, e2pieces.txt, the puzzle CSV, the site's Puzzle JSON, and the viewer URL, with the exact byte-level rules (how the grey border is encoded in each) and, most of all, what each format can and cannot recover.
The numbers every Eternity II researcher ends up re-deriving, collected in one place with their provenance: the puzzle definition, the clue placements, scoring conventions, the record table, search-space sizes and the structural counts.
How a community forbidden from sharing the pieces built a shared test culture anyway: derived-count verification protocols, the Txibilis and beginner suites, node-count duels, full enumerations, and the one benchmark that is still standing open today.
Nineteen years of community software for Eternity II (manual-placement GUIs, editors, public solvers, generators and viewers), plus the quieter layer that made them interoperate: e2pieces.txt, CRC-16 checksums, and the board-in-a-URL format that became the lingua franca. A reference census, with every tool sourced to the message that announced it.
Tomy sold four small companion puzzles for Eternity II: solve one, submit the solution, and the official site revealed one piece's placement on the main board. What each puzzle was, the broken online checker, the eBay grey market, why puzzles 5 and 6 never came, and the clue puzzles' second life as complex-theory test cases and donor piece sets.
Every "Eternity II" that is not the real puzzle: the TopCoder Marathon variant and the unresolved Takahashi 468, McGavin's unframed 480/480, the mixed-set boards, the no-starter challenge, and the claim quarantine, from the 2007 phantom-sets warning to the community's zero-knowledge verification ethic. Ends with a checklist for stating a score properly.
How the solvers that hold the records actually search. They are all, at heart, depth-first backtrackers; what separates them is the order they try things and how they bend the rules near the end.
Everything that throws away hopeless states before the search wastes time on them: propagation to a fixed point, the all-different matching filter, learned no-goods, and the edge-slipping invariant.
Depth-first search done seriously. The order a solver visits the cells is its one free choice and moves the tree size by orders of magnitude; restarts turn a heavy-tailed runtime into a portfolio. This is the family behind every record backtracker.
Raw throughput: the craft below the algorithm (lookup tables, cache-sized structs, generated code) and spreading the work across many machines. It decides whether a node costs 26 cycles or 2,600, and it is the clearest demonstration that speed alone does not move the wall.
Building a high-scoring board from an empty grid instead of digging with backtracking: beam search keeps the best partial boards alive and grows them cell by cell. The workhorse behind this project's from-scratch builders, and a clean illustration of why breadth alone stalls in the deep interior.
Most attacks on Eternity II search from first principles. A distinct family does the opposite: it mines the corpus of boards people have already found for structure, then feeds that structure back into the search. Position priors, learned move-ordering, anti-pattern mining, record decoding, and the failure mode where a learned signal collapses.
Start with a full, imperfect board and improve it by moves: destroy-and-repair, annealing and tempering, evolutionary recombination. The most reliable polishers here, and the cleanest demonstrations of the rigidity wall, where every one of them stops at the same height.
Solvers that can prove things: SAT and CSP encodings, integer programming and its relaxations, exact-cover, meet-in-the-middle, and iterated projection maps. Complete methods stall on the full board, but their verdicts earn their keep as impossibility proofs on sub-boards.
The technique shelf: the algorithms and pruning ideas that recur in every serious Eternity II solver, each with what it is, what it costs, and what it actually bought when measured on this puzzle.
These do not try to solve the puzzle: they measure it, which is how the community knows where the walls are. Parity arguments give one-pass impossibility proofs; solution counting pins down how many full solutions exist to within a factor of two, without anyone having seen one.
Throwing silicon at the wall: GPU ports, FPGA pipelines, distributed sweeps, and the perennial quantum proposal. This is the ledger of what each one actually delivered, and why the wall it meets is memory and structure, not arithmetic.
Approaches we tried that look promising and don't move the needle on Eternity II, written down with what we found so you can spend your time elsewhere.
A public, CC0 dataset for Eternity II in two parts: fourteen benchmark instances to solve, and a corpus of 7,658 distinct strong boards to learn from. Every score is recomputed from the board itself, and the corpus is checked to be genuinely diverse rather than a thousand copies of one board.
Exact counts of how many valid ways a small block can be filled at a given position of the official Eternity II board, under increasingly constrained rules: known-good numbers to check your solver's edge-matching and constraint code against.
The whole site, the engine, and every result in this section run from one repository. Here is how to get it going, rebuild the WebAssembly engine, and reproduce the numbers.