• News

• Industries

• Learning & Support

• Community

• Marketplace # projectile trajectory prediction

So I am doing a tower defence project at the moment and while there are a few workarounds for this problem that I am aware of, I would like to try and figure out a way to guarantee a hit on a character with a projectile spawned by a tower by using an actual projectile and not by instant damage etc. Even if I go down the route of just applying the damage independently I would still like to be able to animate in a straight line an attack coming from the tower to hit the character.

So the problem comes from the fact that a projectile takes time to get to a moving character, for example a character running perpendicular past a tower. I have the angle of the firing matching up to the characters rotation correctly from the tower, but obviously since he is running past the tower I would need to fire where he is going to be, not where he is when I hit the fire button.

So while the math itself is not too complicated to figure out; speed of the character, his current path, distance from the tower and speed of the projectile, it does seem like a fairly complex thing that I thought perhaps somebody else might have put together a blueprint macro already that I could check out?

I can take a look at my AA artillery targeting code. It’s was actually harder to make it miss a target in realistic way Math goes like this:
Distance to target / Speed of projectile = Time to reach target
(Time to reach target * Velocity of target) + Current position of target = Position where target and projectile will collide

Actual blueprint is a bit more complicated as I’m adding randomness to projectile speed, distance to target and target velocity.
Model assumes that distance between target and gun doesn’t change drastically while projectile is flying. In my case this is true as AA shells and bullets move much faster than airplain >10x.
If that’s not a case for you, like projectile is moving just 2 times faster than target then you have to estimate time twice:

• assume that distance won’t change and calculate collision point as before
• now measure distance to collision point instead of target and use it to recalculate new collision point

I can check my code in the evening, but I don’t think there was anything else important there.

Thanks thats pretty much what I had figured the math would be, however like you said if the projectile is not moving much faster than the actual character then it introduces another problem.

My characters will actually be moving and turning through a maze so they will have a lot of 90degree turns in there, so I think I will have to use their spline path and calculate what their position along that path will be at the time when the projectile will arrive there, which could quite possibly make it easier since I can figure out an exact position instead of an estimate. Guess I will probably have to do the math for it manually.

In this case you might want to calculate estimate twice, just in case target does a 90 degree turn.

I done something similar to this, where an actor was firing a projectile at an actor that was moving along a spline. (This was for running characters throwing a ball to each other). You need to know where the moving actor will be by the time the projectile reaches them, and launch to that point yeah.
I modified the SuggestProjectileVelocity node to also return time in flight, and used that time to predict where the actor would be along the spline, but that only worked for me as I was using a timeline to control where the actor was on the spline, so they were always moving at a constant spped. But, since you can get a point on a spline as time along spline (0-1), it could be approximated if you have the velocity of the actor I suppose. I done the calculation 3 times, using the returned time for each successive calculation to get it more accurate