Recalculate trajectory?

Started by
5 comments, last by sammyh 7 years, 7 months ago

There is this spell effect in warcraft called cascade, it looks like this:

Since the players can move after the effect starts to bounce and initial trajectory calculated. How do you calculate the updates frame by frame so that no matter where the target moves to the effect is always heading toward them?

Advertisement

How do you calculate the updates frame by frame so that no matter where the target moves to the effect is always heading toward them?


Pretty much just literally implement that description as code, and that's a reasonable way to do it.

Keep a reference to both the effect and the target of that effect.
Get the difference in position between them, and tell the effect to move in that direction each frame.

You can either base the projectile's speed on the total time-of-flight that you compute at launch (which means you just do some basic interpolation each frame), or you can actually have the projectile "drive" towards the target with whatever kind of seeking logic you want (head straight towards the target, continuously lead the target, etc).

In the arcing effect seen in the video, you could first compute the straight line along the ground to your target, and then set the height as a curve above that straight line. If the target moves, the "straight line" updates itself, and the arc height calculation stays the same.

Remember, when dealing with visual effects you don't NEED to realistically model the position of the projectile. You can fake it as much as you need to until it looks good enough.

Making games is all about cheating... big time. That effect has nothing to do with physics or proper motion, it is simply a trick that looks nice. There are several ways they could pull it off, but given it has to happen on a timer to hit the 'heal tick rate', I suspect it is very simple. If you ignore the trajectory portion, they are basically just interpolating a line between source and target to control the position. So, you interpolate a value 0-1 between two points which track source and target based on the 'tick' rate of the spell. It looks smooth even in 2D without height applied since it still gets to the target at 1 eventually no matter how the source and target move. Then you apply a height value to the particle probably via sine of the 't' in the linear interpolation and some max height.

It is a cheap, dirty hack that looks good. Nothing very fancy, just a lot of cheatery.. :)

tti = time to impact (impact time minus current time)

ptti = previous time to impact (the tti from the previous tick)

displacement = self position - target position

new position = target position + (displacement * (tti/ptti))

void hurrrrrrrr() {__asm sub [ebp+4],5;}

There are ten kinds of people in this world: those who understand binary and those who don't.

Thanks to the both of you, great replies. I was overthinking it a bit. I can probably figure the sine of t method but I don't know how to constrain it to a max height.

you could first compute the straight line along the ground to your target, and then set the height as a curve above that straight line. If the target moves, the "straight line" updates itself, and the arc height calculation stays the same

I'm not sure how to do this, is it something fairly straight forward?

I'm not sure how to do this, is it something fairly straight forward?


Just do what AllEightUp said:

update
{
  interpolatingAlpha = value between 0 (just fired) and 1 (hitting the target) // calculate this based on time or whatever your game needs.
  interpolatedPosition = lerp(startingPosition, targetPosition, interpolatingAlpha) // linear interpolation(from, to, amount)

  interpolatedPosition.Y += maxArcHeight * sin(pi * interpolatingAlpha) // assuming + is up
}

I see, that's really neat. Thanks!

This topic is closed to new replies.

Advertisement