Fully serialize entities

[Shatur]

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

Currently for entities we serialize only id:

bevy/crates/bevy_ecs/src/entity/serde.rs

Line 9 in b995b46

serializer.serialize_u32(self.id())

But this is not very expected behavior. For example, if you serialize an entity, send it over the network, and map it to an entity on another machine, this will not work correctly, because generation is skipped for serialization.

What solution would you like?

Fully serialize entities. It may only be redundant for scenes, but Bevy use DynamicEntity for them anyway.

[alice-i-cecile]

From what I've heard from @cart, this is a deliberate decision. Entity identifiers are intended to be opaque, and should not be used for serialization over the network. This is because other incidental entities (such as UI elements or particles) may be spawned, taking up the entity identifier you were planning to use.

Instead, the suggested solution is to use a secondary identifier for network synchronization.

[Shatur]

Entity identifiers are intended to be opaque, and should not be used for serialization over the network. This is because other incidental entities (such as UI elements or particles) may be spawned, taking up the entity identifier you were planning to use.

No, no, it's not for reusing the same identifiers. It is needed for mapping.
When the server sends its state, it contains entities and components. On the client, I create new objects and map them (using EntityMap) to those received from the server (to know which one matches which). And if generation field is missing, this mapping can be broken.

[alice-i-cecile]

Ah, okay! I've seen a lot of people trying to reuse identifiers, so I was a bit suspicious. I'm okay with this change now that you've explained the pattern you're using now; feel free to open a PR.

[james7132]

I'm curious why a secondary index (i.e. a NetworkIdentity/NetworkId) is insufficient here. Both bevy_backroll and bevy_ggrs utilize a secondary and network-wide unique identifier that is handled separately from how the ECS world ID's entities, which makes the ID assignment deterministic and isolated from the rest of the engine.

[Shatur]

It's easier:

• I do not need to handle uniqueness.
• I map it only on client. Server sends its state as usual and client maps server entity to its own entity. With a secondary index I would need to first map it on server and then on client.
• When you send a component with entities, you need to map its entities too. Currently I just re-use MapEntities trait that Bevy use for scenes on client. With secondary index I will need to send the whole server resource with network mappings to let client decode it. Or you an intermediate component with network identifiers instead.

The only use case I know for entity serialization is scenes, but Bevy already uses DynamicEntity for it to avoid storing an extra u32 for generation. This is why I suggested this change, if anyone want to avoid storing an extra u32, they can just create a new type.