haha, this has gotten so complicated and stuff.
Yep, you are right. This needs some extra tweak, didn’t thought of that - good catch! But otherwise this case also has to be treated special with fixed turn rate (left or right turn)
No, the thing I posted is just fine. I’ve used that exact code elsewhere. You’re not taking into account that it gets called every single time step. Theoretically you make the speed value small (probably < 1) so that it never has too large of an adjustment at one time.
The “velAdjustment” can be seen as the acceleration. If you changed my code to “missilePos += v” as cylab suggested, then it would just move in a straight line towards the target.
This is what happens:
- The missile gets fired at an initial velocity.
- The missile’s velocity gets adjusted as per the code below, so now it’s flying more in the direction of its target.
- The missile’s position gets adjusted by by its velocity (missilePos += missileVel).
- Go back to #2, repeat.
In a ballistic situation, you should never be adjusting the position of something directly. Instead, you adjust the velocity and that in turn gets carried to the position at the update. When you change the velocity, you’re doing so with a given acceleration. Logically that makes sense - you can only ever accelerate something, you can never magically teleport its position somewhere.
If you took my exact code and applied gravity to it, the object would not fall at 9.8 meters per second, it would continue to accelerate at 9.8 meters per second. You’re adjusting the velocity by the acceleration of gravity.
Second 0: Object vel = 0.0 m/s. Object pos = 0,0
Second 1: Object vel = -9.8 m/s. Object pos = 0,-9.8
Second 2: Object vel = -19.6 m/s. Object pos = 0,-29.4
Second 3: Object vel = -29.4 m/s. Object pos = 0,-39.2
etc.
It’s not moving like a “ball of mud,” it’s moving dynamically like a real object would. Adjusting the velocity so that it’s pointing at a given object is exactly the same process.
And as for damping, usually you have a delta involved that does that for you. Like with gravity, you don’t want to be updating only once per second. So if you were updating 60 frames per second, your delta would be 1/60 and so you would apply (1/6) * -9.8 for the acceleration to the object.
Obviously the above would work for something that would need directional rockets on the side as well, but really all homing missiles would need to work that way. You can’t turn the thing by applying different force from the back. Say the missile is going at (-1000,500) but the target is behind it and below it. Its next velocity might become (-950, 450). As long as you point the image of the rocket the right way (and yes, you’ll need atan2 to do that), then it will look like a completely smooth parabolic turn, because although the acceleration is linear the velocity is exponential. If you know your derivatives, this makes sense: x^2’ == x^1.
I haven’t thoroughly understood everything said here (YET) but i think these alternative suggestions are important and i will try them all because i plan to have MANY MANY MANY MANY types of projectiles with different homing or quasi homing properties that all behave differently. If these alternatives allow me to produce different “looking” behaviors that cannot be (easily) reproduced with the original method then thats very good. The projectiles will often be destroyable, so having a different “approach” and movement behaviors towards their targets can mean a lot in my game. Actually even if the original claim that the missile would move like a ball of mud isn’t true thats actually a behavior i might want to try to create… so yeah, thanks a lot for all the extra details, i actually will need it (probably)
I think the ball of mud thing was referring to the missile being able to accelerate in any direction, rather than being constrained by a certain angle around its current velocity. If you wanted to get that, then I would probably use the dot product and cosine rather than atan, but it will all work out the same in the end anyway.