blank grid until you make the first click; to ensure solubility, it
does not generate the mine layout until that click, and then ensures
it is solvable starting from that position.
This has involved three infrastructure changes:
- random.c now offers functions to encode and decode an entire
random_state as a string
- each puzzle's new_game() is now passed a pointer to the midend
itself, which most of them ignore
- there's a function in the midend which a game can call back to
_rewrite_ its current game description.
So Mines now has two entirely separate forms of game ID. One
contains the generation-time parameters (n and unique) plus an
encoding of a random_state; the other actually encodes the grid once
it's been generated, and also contains the initial click position.
When called with the latter, new_game() does plausibly normal stuff.
When called with the former, it notes down all the details and waits
until the first square is opened, and _then_ does the grid
generation and updates the game description in the midend. So if,
_after_ your first click, you decide you want to share this
particular puzzle with someone else, you can do that fine.
Also in this checkin, the mine layout is no longer _copied_ between
all the game_states on the undo chain. Instead, it's in a separate
structure and all game_states share a pointer to it - and the
structure is reference-counted to ensure deallocation.
[originally from svn r5862]
both get passed a pointer to the game_ui. This means that if they
need to note down information for the redraw function about what
_type_ of flash or animation is required, they now have somewhere to
do so.
[originally from svn r5858]
puzzles, rather than just doing its nondeterministic number
placement thing. This enables the use of the `Solve' menu option on
externally entered game IDs, provided of course that they aren't
_too_ difficult.
[originally from svn r5852]
Jacob wasn't able to find a satisfactory fix: the whole area was a
horrid mess. Fortunately, the reason it was a horrid mess was
because the Net drawing routines predated the introduction of clip()
in the frontend interface, and it turns out that clip() makes it
possible to do all this more easily and better. So, a complete
rearchitecting of barrier corners: the corner flags in the
`barriers' array are now gone (and good riddance), and corner
information is computed on the fly so as to take into account the
moving grid edges. In the process I've also updated the corner
mechanism so that a barrier `corner' (really endpoint) is drawn at
the end of _every_ barrier, not just where two meet. This has
changed the appearance of a single isolated barrier, to what I would
have wanted it to look like in the first place but achieving it
without clip() was just too fiddly.
[originally from svn r5846]
[r5844 == 865e8ad6ca3d83ad2a585ceeb1809e9f68c18a20]
(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]
unique solution. This, it turns out, is because there is literally
no such thing. Protective constraint added to validate_params(),
with a proof in a comment alongside.
If you really want a 2xn or nx2 wrapping puzzle, you can still have
one if you turn uniqueness off.
[originally from svn r5835]
The previous checkin stopped it choking on them, but it didn't
actually manage to _deduce_ that all the edges bordering them had to
be closed. Now it does better.
[originally from svn r5829]
over on a grid containing a 0 (completely blank) tile. This can't
happen in self-generated grids, but can happen if you type in a grid
from another Net implementation. Previously, the solver would notice
(technically correctly!) that a completely blank tile connects to no
other tiles and thus forms an isolated subgraph, and would therefore
complain that no orientation of that tile could possibly yield a
valid solution...
[originally from svn r5828]
- 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]
from the currently configured ones, and then bring the Random Seed
box back up, the wrong parameters get shown, and the resulting
random seed is incorrect for the current game.
At least, it was, until this checkin.
[originally from svn r5808]
cross-platform, and rename the environment variables so that they
follow the puzzle name. Should allow a static environment
configuration for each puzzle. Also introduced a <game>_PRESETS
variable for people whose favourite configuration isn't on the Type
menu by default.
[originally from svn r5801]
particularly useful keypress, particularly given how easy it is to
confuse it with `Redo'. So both r and ^R are now Redo, and Restart
is relegated to being a menu-only option.
[originally from svn r5796]
Gareth and I have been using to analyse the game, and also the
number pad. They don't work sensibly for all sizes, but they'll be
handy for the most common ones.
[originally from svn r5793]
of the undo list rather than destroying it. Partly this is because
accidental restarts are a real pain, and partly because it allows
you to compare the initial to the current state by restart-then-undo
which is handy in some puzzles.
In order to do this, I've introduced an additional per-entry field
in the undo list in the midend, which tracks which states were
created by `unusual' operations (Solve and Restart). The midend
takes care of suppressing animation and completion flashes during
transitions between a `special' state and its predecessor, relieving
the game backends of having to do it individually.
(This probably means I could remove some complexity in the
flash_time() functions in most backends, but I haven't done that in
this checkin.)
[originally from svn r5791]
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]
takes place in a checked-out copy. Also added mkunxarc.sh which does
the same version determination before building its archive.
[originally from svn r5782]
ends. Versioning will be done solely by Subversion revision number,
since development on these puzzles is very incremental and gradual
and there don't tend to be obvious points to place numbered
releases.
[originally from svn r5781]
keypad. The reason it doesn't is because front ends were carefully
translating the numeric keypad into 8-way directional keys for the
benefit of Cube. Therefore, a policy change:
- front ends process the numeric keypad by sending MOD_NUM_KEYPAD |
'3' and similar
- front ends running on a platform with Num Lock SHOULD do this
_irrespective_ of the state of Num Lock
- back ends do whatever they see fit with numeric keypad keys.
Result: the numeric keypad now works in Solo, and also works in OS X
Cube (which it previously didn't because I forgot to implement that
bit of the front end!).
[originally from svn r5774]
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]
