Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Suggestions for CompositeMotionHandle and LSequence #200

Open
DaniBarca-voodoo opened this issue Jan 22, 2025 · 0 comments
Open

Suggestions for CompositeMotionHandle and LSequence #200

DaniBarca-voodoo opened this issue Jan 22, 2025 · 0 comments

Comments

@DaniBarca-voodoo
Copy link

DaniBarca-voodoo commented Jan 22, 2025

I'm not entirely sure of what's the use for CompositeMotionHandle, but I see it's used to aggregate different motions in a single handle, in a similar way to what LSequence would do if we only Join all motions. Please let me know if I'm missing an existing way to do this.

In our code we use CancellationTokens and AddTo to know if the motions should stop earlier than expected, and sometimes there's many tweens, meaning we have to add AddTo and/or ToUniTask for each one of them.

I think it would be useful to aggregate all of them in a CompositeMotionHandle and apply those operations to the whole lot, once.

Another suggestion, which I think won't be very loved (but I've got to say it), is that I would like a way to add items to a CompositeMotionHandle or MotionSequenceBuilder without having to add parentheses each time.

Motions usually take a few lines if we want them to be readable, and parentheses don't help keeping code readable when there are many tweens going on. The idea that comes to my mind is overriding compound assignment operators to Add, Append, Join, etc.

I'm not the n1 fan of this solution anyway since it abuses operator overriding, but maybe you come up with something better. I personally like not having to add another tab and avoiding noise.

In the case of CompositeMotionHandles, the operator += could be used to add new handles, and that doesn't feel so bad for me because it's similar to how delegates work by default.

Before

            var sequence = LSequence.Create();
            
            sequence.Append(
                LMotion.Create(0f, 1f, 1f)
                    .WithEase(LitMotion.Ease.OutBack)
                    .BindToPositionX(item1)
            );

            sequence.Append(
                LMotion.Create(0f, 1f, 1f)
                    .WithEase(LitMotion.Ease.OutSine)
                    .BindToPositionX(item2)
            );
            
            sequence.Join(
                LMotion.Create(0f, 1f,1f)
                    .WithEase(LitMotion.Ease.InBounce)
                    .BindToPositionX(item3)
            );
            
            sequence.Run().ToUniTask(cancelToken).Forget();

After

            var sequence = LSequence.Create();
            
            sequence ^= LMotion.Create(0f, 1f,1f)
                .WithEase(LitMotion.Ease.OutBack)
                .BindToPositionX(item1);
            
            sequence ^= LMotion.Create(0f, 1f,1f)
                .WithEase(LitMotion.Ease.OutSine)
                .BindToPositionX(item2);
            
            sequence |= LMotion.Create(0f, 1f,1f)
                .WithEase(LitMotion.Ease.InBounce)
                .BindToPositionX(item3);

            sequence.Run().ToUniTask(cancelToken).Forget();

In this last code it would be much faster to iterate and quickly prepend the motions into a sequence (even using multi-cursor in some IDEs), besides having to select them, surround them with parenthesis and properly indent one by one.

One last thing for which I don't really have an answer, but wanted to make you aware of. Since MotionSequenceBuilder implements IDisposable, it's possible to do sequence.AddTo(cancellationToken) (defined in Cysharp.Threading.Tasks.CancellationTokenExtensions).

I'm not sure what happens in that case because I noticed the difference soon enough, but looking at the code seems like a very different behavior than MotionHandle.AddTo() and looks like mistaking them could result in many hours of debugging.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant