Simplified scene and reflection serialization

[AronDerenyi]

What problem does this solve or what need does it fill?

Right now serialized scene files are too big and verbose. Take for example the scene example file:

[
  (
    entity: 0,
    components: [
      {
        "type": "bevy_transform::components::transform::Transform",
        "struct": {
          "translation": {
            "type": "glam::vec3::Vec3",
            "value": (0.0, 0.0, 0.0),
          },
          "rotation": {
            "type": "glam::quat::Quat",
            "value": (0.0, 0.0, 0.0, 1.0),
          },
          "scale": {
            "type": "glam::vec3::Vec3",
            "value": (1.0, 1.0, 1.0),
          },
        },
      },
      {
        "type": "scene::ComponentB",
        "struct": {
          "value": {
            "type": "alloc::string::String",
            "value": "hello",
          },
        },
      },
      {
        "type": "scene::ComponentA",
        "struct": {
          "x": {
            "type": "f32",
            "value": 1.0,
          },
          "y": {
            "type": "f32",
            "value": 2.0,
          },
        },
      },
    ],
  ),
  (
    entity: 1,
    components: [
      {
        "type": "scene::ComponentA",
        "struct": {
          "x": {
            "type": "f32",
            "value": 3.0,
          },
          "y": {
            "type": "f32",
            "value": 4.0,
          },
        },
      },
    ],
  ),
]

It takes 64 lines to describe 2 entities with a total of 4 components. It's also hard to read and understand with all the indentation. This is mostly because of the way reflected items are serialized so all of the above also apply to them.

What solution would you like?

Luckily the Rusty Object Notation (RON) has introduced named structs which can be used to merge the type and value into a single item like so:

changing

{
  "type": "glam::vec3::Vec3",
  "value": (1.0, 1.0, 1.0),
}

to

glam::vec3::Vec3(1.0, 1.0, 1.0)

This way we remove the "type" and "value" keys and also a layer of indentation. Applying all of this to the example file we get the following:

[
  (
    entity: 0,
    components: [
      bevy_transform::components::transform::Transform(
        translation: glam::vec3::Vec3(0.0, 0.0, 0.0),
        rotation: glam::quat::Quat(0.0, 0.0, 0.0, 1.0),
        scale: glam::vec3::Vec3(1.0, 1.0, 1.0),
      ),
      scene::ComponentB(
        value: alloc::string::String("hello"),
      ),
      scene::ComponentA(
        x: f32(1.0),
        y: f32(2.0),
      ),
    ],
  ),
  (
    entity: 1,
    components: [
      scene::ComponentA(
        x: f32(3.0),
        y: f32(4.0)
      )
    ],
  ),
]

This is only 28 lines long with a lot less indentation while keeping all of the information of the current file. This is subjective but to me it's just as if not more readable than the current one. And while we're at it we can further simplify by treating the scene as a map where each key is and entity and their corresponding values are lists of their components. Like so:

{
  0: [
    bevy_transform::components::transform::Transform(
      translation: glam::vec3::Vec3(0.0, 0.0, 0.0),
      rotation: glam::quat::Quat(0.0, 0.0, 0.0, 1.0),
      scale: glam::vec3::Vec3(1.0, 1.0, 1.0),
    ),
    scene::ComponentB(
      value: alloc::string::String("hello"),
    ),
    scene::ComponentA(
      x: f32(1.0),
      y: f32(2.0),
    ),
  ],
  1: [
    scene::ComponentA(
      x: f32(3.0),
      y: f32(4.0)
    )
  ],
}

I prefer the last version for the following reasons:

• It's compact while still containing every bit of information
• It more closely resembles the corresponding structs in rust
• It's clear what each indentation level means (first: entities, second: components, third: component properties and so on)

[alice-i-cecile]

I like this a lot: it's shorter, clearer, and easier to both read and write! For me, 3 > 2 >> 1.

Are you interested in submitting a PR for this? We're about to take a serious look at scenes, and this is high on my list for improvements I'd like to see.

[IceSentry]

I like the last version, but how would it work if we ever want to add more metadata to a scene that isn't just another entity?

[aevyrie]

I like the last version, but how would it work if we ever want to add more metadata to a scene that isn't just another entity?

Top level sections? e.g.:

scene::Metadata1 (

),
scene::Entities(
  0: [
    bevy_transform::components::transform::Transform(
      translation: glam::vec3::Vec3(0.0, 0.0, 0.0),
      # ...
    )
  ],
)

[DJMcNab]

How is this issue different to #92?

It appears to me to be covering the same ground.

But I do agree, those formats are much nicer

[alice-i-cecile]

I'd missed #92! IMO this issue covers a strict improvement to the syntax: #92 is much more vaguely scoped. Closing #92 will necessarily close this, but the reverse is not true.

[IceSentry]

Top level sections?

I kinda assumed the scene format would support nested scene or even multiple scene in a file. Assuming it's only one per file it makes sense to only use top level sections though

[AronDerenyi]

Are you interested in submitting a PR for this?

I'll give it a shot and we'll see what happens

how would it work if we ever want to add more metadata to a scene that isn't just another entity?

I like what @aevyrie suggested but I don't think it's possible to have multiple top level values. In that case we could simply wrap it all in a struct:

Scene( // optional
  metadata1: ...
  metadata2: ...
  entities: {
    0: [
      bevy_transform::components::transform::Transform(
        translation: glam::vec3::Vec3(0.0, 0.0, 0.0),
        rotation: glam::quat::Quat(0.0, 0.0, 0.0, 1.0),
        scale: glam::vec3::Vec3(1.0, 1.0, 1.0),
      ),
      ...
    ],
    ...
  }
)