These had been based on the "ZZT file format" wiki article, but Weave
came up with some nicer unofficial names for the elements that ZZT 3.2
left unnamed. The variants are still named in CamelCase; this commit
just makes them a little closer to what they're called in practice.
Also in this commit: capitalize letters when they stand for directions
in names, like `SliderEW` (instead of `SliderEw`, which sounds like
expressing disgust over slider puzzles).
A lot of this is deleting zztext-specific functionality, such as string
mappings that go beyond official names for things. It's okay, zztext
will cope.
I'm spinning zztff off as its own Rust crate, separate from my zztext
project (which will soon consume it). This commit is based on running
filter-repo on the zztext project, followed by the minimal work to get
it to build separately.
Eventually, I want to take the code for working with the official binary
formats and split it out into a standalone library. The code for parsing
my unofficial text formats would then use that library as a dependency.
I might also spin off the text format code into its own library someday.
It might be useful to have a common text format.
This commit is just anticipatory prep work; I'm definitely not ready to
split this into a bunch of different crates today! I want to firm up the
data structures and the text format first.
These are the only board indexes in the ZZT file format that cannot
reference the title screen; 0 is reserved to mean "no connection".
This change encodes that in the type system.
- Two blank lines separate major parts (world header, boards)
- Other groups always separated by a single blank line
The intent is to visually cluster together the top-level parts of the
text format, in the hopes of making it more readable.
The example data is far from perfect, and there's a bunch of small stuff
I want to tweak about the text format. But now the tests exist, which is
a strict improvement from before!
I ran some limited tests, and the important data seems to survive
roundtrip conversions. It's a bit tricky to measure because conversion
to text strips out/normalizes some data, such as garbage bytes in the
unused portions of Pascal strings.
cmounce