Animation remastering

[IWonderWhatThisAPIDoes]

Animations of moving objects are very minimalistic, consisting of only one circle arc (or linear spiral) at a time. This is enough to animate a single cycle turning, but if more cycles are turned in short succession, the animation has noticable artifacts. Furthermore, as we add new cycle shapes (https://github.com/IQuick143/bevy_jam_5/issues/20) or black boxes (https://github.com/IQuick143/bevy_jam_5/issues/3), an entirely new implementation of animation will be necessary.

Design considerations

• Animation paths should consist of an arbitrarily large number of path segments. Required segment shapes are at least circular arcs (linear spirals) and straight segments, possibly ellipses if we choose to implement them as a cycle shape.
• Animations should be retractable, i.e. if the player makes the same but opposite move in short succession, the whole animation should not play out, instead, it should subtract the part of the path that has not yet been animated.
• Corner easing might be necessary. This means the animated paths may need to be rounded around sharp turns.
• Finite horocycles will require sprite teleportation. This can probably be done as a special path segment type.
• Infinite horocycles will require sprite spawning at runtime. Because this happens off-screen, the animation implementation does not need to consider this. A new sprite will be spawned immediately, and animated on-screen in a standard way.
• Infinite horocycles should also involve sprite despawning. This is not strictly necessary, but it would probably be a good thing to not have a thousand off-screen entities alive. The de-spawn will have to be done after the entity is done animating off-screen, probably not by the animation engine itself, but rather by another system that takes into account the animation state of an entity before despawning it.
• Black boxes will cause entity transformation, which once again, has to be visualized at a delayed pace, when the sprite actually passes through the black box. The simplest way to implement this would probably be to have two sprite entities alive at the same time (one that ends at the black box, another that starts there) and have them both follow the same path, swapping their visibility when inside the black box. The expiring entity will be despawned when (if) that animation segment fully plays out.
• If there is no synchronization between different objects on the same curve (i.e. one object is in the middle of another animation, the others are not), they may animate at different speeds. This might be too noticable.

[IQuick143]

RE: Blackboxes, we will likely have the blackboxes be smaller than all sprites (notably player sprites), for this reason I imagine the blackbox transformation animation will involve a "squeeze" to fit the sprite into the blackbox by decreasing its scale. Also I would note that entity transformation can also involve either spawning or despawning since one of the transformed states can be an empty slot while the other is an entity with a sprite.

[IWonderWhatThisAPIDoes]

entity transformation can also involve either spawning or despawning

That just means that if we implement transformations by despawning the input entity and spawning a new one for the output, we do not have to make a special case for that scenario, since it all reduces to the same instructions.

I would imagine that each path segment would have additional animation aspects to do with visibility, such as "fade out" or "make this visible halfway through." Maybe the fading out will have to be scratched though, since boxes already consist of several different sprites and applying opacity to that would just be awful.

[IWonderWhatThisAPIDoes]

Moving sprites should be squished as they travel... provided we can hack the api to make it possible