Minesweeper thermodynamics
oscarcunningham.com
oscarcunningham.com
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: https://github.com/yshklarov/minesweeper
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.
A) No place for luck at all, either by making the game "forgiving", or generating a game that never has an ambiguous block, or
B) The game should make luck's presence more constant.
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.
Because of this, I'd keep this logic game be about logic, or work luck into the game more deeply.
Solitaire is similar, with some of its starting positions being outright unwinnable. I'd just filter these out when creating a new game.
Minesweeper is more like a quirky old wooden board game, charming because it's always been what it is, warts and all.
In practice I suspect a SAT solver would make quick work of the positions that actually appear in games.
(Edit: Here it is! https://pwmarcz.pl/kaboom/ And the write-up: https://pwmarcz.pl/blog/kaboom/ )
This is similar in spirit to my take on the game: https://magnushoff.com/articles/minesweeper/
Unfortunately, not being familiar with SAT solvers, my implementation can grind to a halt in some configurations :)
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.
This variant takes out the luck part.
Like the Greeks and Babylonians we usually measure it in degrees. Later around 18th century radians started getting used, especially in power series expansions.
In India, historically, angle was measured in the units of length (for a standardized circle). That made functions like sin be a function from length to length.
i.e. a variant of radians? A radian is the circular arc whose length is equal to the radius. If we standardise the unit circle then a radian is a length of 1.
What Indian mathematicians typically used was a circle with radius 3438 units. Where units would be one of the standard units of length.
Why 3438 you may wonder.
They also wanted to divide the circle into 360 x 60 minutes. For the standard circle they wanted each of those minute arcs to be of 1 unit length. The radius that would accomplish this is (360 x 60)/ 2pi ~= 3438 units.
An angle of 1 minute would then be described as arc length 1 unit on that standardized circle of radius 3438 units.
Indian version of sine and cosine were not expressed as ratios but the corresponding (half) chord for a hypotenuse of 3438 units.
I do dislike the fact the libc sin takes argument in radians. For two reasons. One, the angles in the application are rarely in radians, so they need to be converted before the function call. Two, I would like the standard angles, such as the multiples of 15 degrees to have an accurate representation in 32 bits (or 64 bits).
Anyhow this is way off topic.
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).
it's a flash game, that had an android release at some point (it was removed from the store for some reasons)
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.
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.
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.
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.
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.
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...)
I like Dragonsweeper (discussed in a sibling comment) because it has a more clear probability and information tradeoff.
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.
The HexCells series is also worth a look for anyone interested in pure logic Minesweeper.
If you click on the square three to the right of the top 1, if that shows a 1, then a lot of surrounding squares can be revealed and again you may "walk up" to a more definitive mapping of the bombs.
I'm not even sure those are the optimal examples, but when I minesweeper it was for speed.
The real advantage, especially at this stage of the puzzle, is that those squares might quickly lead to another big field to be revealed.
The author’s math considers how mines would be distributed if mines were distributed to the empty squares after reaching that board state.
This is wrong.
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.
It invalidates all of the numbers after this point.
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.
Whereas in Minesweeper we've just blindly stumbled across a situation where we have to guess.
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.