Choose a better serialization format and implementation
kind: featurestatus: needs researcharea: dataarea: export
Currently, serialization for saved games is done using `serde_json`. This is a poor choice for several reasons:
* It does not efficiently store binary data, so we have to do our own inner encoding.
* Lots of our data is enums — nested ones, even — and:
* JSON doesn't support them especially naturally, resulting in a tradeoff between extra nesting or inefficient processing.
* `serde_json` sometimes does weird things around nested enums and `Option`.
* `serde_json` fails to round-trip some values which we would prefer to keep, such as `f64::INFINITY`.
* `serde`, in general, has no notion of a schema defining valid inputs; it accepts inputs flexibly which we would prefer to reject as invalid (e.g. a JSON array may deserialize into a struct type with named fields).
An ideal new format would:
* Be based on some cross-platform specification (something in the vein of protobuf, CBOR, etc.) so that the files are, in principle, not difficult to decode without a specifically Rust library.
* Have a schema language.
* Be binary rather than text so as to efficiently store and convert bulk data — not just `Space` contents, but the repetitiveness of (for example) many color `Block`s in a palette.
* Not necessarily fully self-describing, but, be friendly enough to using lots of enums and optional fields for forwards-and-backwards versioning.
It would be useful if some existing *voxel* data format was extensible enough to fit our needs, but I think that is unlikely to be the case. If there was, though, it would make sense to first implement import/export for that format.
0 条评论