Integrate Blueprints about entitas HOT 10 CLOSED

It would be great to have two types of serializers human readable and binary, text serialization is great during development, you can easly check previous versions, merge conflicts, comparing.

from entitas.

Started implementing the core functionality after comparing and trying different approaches.

The idea:

• I’d like to reuse the Inspector for EntityBehaviour we all know from VisualDebugging to create and edit Blueprints
• Provide sth to easily set the format how to serialize Blueprints (XML, YAML, JSON, FlatBuffers, ProtoBuf, ScriptableObject, etc)
• Add a code generator to read all blueprints and generate code for better performance compared to pool.CreateEntity(blueprint), e.g. pool.CreateHero()
• Cache blueprints at runtime when used raw (e.g. loaded OTA) to avoid reflection

You can follow and diff here #84

from entitas.

API sneak peak:

var blueprint = new Blueprint("Hero", e);

e.ApplyBlueprint(blueprint);

from entitas.

Blueprints means serializing and deserializing components. Shall I enforce that every component that can be used with blueprints has to be tagged with [Serializable]? It would def help to raise awareness that not every type can be easily serialized and that you'd have to provide a converter for those cases

from entitas.

Too bad that Unity's mono version is sooo old. I cannot use built in json and Unity's json implementation is very limited and doesn't support serializing System.Object. Also no public access to Unity's yaml parser...
I guess for now I have to stick with xml 😱

from entitas.

Too bad C++ doesn't have reflection, i can't think on this feature even a bit xD

It could have been worse 😱

from entitas.

Poll
I was thinking if we actually need the option to serialize to different formats like xml, json, etc.
Ok, it's nice that the serialized file is human readable, but it doesn't really need to be.
What about going binary only? The file size might be smaller, parsing might be faster, and we can always edit the blueprints with the Entity Inspector known from Visual Debugging.
It would also work with A/B Testing by providing a new binary file.
The only downside that I see atm is, that C#-only-projects don't have a visual editor for Blueprints and would benefit from a human readable text file.
Two ways to work around this would be

1. declaring entities in temp code to generate blueprints and binary files
2. Getting the free Unity version to get a visual editor :)

What do you guys think? Can/Should we go binary only?

from entitas.

Maybe binary at first but using an file-access-like interface to allow other formats in the future? (for C#-only)

from entitas.

Personally I don't like to store data files like blueprints in a binary format. Simply because of the quick iterations you get with human readable files. So my vote is on that type of serialization format.
But as @JuDelCo mentioned. The binary way might be the way to go at first?
But in the future It would be really cool to be able to choose the blueprint serialization of your choosing

from entitas.

Update:
I've got the basic mechanic working. In phase 1, you can create new Blueprints as a ScriptableObject which serializes the data in a binary format. The EntityInspector know from VisualDebugging is used to set up the blueprints.
Next step is to support different pools and automatically resolve potential pool and component index mismatches from the deserialized blueprint (when you load an old blueprint and you refactored the pool name or added new components and the index is out of date)
I did lot of profiling and managed to use blueprints without creating garbage.

If you already want to see the first result checkout #84

Happy Easter! :)

from entitas.