"Sudoku uniqueness applies only to locked digits" is doing all the work here, and the reason it holds is that it names the invariant on the value rather than on the cell. Most mashups die precisely because they enforce the rule at spawn time, when merges still need duplicates in the row to be legal — deferring it to a seal move keeps the two rule sets from fighting each other.
The part I'd expect to bite is the board's solvability, not its legality. Since the run starts empty and you build the puzzle by playing it, a sealed tile can leave a row with no legal completion for the remaining alphabet while still being legal at the moment of sealing — that's the classic dead end, except here the player caused it and can't undo without unwinding the run.
How is the win condition checked: a full validate on every seal (cheap, immediate feedback, but tells the player nothing until it's too late), or a forward check for cells that still have at least one candidate digit? For a daily puzzle the second one seems worth the cost.
Thanks. That’s a cleaner framing: the invariant sits on the value once locked, not on the cell the moment it’s occupied. Deferring uniqueness to seal is what stops spawn and merge from fighting Sudoku.
v1 only checks legality, not solvability. Seal asks whether this digit would duplicate a locked tile in the same row, column, or box. Win is a full validation when every cell is already locked. Loss is no legal spawn, merge, or seal left. There is no candidate or forward check after seal.
That dead end is real and intentional here. You can seal a board that is locally legal and globally doomed; undo is the recovery. I left forward checking out on purpose, so soft-locks stay part of the merge economy instead of sliding the game toward a solver. A “warn on doomed seal” assist is interesting for Daily later
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
"Sudoku uniqueness applies only to locked digits" is doing all the work here, and the reason it holds is that it names the invariant on the value rather than on the cell. Most mashups die precisely because they enforce the rule at spawn time, when merges still need duplicates in the row to be legal — deferring it to a
sealmove keeps the two rule sets from fighting each other.The part I'd expect to bite is the board's solvability, not its legality. Since the run starts empty and you build the puzzle by playing it, a sealed tile can leave a row with no legal completion for the remaining alphabet while still being legal at the moment of sealing — that's the classic dead end, except here the player caused it and can't undo without unwinding the run.
How is the win condition checked: a full validate on every seal (cheap, immediate feedback, but tells the player nothing until it's too late), or a forward check for cells that still have at least one candidate digit? For a daily puzzle the second one seems worth the cost.
Thanks. That’s a cleaner framing: the invariant sits on the value once locked, not on the cell the moment it’s occupied. Deferring uniqueness to seal is what stops spawn and merge from fighting Sudoku.
v1 only checks legality, not solvability. Seal asks whether this digit would duplicate a locked tile in the same row, column, or box. Win is a full validation when every cell is already locked. Loss is no legal spawn, merge, or seal left. There is no candidate or forward check after seal.
That dead end is real and intentional here. You can seal a board that is locally legal and globally doomed; undo is the recovery. I left forward checking out on purpose, so soft-locks stay part of the merge economy instead of sliding the game toward a solver. A “warn on doomed seal” assist is interesting for Daily later