What Fog Does to a Sudoku Rule
Someone on Reddit suggested I go read up on Sudoku variants. I did, picked six for Sudoku Fog, and ran straight into a problem that wasn’t really about the rules themselves.
Sudoku Fog covers the grid in fog. You uncover it as you solve. And that changes what a variant is:
Adding a variant to an ordinary Sudoku game means adding a rule. Adding one to a fog-of-war Sudoku game means adding information that may itself need to be hidden.
A thermometer — a line the digits must increase along — tells you something before you write a single digit. So does a Kropki dot between two cells, which says they differ by one or that one is double the other. So does a cell marked as even. Classic Sudoku under fog only ever asked one question: is this digit hidden? A variant asks a second one: is this rule hidden?
I couldn’t find an established answer to borrow. The reason, I think, is that a human setter answers it once, by hand, for one puzzle, and can look at the finished thing and judge it fair. A generator can’t. It needs an answer that holds in advance for every puzzle it will ever produce, including the ones nobody has looked at yet.
Three questions had to be settled before any variant could ship. All three turned out to be about information rather than about rules.
1. What does the fog hide?
The naive answer is that fog hides cells, so a marker in a fogged cell is hidden with it. That works for markers that live inside one cell, like an odd/even mark. It falls apart for the other two shapes.
A thermometer is a line across many cells. A Kropki dot lives on the edge between two. If fog is applied cell by cell, a thermometer crossing the fog boundary gets drawn as a fragment — half a line, ending nowhere. But the thermometer is one object. Half of it isn’t a weaker version of the rule; it’s a different rule, and a misleading one.
So the rule I settled on is this:
The reveal unit is a whole constraint, not a cell.
Uncover any single cell a constraint touches and the entire constraint is drawn, including the parts running off into fog. The digits underneath stay hidden.
That splits information in two. You learn the shape of a constraint; you never learn its contents. Fog governs the second and not the first, and once stated that way, the visibility question for future variants is already answered.
The design I dropped to get there was a per-variant reveal policy — each variant declaring how much of itself a reveal exposes. It’s more flexible and it’s worse: every new variant re-opens the question, by hand, forever. One rule that covers all of them isn’t a simplification I was clever enough to plan. It’s the only version that doesn’t rot.
2. What does an empty space mean?
Kropki has a particularly awkward property under fog. If there’s no dot between two cells, that isn’t silence — it means those two cells are neither consecutive nor in a 1:2 ratio. Absence is a constraint, and solvers rely on it.
Put that under fog and it looks broken. You see no dot. Does that mean there is no dot, or that you haven’t uncovered it yet? Same blank space, opposite conclusions. I spent a while sketching UI for it: some marker for checked, nothing here, distinct from unexplored space.
Then I wrote down when an edge is actually known, and the feature evaporated. An edge is known exactly when at least one of its two cells has been uncovered. That’s the complete condition. And the player can already see which cells are uncovered — that is what fog is.
The fog was already the indicator. What I’d been designing was a second, worse copy of information the screen was showing.
The general form: before adding UI to disambiguate a state, check whether the existing display already determines it. A visibility system tends to encode more than it looks like it encodes, because the player reads it continuously.
3. Can the UI reveal what the fog hides?
A visibility system can be exactly right and still leak through the interface built on top of it. Any UI element that communicates puzzle structure is a potential leak — and highlights are the easiest kind to miss, because they read as an accessibility affordance rather than as a disclosure.
Sudoku Fog highlights the cells related to whichever cell you’ve selected — in classic play, your row, column and box. Variants need this too, and Anti-Knight is close to unplayable without it, because knight offsets don’t match anyone’s spatial intuition.
But the highlight has to be computed from something, and that something is the puzzle. Whether it leaks depends on which kind of relation it draws:
- Positional relations — King’s Move, Anti-Knight, the X diagonals. Identical on every board. Where they are tells you nothing about this puzzle, so highlighting them leaks nothing.
- Puzzle-specific relations — thermometers, Kropki dots. Where the line sits is the puzzle. Highlighting the cells of a thermometer you haven’t uncovered announces that there’s a thermometer in the fog, for free, without you having done the work of reaching it.
So a highlight may only follow constraints that are already revealed. The rule is small, easy to miss, and exactly the kind of thing a generator will violate a thousand times a day if nobody states it explicitly.
What it generalises to
Fog doesn’t only hide answers. It changes what counts as information.
Once a puzzle carries constraints beyond the grid itself, every marker, every line, every highlight — and every absence — is a channel. Each one needs a decision about which side of the fog it sits on, and those decisions are the design. The six variant rules were the easy part. The hard part was deciding what the player was allowed to know about them, and when.