Home page | https://rjbs.cloud/ |
GitHub | https://github.com/rjbs |
Lipograms | https://oulipo.social/@rjbs |
Home page | https://rjbs.cloud/ |
GitHub | https://github.com/rjbs |
Lipograms | https://oulipo.social/@rjbs |
I spent four days in Vienna in early February. This maybe isn't the nicest time of year to go, but it was cheap and really the weather was nice. I saw museums, saw friends, ate cake, and fixed bugs. Good times all around.
In my Portable Puzzle Collection, it was recently (a few weeks ago) the 20th birthday of the game "Mines": a reimplementation of Minesweeper which ensures every grid can be solved by reasoning rather than guesswork. The first click in a completely blank grid is guaranteed to be safe, and to open an area of more than one clue, and after that, you can always identify a safe square to open next by thinking about the currently visible clues.
This makes it possible to generate grids with a much higher density of mines than standard randomised Minesweeper, such as the example shown here with 99 mines in only a 16×16 grid. I actually didn't predict that this would be possible when I wrote the grid generator originally: I only expected to be able to play on settings like the standard Windows ones, without those nasty last-minute frustrations. The ability to turn up the density by more than a factor of 2 was a very pleasant surprise – my algorithm was far more effective than I had anticipated!
The odd thing about Mines is: in the past 20 years, this one game has received far more bug reports about insoluble game instances than any other puzzle in my collection. Very likely more than all the other games *put together*.
But not one of those reports has turned out to be a real bug in the grid generation. In cases where they sent a save file or a game ID, I generally played through the game myself to make sure; if they only sent a screenshot, I've always at least pointed out something I could see in the picture. *Everybody* who sent this kind of report turned out to have missed something.
Happy 20th birthday, Mines!
In my Portable Puzzle Collection, it was recently (a few weeks ago) the 20th birthday of the game "Mines": a reimplementation of Minesweeper which ensures every grid can be solved by reasoning rather than guesswork. The first click in a completely blank grid is guaranteed to be safe, and to open an area of more than one clue, and after that, you can always identify a safe square to open next by thinking about the currently visible clues.
This makes it possible to generate grids with a much higher density of mines than standard randomised Minesweeper, such as the example shown here with 99 mines in only a 16×16 grid. I actually didn't predict that this would be possible when I wrote the grid generator originally: I only expected to be able to play on settings like the standard Windows ones, without those nasty last-minute frustrations. The ability to turn up the density by more than a factor of 2 was a very pleasant surprise – my algorithm was far more effective than I had anticipated!
The odd thing about Mines is: in the past 20 years, this one game has received far more bug reports about insoluble game instances than any other puzzle in my collection. Very likely more than all the other games *put together*.
But not one of those reports has turned out to be a real bug in the grid generation. In cases where they sent a save file or a game ID, I generally played through the game myself to make sure; if they only sent a screenshot, I've always at least pointed out something I could see in the picture. *Everybody* who sent this kind of report turned out to have missed something.
Happy 20th birthday, Mines!
I've always wondered why Mines has attracted *so many* reports of insolubility. My other puzzle games get the occasional one (and, across the whole collection one or two have been right). But Mines gets a large majority.
Perhaps it's just that Mines is far more popular then the rest of my games, and the larger number of bug reports is in proportion to the larger number of players? I don't have statistics to confirm if that's true, though.
And I have another theory:
Players used to playing Minesweeper as a high-speed game, on a timer, simply aren't *used* to having to stop and reason carefully. Because if you're trying to beat your speed record, there's no point: if you stop and ponder over a tricky deduction for 20 seconds, you might or might not finish the game successfully, but you *certainly* won't get a high score. So you might as well treat anything above-averagely difficult *as if* it was impossible.
Speaking of speed play, the most interesting email conversation I've ever had about Mines was with a serious competitive Minesweeper player – someone who placed highly in world tournaments.
First, I hadn't known there _was_ a serious tournament Minesweeper scene, so that was interesting by itself. But also, this player had been using my Mines on the high-density settings as an element of their training programme, to get lots of practice at the situations that come up with high-numbered clues, which you don't get many chances to practise if you only play random grids.
But they didn't like my Mines's user interface, which makes sense, because it's intentionally simplified for portability. And if your reflexes are finely tuned to drive the standard UI at incredibly high speed, any tiny difference will surely throw you off your stride. So they were looking at extracting the grid generation code from my implementation, and sticking it into a modified version of one of the 'pro clones' – the versions of the game used in tournament play. That way, they'd get my high-density grids with the UI they needed.
Alas, I don't know if they ever completed that project, or if it ended up improving their play!
@simontatham
There are two solutions.
Either prevent undoing the first click.
Or reset the game using the same seed.
The latter may confuse people using undo to cheat, as the same seed will generate a different grid with a different first click.
@balki because only Minesweeper is _traditionally_ timed.
But yes, I've always thought it would be nice to make the timer optional across all games, so that you can turn it on for other games, or off for Mines (if you don't like the subconscious time pressure).
Now that there's a user-preferences system, that's reasonably feasible, but it's never got to the top of my priority list.
@RandamuMaki I'm afraid the things you've filled in on the top 4 rows are also wrong. They're consistent with the clues currently shown, but they're not the only pattern consistent with those clues. Opening further squares will reveal clues that rule out one of the two possibilities.
I expected someone might want to replay this particular game and finish it. So the alt text of my original post contains a game ID that you can paste into any version of my Mines!
@simontatham I had never thought much about the determinability of minesweeper until I did a version on a pen plotter. Then it became important and I learned a few things. Your version sounds great. I don’t like the indeterminate portions in the classic version.
@knutaf I'm afraid I've never figured out how to make the web version friendly to mobile browsers. That's not really my expertise – I'd welcome help from someone who does know the answers to things like that (in particular, in plain unassisted JS with no framework on top).
But there are app versions for mobile devices, such as @shortcipher's Android port.
Thank you so much for these games! I've had the page you host these on bookmarked for many years now. I love the mines game, I've never found a single one that couldn't be solved using logic alone, and that always made it very rewarding.
Favorite mines type: 9x9 with 72 mines. 😁
I recently started playing the bridges game, which also can be solved using logic alone. I'm captivated by the mechanics which can be both mathematical and visual which keeps the game extra fun for me.
@simontatham I wonder if some of this is a misunderstanding of the set of information you may be required to use to solve it. e.g I played a bit prompted by this toot, and ran into a game which had a corner like this.
Game is perfectly solvable, but only using the information that there are 170 mines on the board. You can't solve this corner with only local information, which surprised me.
(https://www.chiark.greenend.org.uk/~sgtatham/puzzles/js/mines.html#30x16:15,0,m63e3099956808ffbfa625e4c0b131198ba6da37aed14ffb3997c11081dfb2f16679f372561b93369f1db2f87bf1c442346633ed9763ca41436888873 if you're interested)
@simontatham
I have a trick when there seems to be a bug:
Open a second copy of the came, then use "specific" to start the same game, and click solve. If it solves it, you missed something. If it can't solve it, there's a bug, either in the generation (not solvable without guessing), or in the solver.
This works because in most of the games, the "specific" string contains the grid layout, not the seed use to generate it, and the second copy ensures that the solver doesn't have any data from generating the grid.
Untangle (I think that's the only one) can't solve a grid without the data from generation, but the rest of them, this is an efficient way of checking if there's a bug.
@leeloo I agree that works in most games and not Untangle, but Mines is another exception. So is Guess. In those, the game id _does_ contain the solution rather than the clues, because how else could you possibly represent a specific instance of a Minesweeper grid?
Reopening a Mines descriptive game ID in a second instance and hitting Solve will tell you where the first instance thought the mines were, but it won't re-run the _solver_ to confirm they can be deduced one by one from the starting point.
@simontatham
Guess is obvious, I guess my eyes skipped that one looking down the list.
And I guess mines works the same way, although it could maybe store hints for every square instead, but that would be huge.
@simontatham Deciding if there is an arrangement of mines consistent with the shown numbers is NP complete, as it has been shown to be equivalent to the SAT (boolean satisfiability problem):
https://minesweepergame.com/math/minesweeper-is-np-complete-2018.pdf
So don't feel bad if you have a hard time with it, so do computers.
@profdc9 true, but the Minesweeper consistency problem has remarkably little to do with actually playing Minesweeper! During actual play, you never need to decide _whether_ there's a layout of mines consistent with the clues – you already know there is one.
You're not even trying to identify whether there's a _unique_ layout of mines consistent with the clues. You can certainly ask that question, but it's a bigger question than necessary, because you don't _have_ to nail down the whole layout in one go.
All you're trying to do, in actual Minesweeper play, is to identify _one_ square which is definitely _not_ a mine. Then you open that square, gaining another clue. Repeat until you've opened all non-mine squares, and the game is solved.
That problem may very well also be NP-complete in the general case, but if you restrict it to grids generated by Mines's own algorithm, it's soluble in polynomial time.
@simontatham I just replaced the mines version I had been playing for the past few weeks with yours, because yours is solvable.
I'm happy to spend some time brooding over a difficult problem and don't care about speed. I did hate ending up guessing in the other version time and again. I may have overlooked clues occasionally, but certainly not as often as I ended up stuck.
@simontatham
I play Light Up several times per day and never found an unsolvable one (I admit to skip some when I'm are tired, but if I search deep anough I always find a way), I'll find it ard to believe that Mines is different
ps: Thank you, sir
@KyleBorah it's called "Portable" Puzzle Collection because it runs on many platforms – there are desktop versions for Windows, Linux and (currently unmaintained) Mac, the same code compiles to WASM and runs in a browser, and there are half a dozen ports to other platforms downstream of me that I know of. And probably at least a few I don't.
I have no real idea of how you support screen readers in application software at all. Last I heard there weren't any standard APIs for it. Also I'm not even sure what a screen reader for Mines would _say_? What kind of verbal user interface do you have in mind for a grid-based game of this kind?
But if you think it's easy, patches welcome!
Have to confess, I loved this game. Haven't seen it in ages.
The one puzzle I'd love to see added to your collection is a sliding blocks puzzle like the Sliding Blocks of Huarong. Wikipedia knows it as "Klotski".
I have a version on my Kobo Elipsa ereader, but I would love to have it for my phone and tablet as well.
@agreeable_landfall there's a Klotski implementation in the code base, in fact. It lives in the 'unfinished' subdirectory, under the name 'Slide'.
The reason it's in 'unfinished' is that the game generation is just too slow, and scales very badly with the grid size. I never figured out any way to improve it. But it's playable once a grid is generated.
I and everyone I knew who mineswept raged at those last three clicks at which you had to guess. It was a dishonest game.
Thank you for this.