Okay, it seems that there is some uncertainty about what exactly a "lucky mode" entails and should be. Thus I think this would be a good time to outline what exactly the lucky mode, which I am proposing, is; what it's aims are, and how exactly it will work. The best place to start, however, is to give a good outline of what a lucky mode should be.

The most basic and general aim of a lucky mode is to eliminate the effect of forced guesses from a ranking which is meant to measure skill, not luck. While it is true that forced guesses are not the only (and probably not the most important) probabilistic element in the system as we have it today, it is imo by far the most annoying. This is why I've been working on a way of eliminating forced guesses from the gameplay itself based on the constraint satisfaction approach discussed in

Raphaël Collet's article, "

Playing Minesweeper with Constrains" (even before my blast

). Well, the first thing I want to discuss is what can be defined as a good lucky mode, and why. It is important to note that this definition is in the context of speedsolving. But it doesn't really lose much of it's appeal in other contexts.

Here is an ad hoc list of general properties to illustrate this definition:

- The most important property of a good lucky mode is that it has as small as possible of an effect on the distribution in the "speed-difficulty" (how hard it is to get a fast time) of boards faced by the player. At the moment the standard for measuring this is 3BV (and the emerging ZiNi implementations), and I will stick to that in this post. The reason for this is simply as was said before: We don't want to change minesweeper completely from what it started as.
- The optimal strategies to deal with forced guesses is as far as possible unaltered. This is a gray point, because if one of these strategies is altered only slightly (not in such a big way as Tommy suggests), it takes the same close reasoning skills on the part of the player to realize this change and utilize it. It can easily be argued that if the gains of the two strategies in the two regimes are comparable, then the game was in fact not truly changed. This is of course very gray
- Only forced guesses are eliminated. This is a very subtle condition, and has to be considered carefully in context of the previous points. The most important thing is to only eliminate guesses the player can possibly discern as being forced guesses, and to not eliminate them before this. This condition stems from the idea that players can skew the probabilities of unforced guesses of the same form to gain a considerable advantage. This condition excludes most MSlive-like approaches, as these approaches eliminate the need for the player to be able to recognize a forced guess above an unforced one.

These points are of course not the complete list, but they are a start. I feel it important to restate the point that only

force guesses which the player can possibly identify, using the information available on the board, are to be eliminated. This basically means that the player still has to solve the problem of whether or not it in fact is a guess.

Okay, now for a basic outline of what the article of

Raphaël Collet's says, and how it pertains to this problem...

The basic idea of the article is that a minesweeper game can be reduced to the solution of a set of equations which are determined by (1) the total number of mines on the board, and (2) the uncovered squares in the format

x1 + x2 + x3 + x4 + x5 + x6 + x7 + x8 = N(x0)

where N(x0) is the number in square x0, and x1-x8 can take the values 1 or 0 (1 for a mine and 0 for a safe square)

Example- Code: Select all
`? ? ? x1 x2 x3`

? 2 2 x4 x0 x5

1 2 0 x6 x7 x8

would correspond to the following equation:

x1 + x2 + x3 + x4 = 2

This is, of course not the end of the story. It turns out that to do more advanced logical tricks (like the 1-in-a-hole) you need to group the squares adjacent to a number into appropriate subgroups (the "top row" etc) and generate further equations from them. Thus our example actually implies the following equations: (I'm not entirely sure about the two element groups, but kinks are for later

)

x1 + x2 + x3 + x4 = 2

[x1,x2,x3] + x4 = 2

[x1,x2] + x3 + x4 = 2

[x1,x4] + x2 + x3 = 2

[x1,x4] + [x2,x3] = 2

The reason for this is that some of the logical tricks rely on groups of squares sharing mines.

Once these equations have been set up, it is a simple matter of recursively finding an equation in the entire set which has only one term on the left, and implying it throughout the entire set. You of course need to give it some starting information, but that's not the point.

After reading this in his article I realized that this is

exactly how we solve minesweeper boards! Beautiful heh? Interestingly, Sudoku is a similar constraint satisfaction problem.....

But I digress.....

This brings me to the relevance of this to our current discussion. The key is to notice that in situations where a player is forced to guess, the set of equations describing that position will reflect this. More specifically,

the set of equations will contain a subset which is under-determined and disjoint from the rest of the equations in the set excluding the equation dealing with the number of mines on the whole board, which the set of solutions of the subset will leave unchanged. (this is very vague, but I'm not going into programming grit here....)

Just quickly for those not familiar with the terms..... Under-determined: There are more variables than equations..... disjoint: the variables in the subset don't appear in it's compliment (outside it)

That basically describes the basis of the lucky mode I propose... The specifics of it's implementation are of little importance at this stage....

In our discussion of this idea, Cryslon and I have found only 2 serious con's in this approach. The first is the problem Tommy mentioned:

Tommy wrote:What about situations where you have to guess, but opening one particular square will resolve the whole situation

Well, because of the stringent nature of a guess being defined as "forced", this problem has a very small effect, and is arguably rendered moot due to the similar close reasoning required to arrive at negligibly different results.

The second is the problem of "surrounded square" forced guesses (or, as I like to call them: "Traps"), and their linked nature. Basically, if you have more than one trap on the board they together will form a forced guess if all other squares are open. The problem is that these can only be resolved right at the end of the game, even though they are also forced guesses on their own. The plus side of this problem is that always resolving these as lucky will cost such a high price to players that they probably wouldn't utilize it much in serious play, and it would thus not affect the statistics

There may be more, but I've not found them....

A positive of this method is that the problem Tommy states in the previous post does not exist in this implementation, because what he shows is not necessarily a forced guess (in his expanded picture). The very fact that "a" can influence, and is influenced by the squares of the 50/50 shows this.

Anyhow, that's lucky mode as I see it. And in case you where wondering, I'm completely in favor of eliminating limits on int and exp completely, and leaving that job up to pure statistics; removing 50/50's completely in the way I've just proposed; and in eliminating the probabilistic effects of 3BV-like properties on the measurement of skill which is a world ranking.... (but more on that some other time)