Wobble formula?

0 favourites
  • 8 posts
  • I've been pulling hairs trying to create a versatile formula that basically would make something wobble. i have two needs for this formula, first is to make a sprite wobble by manipulating width/height, second to have the sprite move and wobble when reaching its end location.

    Here's an image that hopefully shows what i'm trying to create:

    Depending on the initial momentum, the sprite should oscillate at the end point until it has stopped.

    Here's a cap example:

    https://www.dropbox.com/s/9gu7ugl7an8bkkk/wobble.capx?dl=0

    Both sprites are using the sine behaviour and none of them work correctly.

    -the sprite that changes width flips after reaching the mid point (shrinking and getting narrow is fine, but not flipping!)

    -the sprite that moves horizontally only wobbles from its initial location instead of moving from point A to point B, this makes me think sine is probably not the answer to this question, i think...

    I was hoping that someone with knowledge could poke me in the right direction on how to get this formula done.

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads
  • try using not sine behaviour, but calculations using sin + cos with setting X and Y position of your item.

    or something like this:

    y = time

    x (time ) = A * e^(-(gama)*time) * sin ( omega*time - phi)

    apply that to x and y and use some values to find out which suites the best. 2nd formula is undertoned oscillation - stops on 0

  • sorry for sounding like an idiot but how does that formula translate to a workable construct event? this level of math is way over my head.

  • something like this:

    set position y = time , X = (pick a number of pixels) * Math.POW( Math.E, -(pick a small number for absorption)*time) * sin (any number * time - any number to 90)

    though this is just simplified version. you will still have to play with it. try x = width /2 and y= time and see what happens. your sprite should travel on the midscreen from pixel 0 downwards until it leaves layout without wobbling.

    then play with X value and you have your solution. if you want wobbling exactly as on picture, you will have to do some math - calculting the point of 70% of sinus where you will start changing your y value for a sec so it rotates back, and then disabling it until it hits next 70% but with reduced amplitude... and repeat until amplitude is ~0 then you stop it.

    it's kinda hard truly, needs at least 2 subevents, maybe there is some kind of plugin that does that already, but i don't know really any.

  • thanks for the quick reply! when you write math, time, e, etc. in the formula, what is this referring to? is it a valid expression or do i need some plugin?

  • Have you tried doing it with lunarray's litetween plugin ?

    I tried to do something similar to what your are doing (e.g coding the wobble and so forth my self) and had it working nicely... but performance sucked. then i started using the lite tween plug and haven't looked back since... it's extremely versatile and performance is in my experience really good.

  • This seems to work for me, and it's a simple formula. Scrap the Sine behavior. Add instance variables to your Sprite called XSpeed and TargetX.

    // Basic Formula
    Every Tick:
       Set X of Sprite to Sprite.X + Sprite.XSpeed*dt
       Set XSpeed of Sprite to (Sprite.XSpeed + (Sprite.TargetX - Sprite.X)*STIFFNESS_AMOUNT)/(1+DAMPENING_AMOUNT*dt)
    
    // Optional: Prevent Excess Wobble Near TargetX
    abs(Sprite.TargetX - Sprite.X) < 0.5
       Set X of Sprite to Sprite.TargetX
    [/code:6s2masrv]
    A good starting value for both STIFFNESS_AMOUNT and DAMPENING_AMOUNT might be around 5 to 10.
    
    Now I'm not sure if this is the "proper" way to do it, but it makes sense if you think about it. The further the object is from the target, the greater the force that needs to be applied to it, so we add a value to XSpeed proportional to its distance from the target. The stiffer a spring is, the HARDER it pulls an object towards it, so we multiply by the stiffness. Finally, springs slow down because of some energy lost in friction and whatever else. So we divide by some value over time.
  • Dalal, that worked beautifully, and much less complicated than i had anticipated! thank you so much!

    Kali, i'm gonna check that plugin out, thanks for the tip!

Jump to:
Active Users
There are 1 visitors browsing this topic (0 users and 1 guests)