Description
I recently picked up Arch and i'm really loving its API. I'm especially excited for the Arch.Extended to be updated to support Arch 2.0.
One thing i'm digging into specifically is the serialization of entities. It looks like Arch.Extended has the ability to serialize entities but it comes with a warning The order in which components are registered must be the same for deserialization as for serialization.
This is almost impossible to guarantee for a pluggable / moddable game. So you expose manual registration as a stop gap
ComponentRegistry.Add();
But now the hurdle is to have plugins or mods know the full set of already used IDs to ensure that overlaps are not created causing bugs. This seem problematic especially for a moddable game. Do you have a recommendation of how best to handle this?
If not the better way i've seen this to be done is to use the FullName of the type as the unique id. This is always unique within the codebase (especially when you include assembly) BUT its also cross compatible with games with different plugins/mods loaded and doesn't require a manually kept full registry of used component IDs to be maintained.
Would you be open to having this kind of functionality added? I've only lightly dug into the codebase but i'm open to trying to give this a shot. On it's face it would seem to be alot like the _typeToComponentType lookup you already have but it would just first see if there is already a "_stringToComponentType" registered before it generates a new registration of a component.
(I've also seen implementations that generate a GUID or Hash from the type class instead of using incremental id's - this looks like it would be more work and pretty big refactor since you are using an indexed array to store the component types and the Component<T>.ComponentType.Id is used in lots of place)
Thanks for your time.