Have an animation repeat and gradually slow down?

[trailsiderice]

Hello! I'm looking to make a sort of shake effect that i could apply to the camera or specific sprites. This thread here had what is almost a perfect solution, but the animation ends kind of abruptly. I'm not very good with ATL, so I'm not really sure where to start with this, but I want to know how I can get started modifying this code so that, after repeating a few times at normal speed, the animation continues to repeat a few more times, gradually slowing down with each repeat. Is this something that can be done with ATL?

Here's the code I have, only slightly modified from the code in the linked thread:

Code: Select all

transform shake(rate=0.09,times=3,xoff=10.0,yoff=10.0):
    ease rate xoffset xoff yoffset -yoff*3
    ease rate xoffset -xoff + 0.8 yoffset -yoff
    ease rate xoffset xoff + 0.8 yoffset -yoff
    ease rate xoffset -xoff yoffset -yoff*3
    ease rate xoffset +0 yoffset +0
    repeat times

[thelastsecret]

I see two possibilities:
1. The easy & ugly one: just do not use repeat, but copy-paste and adjust to your liking.
2. The maybe more elegant, but way more complicated one: define a variable shakiness that multiplies with rate, and change it over time while the screen is running, e.g., by using a second screen with a timer function.

Honestly spoken, I would go for the first variant. You probably don't need that many shaking parameters for your application anyway (I assume), so just define one or two shake animations that look good and use that. Unless shaking is a key mechanics to your game play (guess it's not), there is no need for a parametric transform. It looks over-engineered to me. (I was like "Wow! – – – But.... why?" when i saw it

[trailsiderice]

I see two possibilities:
1. The easy & ugly one: just do not use repeat, but copy-paste and adjust to your liking.
2. The maybe more elegant, but way more complicated one: define a variable shakiness that multiplies with rate, and change it over time while the screen is running, e.g., by using a second screen with a timer function.

Honestly spoken, I would go for the first variant. You probably don't need that many shaking parameters for your application anyway (I assume), so just define one or two shake animations that look good and use that. Unless shaking is a key mechanics to your game play (guess it's not), there is no need for a parametric transform. It looks over-engineered to me. (I was like "Wow! – – – But.... why?" when i saw it

That's a little presumptuous. as it turns out, the shake effect *is* something that is an important part of my game that will be used quite a lot. The use case is, mostly, a camera/background shake animation to simulate a sort of "crash" perspective. The renpy default hpunch and vpunch simply don't do it for me—I always preferred the "ShakeCamera" command used in the Fungus visual novel library for Unity, but RenPy is superior to Unity/Fungus as a VN engine in basically all other areas, so I don't want to use Unity/Fungus. I'm essentially attempting to recreate the Fungus ShakeCamera effect in RenPy as closely as possible, so I can have the best of both worlds. A more complicated, "over" engineered solution is, for me, worth it in this case.

I'm not sure what you mean for the second screen. Do you mean have the images I want to shake on a separate screen and apply the transformation through that? I'm not sure that would work in this case since usually the object i want to shake is the camera...

[thelastsecret]

I don't want to keep being presumptuous, but even if you need the effect a lot, that does not mean that you will need a lot of different variants of it. So think about whether 1, 2 or maybe 3 well designed shake effects will be sufficient for your game. I would still be surprised if they are not.

The second solution would need a screen like this:

Code: Select all

screen change_shakiness(period=1,end_time=5,factor=2):
    timer period:
        action SetVariable("shakiness",shakiness*factor) #or whatever shake prolongation you want
        repeat True
    timer end_time:
        action CloseScreen("change_shakiness")

This is just an untested suggestion. It might also violate some Ren'Py rules if you use one screen to change variables you need in a different screen, not sure about that. Maybe it would work to squeeze both into one screen, but I don't know.