py_maze py_maze
Source

Saving and loading

Keep a maze in a file and play it back later, and what happens to a file that is not a maze py_maze can read.

--save writes the maze, and any collectibles, to a file:

python -m py_maze -d easy --seed 2024 -c 4 --save maze.txt

maze.txt:

# py_maze save 1
# seed: 2024
* ***********
* *     *   *
* *** * *** *
*   * *     *
*** * *******
*   *       *
* *** ***** *
*   *$*$  * *
*** * * *** *
*   * $$*   *
* ******* * *
*         * *
*********** *

A save file is the maze exactly as it is drawn, under a short header recording the format and the seed it came from. That makes it readable, editable by hand and comparable like any other text file. Lines starting with # are comments, so a note about the maze can be kept alongside it.

--load plays a saved maze back:

python -m py_maze --load maze.txt

The maze comes from the file as it was saved, so the options that generate one do not apply to it: --width, --height, --difficulty, --algorithm, --braid and --collectibles are all ignored for a loaded maze. --solve, --animate and the in-game hints work on it exactly as they do on a generated one, and --wall-char and --open-char apply to nothing else: they say how a file that carries no py_maze header was drawn.

--seed is the one of them that is not quite ignored. The grid is in the file and is never re-seeded, but what a mode lays over that grid is not in the file at all - quest mode’s chain of doors and boxes is laid fresh each time a picture is loaded - and that does come from a seed:

The run gives The file records The chain comes from
--seed N anything N
nothing a seed line the seed the file records
nothing no seed line fresh randomness, so it differs every run

So --load picture.txt --mode quest --seed 5 lays the same quest every time, and a document that already carries a quest is played with the chain it carries rather than a new one, seed or no seed.

A loaded maze reports the seed its file records, so a maze that turned out to be worth keeping can still be traced back:

Loading maze...

start
...
end
seed: 2024

Where the chain came from somewhere else, a second line says so. The two seeds answer two different questions - seed: is the grid in the file, and content seed: is the chain laid over it - and only the second is the one --seed reproduces:

python -m py_maze --load picture.txt --mode quest --seed 5
Loading maze...

start
...
end
seed: 11
content seed: 5

The line is there only when the two part, which is a loaded maze the run named a seed of its own for. A generated maze, and a loaded one played with no --seed, have a single seed between them and report the one line they always did. So does a document played back with the chain it was saved with: nothing was laid from a seed at all, so there is no second number to give.

A file that is not a maze this build can read is refused rather than guessed at, with a message naming what was wrong:

python -m py_maze --load notes.txt

Output:

py_maze: notes.txt: not a py_maze save file

The same goes for a ragged maze (notes.txt: line 3 is 4 characters, expected 5), a stray character such as a solution marker pasted back in (notes.txt: unexpected character '.' on line 2), and a file written by a newer build (notes.txt: save format 2 is not supported, this build reads 1).

The format is specified in the save file format: the header, the seed comment, the markers, the ragged-line rule and what a reader refuses, so another tool can write a file py_maze will load.