| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
| |
[originally from svn r5800]
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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]
|
| |
|
|
|
|
|
|
| |
computers, let's save the Solo and Pattern grids at generation time
and regurgitate them when asked to solve, rather than doing all the
work over again.
[originally from svn r5737]
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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]
|
| |
|
|
|
|
|
|
|
|
| |
constructed at the same time as an internally generated game seed,
so that it can preserve any interesting information known by the
program at generation time but not physically contained within the
text of the game seed itself. (Such as, for example, the solution.)
Currently not used for anything yet, but it will be.
[originally from svn r5729]
|
| |
|
|
|
|
|
|
| |
as text. This is used by front ends to implement copy-to-clipboard.
Currently the function does nothing (and is disabled) in every game
except Solo, but it's a start.
[originally from svn r5724]
|
| |
|
|
|
|
|
|
|
| |
definitions, so let's move it so that it's just next to the
functions it relates to. This also opens the way for me to add more
booleans next to other functions without getting confused as to
which is which.
[originally from svn r5723]
|
| |
|
|
|
|
| |
interface to it just in case it comes in handy.
[originally from svn r5686]
|
| |
|
|
|
|
|
| |
column of the same colour (at least when the dimensions are big
enough to make this feasible). It's a little bit too easy otherwise!
[originally from svn r5391]
|
| |
|
|
|
|
| |
grid dimensions are very small.
[originally from svn r5390]
|
| |
|
|
|
|
|
|
|
| |
edges and the bottom/right ones. Fix it. (Also remove it from the
todo list in osx.m, where I had entered it in the assumption that it
was a bug in my new OS X port! Turns out it's an entirely platform-
independent bug.)
[originally from svn r5187]
|
| |
|
|
|
|
|
|
|
|
| |
functions and a couple of variables, now each one exports a single
structure containing a load of function pointers and said variables.
This should make it easy to support platforms on which it's sensible
to compile all the puzzles into a single monolithic application. The
two existing platforms are still one-binary-per-game.
[originally from svn r5126]
|
| |
|
|
|
| |
[originally from svn r4955]
[r4954 == 47e9419452a9fca895f1c84412ab1040d1aa86a5]
|
| |
|
|
|
|
| |
lingering GRID_UNKNOWN, causing it to declare victory too soon.
[originally from svn r4954]
|
|
|
[originally from svn r4953]
|
