You get the Vy from this equation:

y = h + Vy * t - g * t² / 2

If you know "t" (time of flight), then y = 0 when the projectile has flown "t" time. Or in other words, the projectile hits ground (y = 0) after time (t) has passed. So you can insert y as 0 and your chosen t to the function.

From this formula you eventually get:

Vy = gt/2 - h/t.

If your projectiles are thrown "up" or towards the top of the layout you need to take the opposite of this function since in Construct that is negative speed (y is decreasing while traveling to that direction), so we use:

Vy = -(gt/2 - h/t).

I actually improved my example. In this version you can also choose to manipulate Vx since I realized that might usually be more useful that using t as a constant. Remember you could also calculate the time of flight or Vx based on the distance between the player and enemy or any other factor you want, which will give you more tools to tweak the trajectory just the way you want it.

Improved example:

dropbox.com/s/lrnqt7iy21t82t6/Trajectory_Improved.c3p

Hi!

The important thing while calculating trajectory is that you need to figure out which parts of the equation you want to set as constants. This is my example using the "time of flight" and "gravity" as constants. You might want to play around the the trajectory equation if you want to for example change the angle of trajectory or Vx component to be the primary constant.

dropbox.com/s/vg0shir90yxwtcz/Trajectory.c3p

Useful link for the equations:

omnicalculator.com/physics/trajectory-projectile-motion

WackyToaster,

What do you mean by changing the image points and 9 patch? I've never heard of 9 patch before.

I'm still playing around with it and I really want to know how to do it with image points as well as move to. (I need to learn everything)

I messed around with the image point some more, but the thing still goes up in there air.

I changed a bit of it and reuploaded it if you'd like to see what I've done since (messed up since)

https://drive.google.com/file/d/15K2aOkcPutqi1mmGooQc5Kgx0BdVIAhg/view?usp=sharing

Thanks.

The player sprite goes up because you haven't set the image point to the same point in the middle of the player "body" in all animation frames.

You really should not use that method though. It's clunky and uses a lot of unneeded animation.

I didn't notice blackhornet's example. That tiled background method seems better than my method, thou.

Hi,

I think I made it work the way you want.

dropbox.com/s/28xyd2vbsic9ex8/monsters.c3p

Thanks, this actually helps a lot when designing how to use effects. I did notice a slowdown when I moved the effects as much as possible to layers, and this certainly explains why.

Hi,

Let's say that you use a specific effect, "brightness" for example. If you have conditions that affect the effect level of all instances equally it makes sense to control the effect by applying it to the layer the instances are placed in (if you can set a layer of their own for all these instances). It's supposed to increase performance. But if you have conditions that affect individual instances' "brightness" you have to add the effect directly to the object as well.

But how should you set things if you have a combination of both situations mentioned above, meaning some conditions affect the effect levels of all the instances while some conditions only affect individual instances? If you in that case apply the effect to both the object and the layer, does that cause double rendering work that could be avoided by only having the effect added to the object? Or does it still increase performance if you can control the effect as much as possible through a layer, even though you in some conditions are still forced to also individually control the instance effect levels.