Connect matching nodes across the grid.
Solve the built-in levels.
Design your own grids.
Design custom paths.
Manage your grids and track your solutions.
Publish grids and test community creations.
Explore the mathematics behind grids.
Choose between the classic starter grids and the advanced workspace.
Pick one of the revealed starter grids.
Jump straight into the editor, tile forge, or the exact community spaces you want.
Why hex path puzzles are hard, and what kind of hard they are.
Core idea
Each tile only sees its neighbors, but every choice ripples across the whole board. That gap — between rules you can check at a glance and a solution that has to be globally consistent — is what puts path puzzles in the NP-hard family of problems.
Within the family, size isn't what makes a board difficult. Structure is: bottlenecks, endpoint pairings, and how much slack each tile leaves for the rest of the network.
Each tile is a tiny rule. A wrong choice can stay invisible for a dozen moves and only fail at the far edge of the board. The puzzle isn't hard because there are too many tiles — it's hard because local choices have non-local consequences.
Sometimes a board has no solution at all. A narrow corridor that can't carry every required path, two endpoints that fight over the same exit — these structural blockers can make a puzzle impossible before you start drawing.
Which local constraints let you prove impossibility before running a full search? Bottlenecks, disconnected regions, and forced pairings can sometimes act like clean certificates of failure.
Some boards force exactly one routing — those feel like deduction puzzles. Others admit dozens — those feel like exploration. The number of solutions tells you whether the difficulty is finding the answer or choosing among answers.
What changes turn a rigid grid into one with many valid completions? Symmetry, branching freedom, and corridor width can all change how many solutions the board admits.
Among the routes that work, which one is "best"? Fewest turns? Most symmetric? Best balanced? Different definitions pick different winners — and the cleanest answer is rarely the one you stumble on first.
How should simplicity be measured: fewest turns, shortest total path length, strongest symmetry, or the most balanced pairing pattern? Different metrics may prefer very different "best" routes.
You'd expect three-path tiles to be harder than two-path tiles — more states, more to track. In practice they often feel easier. Extra connectivity is extra slack: more ways out of a bad commitment, fewer chains of forced decisions, fewer brittle dead ends.
For the formal version of this paradox — and what NP-completeness actually says about path puzzles — switch to the mathematicians' view above.
Encode the board as an undirected graph G=(V,E) with tiles as vertices and shared edges between neighboring tiles. A tile rule is a set of permitted internal pairings on its incident edges — a perfect matching on the edge-set \delta(v) for each v\in V. A board solution is a global selection, one matching per tile, composing into edge-disjoint paths between the required endpoint pairs \{(s_i,t_i)\}_{i=1}^{k}.
In short: a path puzzle is a constraint-satisfaction problem whose constraints are local edge-matchings and whose witness is a global multi-commodity routing.
The decision problem — does this board admit a valid routing? — is in NP: a candidate solution is verifiable in polynomial time by checking each tile's matching and tracing each required path. It is also NP-hard, by reduction from edge-disjoint paths on planar graphs (Karp 1975) and edge-matching with rotations (Demaine & Demaine 2007). The decision problem is therefore NP-complete:
Concretely: unless \mathrm{P}=\mathrm{NP}, no algorithm solves every instance in time polynomial in the board size. Worst-case runtime is essentially exponential, and any tractability we observe comes from structure, not better engineering.
A useful sanity check: a verifier runs in O(|V| + k\cdot|E|) time, while the natural backtracking solver explores up to \prod_{v\in V} |\mathcal{M}(v)| states in the worst case.
Counting solutions sits one rung higher: #P-hard. Even when deciding existence is easy on a restricted class, counting valid routings can remain intractable — analogous to the gap between bipartite matching (\mathrm{P}) and counting perfect matchings, i.e. the permanent (\#\mathrm{P}-complete, Valiant 1979). For puzzle design this has a practical consequence: uniqueness is hard to guarantee structurally, so designers verify it empirically per board.
A few parameters control practical difficulty:
A degree-d tile admits at most (d-1)!! = (d-1)(d-3)\cdots internal matchings on its incident edges (and a chosen subset, depending on rules). Increasing path-count per tile from two to three relaxes the per-tile constraint: fewer rotations are forbidden, the per-tile feasible set widens, and the joint feasible set is more often non-empty even though raw configuration count grows.
The headline: per-tile entropy and global constraint tightness move in opposite directions when you add connectivity. Only the second governs whether a solution exists.
Where does extra connectivity stop being "more complexity" and start becoming "more freedom"? Comparing two-path and three-path tiles is a good way to study when local choices become globally brittle.
These prompts can become small experiments in the editor or community grids. A useful theory board should point toward conjectures, counterexamples, and puzzles that other people can test.
localStorage.Manage grids, retrieve saved progress, and view solutions.
Choose between sharing grids and browsing the community.
Publish Repository grids publicly or manage group-only sharing from the same place.
Browse the public gallery or jump into group-shared collections from one browser landing page.
Open a group to browse private grids for chosen members.
Browse the public gallery, test shared grids, save your own progress into Repository, and join the discussion on each card.
All paths perfectly routed.
Configure grid → drag letters to boundaries → save to repository
Design custom routing logic for any geometry.
Drag tiles onto 🗑️ to delete them permanently.