Determine path for serialization + widgets

[McCallisterRomer]

Within NcEditor, each component type needs a way to expose its properties through the UI and be saved/loaded. We need to determine how game-side components will provide this functionality to the editor.

Q: How will the editor loop through each component type? We'd like to be able to say something like:

for (auto& c : registry->ForEachComponent(entity))
{
    Serialize(stream, c);
}

This doesn't work for pooled components, since there's no common base class. We don't have any way to loop through any sort of 'type list' of all registered types - we just have a list of PerComponentStorageBase.

• Could we make some common interface wrapper that exposes funcs like Serialize() and UIWidget()?
• Could we manage a type list somehow and loop over that? The use would need to 'set' this somehow.

Q: What does (de)serialization interface look like? Component constructors may need access to all kinds of things during deserialization + they need to be constructed through the registry.

Q: How do we handle logic components + other user logic? If we load a scene by deserialization, maybe there is some game function that should run after that process to cover something not possible during deserialization.

[ClickerMonkey]

If we load a scene by deserialization, maybe there is some game function that should run after that process to cover something not possible during deserialization.

This crossed my mind as well - personally I broke up creating a scene into two parts. First step was defining entity/component/storage stuff as well as something like the "logic types" where you map a function definition to some type. The second setup function was to initialize the data when the scene was not being restored from files. Then there is an amount of validation that needs to be done (if the data in the scene depends on something that was removed that's not good. like if you had EdgePanCamera logic the last game run and then you removed it but there's a serialized entity that depended on it.

Just some unsolicited thoughts!

[McCallisterRomer]

In a previous POC I had made it possible to mix source code + deserialization during scene initialization, but never got far enough to handle logic serialization. So you could do something like, but PostLoad() would always need to know how to setup logic components:

void MyScene::Load()
{
    Init();
    HasSaveData() ? Deserialize(GetSaveData()) : FirstTimeInit();
    PostLoad();
}

I've started with the first question, but I need to figure out what it would look like to add some sort of function registry to track logic types for serialization (and possibly selecting/assigning functions through the editor).