Serialization about goggles HOT 4 CLOSED

I would be okay with implementing Serialize / Deserialize for specific types, but in my opinion a full serialization of a world with entities is just out of scope. I've implemented a serialization system in a pretty complex project that uses goggles, and naively trying to serialize every resource and every entity and every component breaks down really quickly. specs' serialization system was too simplistic and it was one of several parts of specs that I ended up just ignoring.

Now that I think about it, I'm not even sure there are any types in goggles where implementing Serialize / Deserialize is even a good idea. Maybe I'm not thinking of something, what are you using remote-derive to serialize?

from goggles.

So for me it's the Entity type. Right now I just forked this and added #[derive(Serialzie, Deserialize)] to it. I don't think there are many places besides that.

I am in the process of porting from my custom, messy, ECS to goggles so other things might pop-up, but until now it's just the Entity,

from goggles.

I was thinking it might have been Entity. You definitely don't want to serialize Entity at least without also serializing the entity Allocator, and if you do that you usually end up serializing some unique ID per entity and then just re-creating Entity on load. AFAICT that's what the specs serialization system does as well (Marker and MarkerAllocator). If you only serialize / deserialize Entity, then you will end up allocating conflicting entities after a load. An Entity is an allocation of an index for some specific Allocator that exists in memory, that's why there's not a way to just create an Entity from an index and a generation.

I'm sure there are different entity allocation strategies that might be more amenable to direct serialization, and if so, you can still use the rest of goggles and make your own World and Entity types.

from goggles.

You're right :).

from goggles.