Changed my mind about midend_is_solved: I've now reprototyped it as

midend_status(), and given it three return codes for win, (permanent)
loss and game-still-in-play. Depending on what the front end wants to
use it for, it may find any or all of these three states worth
distinguishing from each other.

(I suppose a further enhancement might be to add _non_-permanent loss
as a fourth distinct status, to describe situations in which you can't
play further without pressing Undo but doing so is not completely
pointless. That might reasonably include dead-end situations in Same
Game and Pegs, and blown-self-up situations in Mines and Inertia.
However, I haven't done this at present.)

[originally from svn r9179]
This commit is contained in:
Simon Tatham
2011-06-19 13:43:35 +00:00
parent 8dcdb33b77
commit 73daff3937
42 changed files with 188 additions and 164 deletions

View File

@ -1535,9 +1535,9 @@ static float game_flash_length(game_state *oldstate, game_state *newstate,
return 0.0F;
}
static int game_is_solved(game_state *state)
static int game_status(game_state *state)
{
return state->completed;
return state->completed ? +1 : 0;
}
static int game_timing_state(game_state *state, game_ui *ui)
@ -1628,7 +1628,7 @@ const struct game thegame = {
game_redraw,
game_anim_length,
game_flash_length,
game_is_solved,
game_status,
TRUE, FALSE, game_print_size, game_print,
FALSE, /* wants_statusbar */
FALSE, game_timing_state,