Better Tween integration

[parasyte]

This is something that I've been fighting in my head for a long, long time. The question is: how do we integrate Tweens into objects better?

Background: me.Tween is easy to use because it adds itself to the world container when created. For this reason, it is kind of "heavy" and disconnected from the parent object that is using it.

Proposition: Tie me.Tween directly to the object using it. And avoid creating additional objects if possible.

Two examples:

1. A HUD item may be a child of a HUD me.ObjectContainer, and the HUD item uses two Tweens: one for scaling when the mouse hovers over it, and another which slowly rotates it a few degrees left and right as a simple idle animation. When these two Tweens are created, they are immediately added to the world container. However, the HUD item will not be visible or updating if the HUD container is not in the world container at that time. This is the disconnect. Second, because there are two Tweens added for each HUD item, the total number of objects to iterate in the world container grows rapidly, meaning slower update, and slower draw each frame.
2. A particle manager (Add a Particle System #367, particle system improvements and features #385) could benefit greatly from Tweening properties on each particle, as any of the supported interpolation functions could be used (instead of a simple LERP). This scenario will stress test the Tween support by virtue that each particle will require multiple Tweens. When dealing with hundreds of particles, that means thousands of simultaneous Tweens.

I would love to hear any ideas for solving the two issues; tie Tweens to parent object, and avoid multiple Tweens everywhere. My concept so far is : me.Renderable gets a new property "tweens" which is an array of Tweens. me.Renderable.update iterates the array to update Tween state. That's it so far. :\

The obvious benefits are:

• Tween updates can be prevented in a variety of cases, especially when the parent object has not been added to the scene graph.
• Tweens never incur a performance penalty in the draw phase, because they are no longer included in that code path.

Open questions:

• Should Tweens update object properties in the update phase, draw phase, or make it configurable (but never both)? This question will be important for Separate game logic and drawing updates; allow consistent game speed with variable frame rate #99, where the two functions will run at a different frequency; draw will always be the highest frequency. I'm partial to draw phase only, but there may be cases where doing it in update is preferred?
• Should we continue supporting the concept of a "global" Tween that adds itself to the world container? Would there be any point to this?
• Tweens tied directly to the parent object will create circular references, which we need to be careful about or we may end up falling into a big GC trap.

@obiot @agmcleod Any thoughts? Comments? Open to discussion! Also looking forward to input from @insidiator and @ciangames

[insidiator]

This is something that is bothering me too.
But I think it would be a lot easier if I could just tell the tween to not update automatically when calling start.
That way I can decide when and where I want to call the update function myself and still have the comfort of not thinking about it if I don't care.

[parasyte]

Yes, that's the reason for this discussion; to get Tween to the point where it works well in different scenarios and no one has to care how or why. :)

[agmcleod]

Yes definitely a +1 on this. Even if we keep it relatively simple as per @insidiator's suggestion. Should just make it a bit more clear as to when it's updating. If i have to call update() on my tweens for the snowball animation or w/e, then i know for a fact that if the snowball isnt updating, neither are the tweens. This connects the tween better to the objects you wish to manipulate. Pretty much everything visible in a game is staged to the game world object container. So why not tie tween's to a renderable?

[agmcleod]

@parasyte As a small change, any objection to simply removing it from the world container? Update/create an example to show the parent object of the tween such as a renderable to manually invoke the update?

[parasyte]

Well, I definitely don't want to put the responsibility of updates on the user. It should still be automatic. It just needs to work right. :\