[Merged by Bors] - bevy_scene: Replace root list with struct

[MrGVSV]

Objective

Scenes are currently represented as a list of entities. This is all we need currently, but we may want to add more data to this format in the future (metadata, asset lists, etc.).

It would be nice to update the format in preparation of possible future changes. Doing so now (i.e., before 0.9) could mean reduced¹ breakage for things added in 0.10.

Solution

Made the scene root a struct rather than a list.

(
  entities: [
    // Entity data here...
  ]
)

---

Changelog

• The scene format now puts the entity list in a newly added entities field, rather than having it be the root object

Migration Guide

The scene file format now uses a struct as the root object rather than a list of entities. The list of entities is now found in the entities field of this struct.

// OLD
[
  (
    entity: 0,
    components: [
      // Components...
    ]
  ),
]

// NEW
(
  entities: [
    (
      entity: 0,
      components: [
        // Components...
      ]
    ),
  ]
)

Footnotes

1. Obviously, adding features runs the risk of breaking things regardless. But if all features added are for whatever reason optional or well-contained, then users should at least have an easier time updating. ↩

[Vrixyz]

I feel like it's a complex implementation of the serialization/deserialization ?
I would have expected to see a SerializedScene struct we can refer to rather than rely on other docs/examples ?

In any way, it's probably helpful to have a custom deserializer, to iterate over assets or entities I guess, but right now it doesn't seem to be the point ?

Other than that (and the minor space nitpick), LGTM 👍 but I'm not comfortable enough with scenes to commit to an approve though, good luck :)

[alice-i-cecile]

I'm on board. I think it's very unlikely that we never want to add other data to scenes, whether that's assets, meta-data, resources or something else entirely.

[MrGVSV]

I feel like it's a complex implementation of the serialization/deserialization ? I would have expected to see a SerializedScene struct we can refer to rather than rely on other docs/examples ?

Yeah the documentation could be improved to bevy_scene overall. As for a SerializedScene struct, you can sorta look at DynamicScene to get an idea of the layout. Thankfully, with this PR it actually matches up rather than being the value of DynamicScene::entities.

In any way, it's probably helpful to have a custom deserializer, to iterate over assets or entities I guess, but right now it doesn't seem to be the point ?

The reason for the custom deserializer is we need access to the TypeRegistry (we use DeserializeSeed instead of Deserialize to achieve this). So we can't just derive Serialize/Deserialize unfortunately.

[jakobhellermann]

I agree with the decision to change the scene schema, it is more understandable and easier to extend.
It's unfortunate that we can't just derive the serialization code but that is nothing new. I don't exactly understand how the #[seride(field_identifier)] stuff works but other that that the implementation looks good.

[mockersf]

I haven't written serde code in a long time, but nothing stands out as bad 👍

[alice-i-cecile]

bors r+

[bors]

Pull request successfully merged into main.

Build succeeded:

• build-and-install-on-iOS
• build-android
• build (macos-latest)
• build (ubuntu-latest)
• build-wasm
• build (windows-latest)
• build-without-default-features (bevy)
• build-without-default-features (bevy_ecs)
• build-without-default-features (bevy_reflect)
• check-compiles
• check-doc
• check-missing-examples-in-docs
• ci
• markdownlint
• run-examples
• run-examples-on-wasm
• run-examples-on-windows-dx12