106 Commits

Author SHA1 Message Date
90560462c4 First cut at a game timer. Yet another backend function which
indicates whether a particular game state should have the timer
going (for Mines the initial indeterminate state does not have this
property, and neither does a dead or won state); a midend function
that optionally (on request from the game) prepends a timer to the
front of the status bar text; some complicated midend timing code.

It's not great. It's ugly; it's probably slightly inaccurate; it's
got no provision for anyone but the game author decreeing whether a
game is timed or not. But Mines can't be taken seriously without a
timer, so it's a start.

[originally from svn r5866]
2005-05-30 16:15:34 +00:00
7ddaa1382f D'oh, there's always one. Remove first-click stuff from the todo list.
[originally from svn r5863]
2005-05-30 13:11:05 +00:00
0564c4c4d0 Mines now follows the conventional approach of offering a completely
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]
2005-05-30 13:10:37 +00:00
7ff09fbba1 Neat idea from Gareth: if you put a % on the end of the mine count
in the Custom dialog box, it'll treat it as a mine density.

[originally from svn r5861]
2005-05-30 12:24:31 +00:00
6e7421a3ba Nit: "warning: extra tokens at end of #endif directive"
[originally from svn r5860]
2005-05-30 11:49:08 +00:00
6b9e690c89 Initial checkin of my Minesweeper clone, which uses a solver during
grid generation to arrange a mine layout that never requires guessing.

[originally from svn r5859]
2005-05-30 10:08:27 +00:00