Rather than revealing the entire mine layout when you die, we now
only reveal the one mine that killed you. You can then Undo and
continue playing, without having spoiled the rest of the grid for
yourself. The number of times you've died is counted in the status
line (and is not reduced by Undo :-).
Amusingly, I think this in itself is quite a good way of dealing
with ambiguous sections in a Minesweeper grid: they no longer
_completely_ spoil your enjoyment of the game, because you can still
play the remainder of the grid even if you haven't got a completely
clean sweep. Just my luck that I should invent the idea when I've
already arranged for ambiguous sections to be absent :-)
[originally from svn r5886]
(Adding modifier+cursors handling has had minor knock-on effects on the other
puzzles, so that they can continue to ignore modifiers.)
(An unfortunate side effect of this is some artifacts in exterior barrier
drawing; notably, a disconnected corner can now appear at the corner of the
grid under some circumstances. I haven't found a satisfactory way round
this yet.)
[originally from svn r5844]
number. Many thanks to Chris Thomas, for helping with the detailed
UI design by means of testing an endless series of prototypes.
[originally from svn r5842]
- fix documentation of Net's unique solution option (should have
tested before last checkin)
- make unique solutions optional in Rectangles too (same reasons)
- tidy up various issues in parameter encoding in both games.
[originally from svn r5818]
enabled by default), since ambiguous sections in grids can present
additional interesting challenges. I think uniqueness is a better
default, though.
[originally from svn r5816]
puzzles. I generate the grid of rectangles as normal, but before I
place the numbers I run it through a non-deterministic solver
algorithm which tries to do as much as it can with as little
information about where the numbers are going to be. The solver
itself narrows down the number placement when it runs out of steam,
but does so as little as possible. Once it reaches a state where it
has ensured solubility, and then the generation algorithm chooses
random number placement from whatever's left.
Occasionally it paints itself into a corner and can't ensure a
unique solution no matter what happens; in that situation we just
have to give up, generate a fresh grid, and try again.
[originally from svn r5809]
rather than literal grid descriptions, which has always faintly
annoyed me because it makes it impossible to type in a grid from
another source. However, Gareth pointed out that short random-seed
game descriptions are useful, because you can read one out to
someone else without having to master the technology of cross-
machine cut and paste, or you can have two people enter the same
random seed simultaneously in order to race against each other to
complete the same puzzle. So both types of game ID seem to have
their uses.
Therefore, here's a reorganisation of the whole game ID concept.
There are now two types of game ID: one has a parameter string then
a hash then a piece of arbitrary random seed text, and the other has
a parameter string then a colon then a literal game description. For
most games, the latter is identical to the game IDs that were
previously valid; for Net and Netslide, old game IDs must be
translated into new ones by turning the colon into a hash, and
there's a new descriptive game ID format.
Random seed IDs are not guaranteed to be portable between software
versions (this is a major reason why I added version reporting
yesterday). Descriptive game IDs have a longer lifespan.
As an added bonus, I've removed the sections of documentation
dealing with game parameter encodings not shown in the game ID
(Rectangles expansion factor, Solo symmetry and difficulty settings
etc), because _all_ parameters must be specified in a random seed ID
and therefore users can easily find out the appropriate parameter
string for any settings they have configured.
[originally from svn r5788]
additional configuration parameter, which is the number of shuffle
moves. By default the grid will be fully shuffled so that you need a
general solution algorithm to untangle it, but if you prefer you can
request a grid which has had (say) precisely four moves made on it,
and then attempt to exactly reverse those four moves.
Currently this feature is only available from the Custom box, and
not in any presets.
[originally from svn r5769]
the missing fifth difficulty level to Solo: `Unreasonable', in which
even set-based reasoning is insufficient and there's no alternative
but to guess a number and backtrack if it didn't work. (Solutions
are still guaranteed unique, however.) In fact it now seems to take
less time to generate a puzzle of this grade than `Advanced'!
[originally from svn r5756]
various things:
- if you haven't fully understood what a game is about, it gives
you an immediate example of a puzzle plus its solution so you can
understand it
- in some games it's useful to compare your solution with the real
one and see where you made a mistake
- in the rearrangement games (Fifteen, Sixteen, Twiddle) it's handy
to be able to get your hands on a pristine grid quickly so you
can practise or experiment with manoeuvres on it
- it provides a good way of debugging the games if you think you've
encountered an unsolvable grid!
[originally from svn r5731]
enable configurable puzzle difficulty. I'm only generating grids up
to Times level (complicated non-recursive analysis but guessing
never required); I wouldn't object to providing a Telegraph
difficulty level (guessing required) but it turns out to be very
hard indeed to generate at random. I might still add it later
(probably under the name `Unreasonable' :-) if I can think of an
efficient way to find them.
[originally from svn r5682]
the default symmetry from order-4 down to order-2, which seems to
mitigate the excessively-full-grid problem by permitting more
freedom to remove stuff.
[originally from svn r5666]
of the manual using Halibut (with one additional magic tag in the
<HEAD> section), stuck it in the right part of the application
bundle, referenced it in Info.plist, and added a Help menu.
Everything else was automatic. Not bad!
[originally from svn r5190]
tiles randomly. (Rachel asked for this; it's been being tested for a good few
months now, and Simon didn't care either way, so in it goes :)
As part of this, the front end can now be asked to provide a random random
seed (IYSWIM).
[originally from svn r5019]
of puzzle. Configurable option, turned off by default, and not
propagated in game IDs (though you can explicitly specify it in
command-line parameters, and the docs explain how).
[originally from svn r4461]
