Re: [Enigma-devel] level submission: minesweeper

[Ronald Lamprecht]

Hi,

Andreas Lochmann wrote:
> thank you, this level is really interesting!
> I particularly like that it's not exactly Minesweeper, but
> twisted by a typically Enigmian obstacle: You can "open"
> only those tiles which are adjacent to another "open"
> tile (or the border).
>
> But there's one fundamental problem: It's not always
> solvable. Minesweeper in itself is not always solvable,
> and the above peculiarity worsens this ... I thought about
> this since yesterday, but can't come up with a good
> idea yet ...
>
> Well, maybe some kind of "inverse Minesweeper":
> You see all tiles and their numbers (numbers also on the
> mine-fields), have to touch those without mines, after
> which these numbers disappear. Provided that the border
> is mine-free and that the set of mine-free tiles is connected,
> we can proove solvability. But that's not Minesweeper
> anymore.

I do like the approach of marking the bomb free fields by moving the 
marble over them. That is a fast input much better than clicking :-)

The problem of unsolvable bomb distributions can be fixed by a simple 
algorithm. All bomb free fields must be connected to the outside area by 
direct path. For all bomb free fields of the border mark all reachable 
fields by a recursive depth run. Marking all visited fields allows to 
limit the recursive depth run to those border fields that are not yet 
marked.

This would reduce the problem to bomb distributions that are not 
"solvable" due to the intrinsic ambiguity.

A simple solution would be to set enigma.ConserveLevel to TRUE and 
provide a panelty that keeps players from misusing it. E.g. an it-weight
on each resurrection would be fair. That would be o.k. for solving one 
or two last ambiguities by trial. But it should keep players from using 
it on a regular basis.

Of course you are welcome to write an algorithm that rejects ambiguos 
bomb distributions. This would allow you to give the user a solvable 
start of a few opened fields, too. But the algorithm might be more complex.

Either way, thanks for your contribution,

Ronald