I hacked up a version of minesweeper that was “forgiving:” if there was no selection that was provably safe, it gave you a safe move. If you picked any square that was not provably a bomb, it would not be a bomb.
Typically, as long as you don’t select a number of bombs equal to the number of squares , your first move is safe. I just extended that for the whole game.
If you select N-1 bombs, you always win on the first move..
Simon Tatham's _Mines_ deals with this in a different way: it generates the mine positions in such a way that they can never lead to an ambiguous state during a game. <a href="https://www.chiark.greenend.org.uk/~sgtatham/puzzles/doc/mines.html#mines" rel="nofollow">https://www.chiark.greenend.org.uk/~sgtatham/puzzles/doc/min...</a>
That's pretty neat. I wonder how it works. It's not obvious to me at all how to build something like this, as the program doesn't know the sequence in which the player will reveal the tiles.<p>I also once made my own variant of this (just like
gregfjohnson's idea): A "lucky minesweeper" where luck can be toggled on/off at any point during the game: <a href="https://github.com/yshklarov/minesweeper" rel="nofollow">https://github.com/yshklarov/minesweeper</a>
There is a Korean indie game made in RPG Maker MV that pushes this idea to the extreme, titled <i>How can I be a brave in the isekai while I suck even at the minesweeper's novice level?!</i> (rough translation, original: 지뢰찾기 초급을 겨우 깰까말까한 내가 이세계에서는 용사라고?). Too bad it's only available in Korean.
> a version of minesweeper that was “forgiving:”<p>I think this diminishes the game. Sometimes you just don't have enough information to know for sure. Experiencing this in a low stakes situation like a minesweeper game reminds us that life is like that sometimes and we just have to make a guess and accept the consequences.
Yes, this really depends on what one's expectations are of a "game". Luck, as a component, is often contested. In case of the minesweeper, I'd argue there is either<p>A) No place for luck at all, either by making the game "forgiving", or generating a game that never has an ambiguous block, or<p>B) The game should make luck's presence more constant.<p>In case of Minesweeper, the most unfair event is when after a lot of pure skill-based play, the outcome ends up being luck based. As a game mechanic, this can work out to be challenging, or work as a surprise the first time, but it gets old pretty fast - because why bother putting in all that skill, just so be judged by luck in the end? And those who are thrilled by luck checks, will be turned away from the game because the exciting part comes last.<p>Because of this, I'd keep this logic game be about logic, or work luck into the game more deeply.<p>Solitaire is similar, with some of its starting positions being outright unwinnable. I'd just filter these out when creating a new game.
Agree completely. The luck aspect kinda wrecked minesweeper for me. It's a super fun simple game, but after spending a lot of effort logic-ing my way through it, only to have to take a 50/50 or worse guess toward the end and have it blow me up, is deeply unsatisfying. When it comes at the beginning (that first block can be a bomb after all) it's not too bad, but at the end isn't cool
This is why Slay the Spire is as loved as it is -- clearly defined skill and luck checks delivered one after the other at the precise limits of your ability.<p>Minesweeper is more like a quirky old wooden board game, charming because it's always been what it is, warts and all.
I actually like the idea that it's always solvable. Like a sudoku puzzle. If a sudoku isn't solvable through logic, but requires guessing, it's considered an invalid puzzle.
Ha! This is NP-Complete, no? In practice, it probably doesn't matter but my bet is that there are some configurations that will take exponential time to see if the player should be "forgiven".
Yeah, it's NP-complete to decide whether a cell in Minesweeper must be a mine: <a href="https://logic.pku.edu.cn/ann_attachments/np.pdf" rel="nofollow">https://logic.pku.edu.cn/ann_attachments/np.pdf</a>.<p>In practice I suspect a SAT solver would make quick work of the positions that actually appear in games.
There was a Minesweeper on here that used a SAT solver, but I cannot find it at the moment. As I recall, it never had any issue with resolving the board quickly. I think it dynamically resolved where the mines would be as you played the game, and if you clicked a square that could be a mine, it would be a mine, except, I believe, when there were no open squares that were safe.<p>(Edit: Here it is! <a href="https://pwmarcz.pl/kaboom/" rel="nofollow">https://pwmarcz.pl/kaboom/</a> And the write-up: <a href="https://pwmarcz.pl/blog/kaboom/" rel="nofollow">https://pwmarcz.pl/blog/kaboom/</a> )<p>This is similar in spirit to my take on the game: <a href="https://magnushoff.com/articles/minesweeper/" rel="nofollow">https://magnushoff.com/articles/minesweeper/</a><p>Unfortunately, not being familiar with SAT solvers, my implementation can grind to a halt in some configurations :)
I wonder if one learned to play faster with this kind of minesweeper.<p>I find in a lot of repetitive learning, you have a very noisy signal, you don't know if you succeeded because of luck or you did something right.<p>This variant takes out the luck part.
I made winsweeper, which will move the mine if there is no safe tile left for you to discover.<p><a href="https://github.com/alaingilbert/winsweeper" rel="nofollow">https://github.com/alaingilbert/winsweeper</a>
Yeah I've debugged another game that attempted this and this system resulted in the game lagging as hard sometimes.
Every version of Minesweeper I've ever played makes your first move safe. I realize this is not going as far as your version, but I've had this argument with ardent players who insist it isn't true (and somehow they've just been lucky, I guess).
Prior art: <a href="https://news.ycombinator.com/item?id=21883875">https://news.ycombinator.com/item?id=21883875</a>
I would also like to auto clear tiles that are unambiguous when I flag a mine. Perhaps by double tapping one of the adjacent tiles
The Windows 7 Minesweeper does something like this on the initial click, I think. You usually get a "good start".
The article discusses Boltzmann's formula exp(-E/kT). I was recently looking at the same formula in the context of semiconductors and I realized that Boltzmann's constant k is only needed because temperature uses bad units. If we measured temperature in energy instead of degrees, then Boltzmann's constant drops out. For instance, you could express room temperature as 25 meV (milli electron volts) or 2444 joules/mole and the constant disappears. Likewise, the constant in the ideal gas law disappears if you measure temperature as energy rather than degrees Kelvin. In other words, degrees Kelvin is a made-up unit that should be abandoned. (I'm not sure I believe this, but I don't see a flaw.)
Yes! Units are up to you (with some constraints)! Physicists do this in practice a lot: <a href="https://en.wikipedia.org/wiki/Natural_units" rel="nofollow">https://en.wikipedia.org/wiki/Natural_units</a>
See: Temperature as Joules per Bit <a href="https://arxiv.org/abs/2401.12119" rel="nofollow">https://arxiv.org/abs/2401.12119</a>
This is true of any units. A lot of physicists say things like "set c=1", does that mean that meters/feet are bad units and we should instead be measuring our height in fractions of c? That sounds inconvenient to me.
Another example that shows up in mid school is how we measure angle.<p>Like the Greeks and Babylonians we usually measure it in degrees. Later around 18th century radians started getting used, especially in power series expansions.<p>In India, historically, angle was measured in the units of length (for a standardized circle). That made functions like <i>sin</i> be a function from length to length.
I don't think temperature would be measured as energy, but rather as energy per information; e.g. joules per bit. Boltzmann's constant defines the degree as one joule per a very large number of bits, to get numbers convenient at macroscopic scales.
Minesweeper is a probabilistic game, that's why you should use probabilistic tools to solve it.<p>For example you can use a particle filter to approximate the distribution of mines. Every time you obtain new information you update the filter so that only distributions compatible with constraints remain.<p>Once you have an approximation to the distribution of mines you can calculate the probability of each spot being a mine. You can also calculate statistical indicator like the Information Gain of each action.<p>A good strategy is therefore to play low mine probability with highest information gain. But there is a trade-off, when the mine probability is non-zero. So you need to look-ahead.<p>Fortunately thanks to the mine distribution approximation you can also simulate any actions and their consequences, because you can use your approximation of the distribution to predict which number will be revealed upon a click.<p>So an even better strategy is to unroll the game tree for the best few candidate moves based on some heuristics, and calculate the cost gain probabilities after a few moves.
Most of the times Minesweeper is deterministic, and you can just think and get an empty spot. From time to time, you are unlucky and has to guess.<p>A few years ago, I modified the version of minesweeper in the "Games" collection of Racket to get more mines per board and get more hard cases. (I added the trick to autoopen the squares that have enough flags around, so it solved all the easy cases and it was more fun. I never upstreamed the changes...)<p>I like Dragonsweeper (discussed in a sibling comment) because it has a more clear probability and information tradeoff.
Only tangentially related, but Dragonsweeper is an interesting extension of minesweeper where you have hit points and the "mines" have attack values. I got a better appreciation for the mechanics of minesweeper by playing it; it's surprisingly deep. <a href="https://danielben.itch.io/dragonsweeper" rel="nofollow">https://danielben.itch.io/dragonsweeper</a>
Similar game: Mamono Sweeper <a href="https://duckduckgo.com/?q=mamono+sweeper" rel="nofollow">https://duckduckgo.com/?q=mamono+sweeper</a> (mamono is monster in japanese)<p>it's a RPG variant of Minesweeper, where you have life points, level up and fight against monster (mines) that gives you xp once killed (you loose HP if you fight a monster higher lvl than you).<p>it's a flash game, that had an android release at some point (it was removed from the store for some reasons)
This is actually a quite interesting game, I played it for like 2 hours when I saw it first time.
Interestingly, the main problem with Minesweeper is that is a game of chance (so the approach discussed in the article is very appropriate).<p>For a minesweeper variant purely based on logic, I highly recommend the game Tametsi. It has 160 handcrafted levels, and some have very interesting geometrical arrangements. I have logged over 100 hours in this game.
There are other squares to click on on the other side of that "probability wall" that might reveal more info at a lesser danger percentage.
How could this be extended to a negative bomb space like in Bombe (<a href="https://store.steampowered.com/app/2262930/Bombe/" rel="nofollow">https://store.steampowered.com/app/2262930/Bombe/</a>)?
At first I thought the "equal probability assumption" wasn't too bad an approximation, but it has an average Brier score of 0.217. Much worse than I thought.
The article makes a serious math error early on.<p>The author’s math considers how mines would be distributed if mines were distributed to the empty squares after reaching that board state.<p>This is wrong.<p>This is classic Monty Hall Problem. The author is doing the equivalent of saying “there are two doors left, so the odds are 50 / 50 that the prize is behind either door.<p>It invalidates all of the numbers after this point.
I don't agree (I'm the author).<p>The difference is that Monty knows which of the doors the car is behind and deliberately avoids it, thereby giving away information about where the car is.<p>Whereas in Minesweeper we've just blindly stumbled across a situation where we have to guess.<p>It would be like if every show Monty always revealed a random door. Sometimes he would reveal the car and the game would end immediately. In the cases when he didn't reveal the car it really would be 50/50 between the remaining two doors.
What would the winrate of a bot doing these calculations be compared to one that doesn't?
now this is time well spent