Bombe[0] is to my mind the definitive exploration of this concept. The tagline is "Minesweeper, but you only solve each situation once", which you do by writing these kinds of deduction rules with a fairly painful visual programming language. (You can't write an invalid rule: the game will detect the logic error and present you with a counter-example.)
You then let the computer churn through it's list of 100k scenarios idle-game style, until you bump into a board that can't be solved with the rules you provided, and you have to figure out what new rules to write.
As the game progresses, you'll unlock ways of parameterizing the rules in various ways, as well as various variant rules.
As an experiment, I tried clicking on a random position after clicking the starting point. And it is possible to that the position is safe. So I don't think the map in no guessing mode is dynamic.
Also in the help section: "In this mode, a starting position is provided, and you never need to guess to complete the board."
Are they all valid, and do they prove that the location you're clicking on is empty? Then you're not guessing.
Are they invalid, or do they not prove that the location is empty? Then you're making a guess that should fail.
Are they valid, comprehensive (there are no more bombs you could mark), and prove that all you have left are random choices? Then clicking is you indicating that you've found all there is to find for now, not a "guess".
I will second the recommendation. As someone who's wasted too many hours on minesweeper, it radically changes the game. Because I know there's a logical solution, I'm able to find patterns that I never found in the original, because I'd often assume it was just one of those guesswork situations. It's similar to how chess puzzles are easier than an equivalent position during a game. Because you know there's a neat solution, you're more willing to put in the legwork of searching for it. Learned a lot about the game simply by playing Simon's version.
For the vanilla game the guesses become integral part of the game that you can strategize around. There are guesses where some squares are less likely to contain mines than others. You can also try to uncover guesses as early as possible in a game, so you don't waste too much time on a game that is doomed to fail.
it's also available on windows and android - very good.
https://www.chiark.greenend.org.uk/~sgtatham/puzzles/js/mine...
However, the minesweeper puzzle is the one that causes a big wart in the API, which part of me has wanted to refactor for years. (it's for the reason given in GP comment, the puzzle isn't generated until first click; it's the only one with this behavior and could be reworked to have the clicked area be a parameter to creation, but then it would have a slightly quirky main()-equivalent function.. IMO worth it for the cleaner API)
Simon's puzzles have overall been an inspiration, some good reading if you're into algorithms and applied graph theory and don't mind that it's in C.
Could you explain how? I haven't played a huge amount of Minesweeper, but I can't see how that can be solved without risk/luck.
https://agustinfitipaldi.com/minesweeper?seed=eyJ3aWR0aCI6OS...
Anyone know what minesweeper software I'm thinking of?
It’s a bit mind bending as you’re never actually solving the puzzles yourself, but creating sets of rules to solves whole classes of potential minesweeper patterns. It definitely solves that pleasurable puzzle solving itch!
greentec•3d ago
Thank you for your interest in my previous post. This time, I've written a blog post about the game and the process of creating it.
In the original Minesweeper, there are inevitable 50/50 moments where you have to rely on luck. In the game I created, 'Explainable Minesweeper,' I eliminated these guessing situations. However, I also prevented the maps from becoming too easy! How? By using logical deduction, you can solve puzzles that initially appear to be luck-based. The blog post explains the process in more detail.