search

NagaChiang / entity-tween

Entity compatible tween library for Unity ECS/DOTS and Project Tiny (DOTS Runtime).
MIT License
79 stars 14 forks source link

Internal interfaces prevents extensibility. #3

Open AlexandreFiset opened 3 years ago

AlexandreFiset commented 3 years ago

In its current form, it is not possible to extend Entity Tween as its interfaces are internals. For instance, I'd like to tween a View (Canvas Group), but it is not possible to use the interfaces outside of the scope of the Entity Tween assembly.

I'd recommend making them public so that developers can develop their own tweening systems for things they want to tween.

AlexandreFiset commented 3 years ago

After playing around much more with the package, which is amazing btw, I found that I had to turn a lot of internal classes to public. I believe that in the end, I'd probably be better to just fork it and integrate my changes right into it but eh, done is done.

I had done a similar thing called InterpolationSystems but while I had similar performances, yours is much nicer to use and extend. The only hiccup I have is the static Tween class which cannot have extensions by its static nature. Anyway!

NagaChiang commented 3 years ago

Sorry for the late response. Thanks for your kind words. I'm glad someone likes it.

How do you tween the UI objects? As far as I know, DOTS doesn't have any UI support so far; or, did I miss something? I don't follow DOTS for a while since they slow down the pace of the development.

The reason why I kept most of the things internal was that I thought it's not quite easy to customize new tweening support after all. You have to fully understand the workflow, knowing which parts should be implemented, before you customize.

If you are interested, how about opening a PR and we can discuss more the extension you made? Contributions are always welcomed since I don't get much time working on this recently. Sounds good?

AlexandreFiset commented 3 years ago

Yes of course! I am playing a bit more in depth with it and for the moment, there are a few things that comes to my mind for refactoring the thing to be more extensible.

Changing static Tween to static instance of TweenManager This allows extension methods for the Tweener and is also closer to what we're used to with EntityManager. What I do is leave the TweenManager empty and add an extension method per type of tween to their own script. For instance, TweenRotationExtension would contain the three Move methods. The base TweenManager would have no such method.

Moving RegisterGenericJobType and their associated jobs to separate files That means that RegisterGenericJobType plus the Generate and Destroy systems would be found in TweenSomethingSystem.cs. This ensures that the original Generate and Destroy systems remain untouched. This also means that generating new tween is only a matter of copying TweenRotationSystem, its associated components, and just changing names and value types.

Then for the managed stuff, what I always do is use some kind of link component data. For instance, for Ui, there is no point in having two Alpha on one Entity. There is always just one Alpha for a given object. So I use an Alpha component, then some systems such as CanvasGroupAlphaSystem which applies the Alpha Value to the CanvasGroup on the main thread, usually after the simulation.

I'm playing around with these things part-time as I have a lot of things to do, but once I have something nice that responds to my needs, I'd be happy to share it back to you and if you want these changes to be part of your repository, then that would be great :) Cheers!

NagaChiang commented 3 years ago

Seems great. In this case, when we extend new tween supports to the package or users customize their own tween logic, all codes will be gathered in one file. I think it might be better since there are tons of things to support in the future.

I understand how it feels to play these things only in limited time due to the day job and other things in life. Just take your time and have fun!