# Creating a parabolic effect in 2D top-down view

1 favourites
• 20 posts
From the Asset Store
Set of tiles to create a map for top-down games with island theme
• In my game, whenever an enemy is hit, it will spawn a few collectible power-ups. Upon spawning, I want it to appear as though they are "bouncing" once from the enemy. Since the view is a top-down perspective, I figure that adjusting the scale of the power-up while it travels in a short linear direction is the best option.

If we could imagine viewing this power-up spawning action from a side view, it would basically be a parabola (think back to math class and graphing x,y points). The parabolic equation is y=ax^2+bx+c, where y=object's scale.

However, I'm pretty sure this is an overly complicated way to work this out...but, I would still like to know if anyone can help me understand how I might make it work anyway. Also, while there is surely a much more simple solution, using a parabolic equation would make the effect look more "natural" in my mind, which is partly why I am still seeking help on this one.

• If you dont want to use parabolic formulars, you can achieve the same effect with Bullet behavior and change scaling according to the speed:

1drv.ms/u/s!Ap_-qxoGKbDcg36Eo443iLPo3VaT

• The parabolic equation is y=ax^2+bx+c, where y=object's scale.

If I want to use this equation for y=scale, then what is a "a", "x" and "b"?

a = beginpoint, b = endpoint, x = x-scale?

• Use three instance variables:

z =100 for the z position

vz=-10 for the z speed

g=10 for the gravity

Then with events:

Every tick:

— sprite: add self.g*dt to vz

— sprite: add self.vz*dt to z

— sprite: set scale to 100/max(100,self.z)

It’s still parabolic but simpler than using the parabolic equation because you’d have to do more on top of it.

Anyways you’ll have to adjust the variables to get the effect you want.

If the object gets too big, make vz smaller.

If it happens too fast or slow, then adjust g. Keep in mind you’ll need to adjust vz after that too.

The use of max() in the set scale action limits the scale to never be lower than 100.

• Thank you, everyone! I'll attempt to implement your suggestions when I get home today.

• R0J0hound - Does the Z variable ever change? It doesn't appear so based on what you offered. If not, does it matter if I just use max(1,1)? Or is there something I'm missing?

• Also, the second event line is just written as sprite: add self.vz*dt. What am I adding that to?

• That was the line where z was added to.

I also forgot to take into account z scaling. Edited the op with the changes.

It uses (100-1)/(100-z) for the scale now. Change the 100s to adjust the amount of scaling. It may be ok to just use z directly like before. It all depends what is acceptable.

• AH! Okay. Thank you, sir! I will plug that in and make some magic happen! (I'm always grateful for your help.)

• Ha HAAA!! It works! Thank you!!!

• Kyatric : is this something for the FAQ?

• It uses (100-1)/(100-z) for the scale now. Change the 100s to adjust the amount of scaling. It may be ok to just use z directly like before. It all depends what is acceptable.

Thanks, it also works for me.

I do not understand the 100-part, though. If it is not too troublesome, could you explain it or point to someplace where I can read about it?

(100-1)/(100-z), if z=1 --> (100-1)/(100-z)=99/99 = 1 = the image is not scaled up or down, if I understand correctly.

And if z changes, the outcome changes, which affects the scaling.

If I am right about how this works, then the question is maybe, how did you get to making this genius way of handling it?

• There are more elegant ways to handle it.

Basically I started with z is the distance into the screen and 1/z is to get the scale.

Basically z=0 is the eye location.

Z=1 is the ground

And z<0 is behind the eye and should be hidden otherwise things scale up again negatively.

If we just had stuff going away from the camera it would work fine. The objects would get smaller. The problem is the objects are going up and only have 1 unit to move before being behind the camera. So I just scaled everything down.

A better solution may be to use z=300 and the ground level, and make vz negative, and g positive.

Then the scale would be:

300/z

Yeah that would look cleaner.

Further reading would be “perspective transform” on Wikipedia or elsewhere. I’ll see if I can make a simpler example/better explanation later.

• ## Try Construct 3

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

Construct 3 users don't see these ads
• Further reading would be “perspective transform” on Wikipedia or elsewhere. I’ll see if I can make a simpler example/better explanation later.

Thanks! I will start reading there!

One more question: is there a (best practise?) reason why you have chosen to use "sprite: add <negative gravity> to <variable>"?

I (n00b me) would have typed: "sprite: subtract <gravity> from <variable>"

ps: I have thanked you in my twitter post, accompanied with a small movie of a falling apple. But I do not know your twitter name, so I used your forum handle.

• No reason really. Adding a negative number is the same as subtraction. Plus it’s faster to change.

I don’t have Twitter. Just here.

• 20 posts