DefaultEcs v0.15.0 breaking changes #106
Doraku
started this conversation in
Show and tell
Replies: 0 comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
Don't know if someone will actually read this but with the possibility to have a real place for discussion in github now I thought it would be a good idea to expose what are the changes coming with the next version and the reasoning behind them them.
Breaking changes
Since its inception I was always displeased with the way I implemented the parent/child relationship in DefaultEcs. It was something really specific, ignored the enable/disable state of entities and created garbage memory if used. I finally decided to remove this feature from DefaultEcs, and offer an exemple on how to add it back if you need it in the extension project here.
In the end I think this feature is highly specific of your engine and shouldn't be part of a base framework.
The TextSerializer is supposed to be easy to read and edit by end but because List, Dictionary and Guid were serialized as any type, you were shown all their fields which was completely unnecessary. This aims to change this shortcoming.
Before you could later decide on which world to create your entities with an EntityCommandRecorder. At the beginning I had the thought to turn the recorder as a factory you could reuse multiple times where this would make sens but this offer no benefit to just calling your static method as a factory or even create a really simple model to schematize this factory in an editor so I just scrapped this idea. Thus keeping the world parameter of the Execute method made little sens instead of providing the world when creating an entity in the recorder.
Actually went with the rename, makes things clearer and more homogeneous.
DefaultEcs.Analyzer sister project
This is probably the actual big new thing that will come with this release. This analyzer will include some checks about the correct usage of DefaultEcs but also a roslyn code generator to greatly reduce boilerplate code and remove reflection usage when possible (to help AoT platform that can't rely on jitter).
For example instead of having systems declared as such:
you will be able to declare them as
The EntitySet composition will be automatically deduced from the parameters of the method decorated with the Update attribute, the generator taking care of the constructor and the override of entity systems.
Beta Was this translation helpful? Give feedback.
All reactions