ITADN

Choose a better serialization format and implementation

#726Openkpreid 创建于 2025-12-30
kind: featurestatus: needs researcharea: dataarea: export
K
kpreidcommented
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 条评论