In general, when looking at these situations, you want to click on the squares that are the least likely to contain mines. This will invariably give you more information about your current situation.

Here's an example of a game that can't be beaten without strict testing, which I will use to demonstrate what I mean.

There are two mines remaining. I apologize, but the 3 underneath the square labeled 2 actually has two adjacent flags, and needs one more flag; one of them was cut off in the screenshot.

Because there is a 1 next to 1 and 2, I know that one of these must be a mine. If 1 is a mine, then 2 is not, which means one of 4, 5, 6 is a mine, and 3 is not. This gives three cases when 1 is a mine.

If 1 is not a mine, then 2 is a mine. If 2 is a mine, then none of 4, 5, 6 is a mine, which means 3 must be a mine. This has only one case.

Therefore, the number of cases where 1 is a mine is 3/4; the number of cases where it is not is 1/4. We can proceed assuming that 1 is a mine - and as it happens to turn out, it is.

Here's another example of a possible setup. The method I use in these cases effectively can be extended across the entire board (which makes it a bit more accurate), but I only execute it a few levels in my head. Here's how my thought process works:

We can see that if 5 is a mine, then 4 can't be, which means 3 is. At this point, either 1 or 2 could be a mine, which gives two cases.

If 5 isn't a mine, then 4 must be a mine, which means 3 isn't, which means both 1 and 2 are - which gives one case.

Therefore, the situation in which 5 is a mine covers 2/3 of the cases, and the situations in which 5 isn't covers 1/3. Therefore, we proceed on the assumption that 5 is a mine.

Of course, there are more than three cases for the entire grid - this is only a rough estimate. I could go into further detail about what the squares above 1 and 2 could be, as well as the surrounding squares, but I won't here. It all depends on how long you want to take and how accurate you want to be.

Generating the grid is simple. There are a couple simple algorithms that you need when executing the player's move, to determine which squares to open up and whether they have lost or won.

Generating the grid

The simplest algorithm is to place all of the mines randomly. (Make sure you don't overlap them!)

Problem: The player's first click might be a mine.

Improvement: Delay the generation of the grid until the user clicks on the first square, and don't put any mines in that square.

Problem: The player's first click might reveal a non-zero number, and they will be forced to click randomly until something opens up.

Improvement: Don't generate any mines in the (up to) eight squares around the first click, either.

Problem: The player might be forced to guess at some point, making this a sad excuse for a logic puzzle.

Improvement: Run the solver alongside the generator, making sure that the puzzle has a unique solution. This takes some cleverness, and isn't done in most variants.

Another, less common way to resolve ambiguities is to detect when the player knows they are choosing between equally likely possibilities and "collapse the waveform" into the position they decided on. I have never seen this in action, but it would be kind of fun.

Playing the game

Besides marking flags, the player can make two kinds of moves to attempt to uncover squares:

• Single guess: The player clicks on a square with unknown state and no flag. Reveal the square, see if the player died, and put a number in it. If the square contains a 0, repeat this recursively for all the surrounding squares. This should be in a dedicated function, to separate it from the GUI's event handler, to make the recursion easy, and because it's reused in the multiguess.

• Multiguess: The player clicks on a square that is uncovered and known to be safe. If the number of flags surrounding equals the number in this square, we open up the unflagged squares using the same procedure as above.

Winning the game

If the number of squares that are covered up is the same as the number of mines, then the player has won, even if they haven't placed a flag on every square.

When the player loses, it is customary to mark any incorrect guesses that they made, the remaining mines, and the mine that they stepped on.

It is better to start in the corner in Minesweeper. The reason for this is simple: corners are the most likely place for logically unsolvable positions. The more corners you remove, the greater the chance you'll be able to solve the puzzle, regardless of mine density. Since your starting move can't be a mine, starting there reduces the chance of being stuck on a corner by 25%.

The reason corners are the most likely place for unsolvable positions is simple: you have very few clues there. Note that this will also tend to generate smaller starting cleared areas when you start in the corner, but this isn't generally a hindrance.

You are additionally not much more likely to have a faster game if you start in the corner. The reason for this is simple: until you run out of options, you're always executing further options. If a region would have been cleared by clicking in the middle of the puzzle, it will be cleared when you reach it normally. In this sense, you wouldn't actually be saving time by clearing the middle region, because you'll inevitably clear it anyway.