Homing Missile AI in 3space with momentum (hard!)
Hi all,
Im new to these forums, and forums in general, so please bear with me on this.
Some time ago, I had to code a project which was a 3d space combat game. We used a 3d party phyiscs engine for our project.
One of the key points about our game was that it had real physics.
ie: objects have momentum, and move as such; if your going fairly fast in one way, you have to come to a stop by thrusting in the opposite direction.
Objects do not have momentum as they turn, however (ie, an object continues to yaw only as long as its being told to by the player, or AI controlling it, and stops when its tryToYaw value is 0).
In the game objects positions are represnted as 3 space vectors, as are their current velocities.
Objects rotations are represented by quaternions.
A object can be made to roll, pitch, yaw, or thrust by setting its object.tryThrust, object.tryRoll etc. int to a positive % value (clockwise RPY), or a negitve % value to roll pitch or yaw counterclockwise. Same holds for thrust, only it thrusts forward or back.
The problem Im having, is to try and code an AI, which has access to the velocity, orientation and location of or the object its controlling, and some target object, and may modify its own tryThrust, tryRoll etc values.
I need to make it so that an object can be told to
A) move to a certain point in space,
B) try hit an enemy ship, based on ships current trajectory.
I have coded a method which can turn the ship to face a point (given as a vector3); what I need is to use this, and the other info, to get it to fulfill A and B.
The problem lies in the fact that to get a homing missile with momentum, and this rule set, to move somewhere else, it has to deal with where it wants to move to, as well as its current velocity.
I know the problem is solvable, because a human player with said info can home on an enemy.
Solutions like first stopping completely, then turning to face the enemy, and accelerating are easy, but not much use.
Any help towards A or B would be appreciated. I am sure this cannot be an uncommon problem, as something like this must be dealt with in real life, however i cannot find any solutions to this problem in this complex a form easily. Even turning to face the enemy took ages (different ships could have different up vector btw)
Thanks for your help...
feel free to email feral@iolfree.ie with replies etc if not suitable here.
Does it have to be perfect?
and, are you operating in space or in the air?
For a first try, why not just make it head towards the enemy as much as possible, if it misses, just tunr around and try again
and, are you operating in space or in the air?
For a first try, why not just make it head towards the enemy as much as possible, if it misses, just tunr around and try again
I would imagine in space with all the corrections necessary that even a player-piloted missile would be hard to crash into its target at the same point.
Still, though, it's possible. The problem is that if the missile acquires too much velocity, it doesn't take much for the enemy craft to make a small correction and evade it - the missile would REALLY have to punch its lateral thrusters, maybe even slow down, to successfully make a meaningful correction at high speed.
Your best bet for success is to head for a point that is ahead of the target craft. That, or try to come in behind the target craft and pursue by imitating its movements, instead of going for a meet-the-same-point collision.
[edited by - Waverider on June 28, 2002 5:38:30 PM]
Still, though, it's possible. The problem is that if the missile acquires too much velocity, it doesn't take much for the enemy craft to make a small correction and evade it - the missile would REALLY have to punch its lateral thrusters, maybe even slow down, to successfully make a meaningful correction at high speed.
Your best bet for success is to head for a point that is ahead of the target craft. That, or try to come in behind the target craft and pursue by imitating its movements, instead of going for a meet-the-same-point collision.
[edited by - Waverider on June 28, 2002 5:38:30 PM]
It's not what you're taught, it's what you learn.
If I understand your problem correctly, you just need ''seek'' and ''pursuit'' steering behavior. Seek is very easy to implement, pursuit not much harder.
This link will give you the details.
http://www.red3d.com/cwr/steer/
Stimulate
This link will give you the details.
http://www.red3d.com/cwr/steer/
Stimulate
My Website: ai-junkie.com | My Books: 'Programming Game AI by Example' & 'AI Techniques for Game Programming'
Hi all,
thanks for your replies so far.
fup:
Thanks for the link, ive only skimmed it, but will look through it at more detail later.
However, I dont think its really what Im after.
Those seeking/pursuit behavoirs are fine for 2d, when you know the velocities involved.
However, I need the same stuff in 3 space (not hard), but without access to velocities. ie: a ship has an acceleration, not a max velocity.
So if I need to intercept a target using simple linear vector algebra with relative velocities, I need to know my velocity to work out the targets velocity relative to me. However, I dont know my velocity, as it will be some sort of average velocity formed as I accelerate across the distance between my current location and the targets location.
So I could use calculus to work out that velocity, or might even need it, fair enough.
The problem is, I wont know the distance Im flying to intercept until I can work out which direction I should thrust in order to intercept, and this direction itself depends on the distance (coz of velocities).
I cant figure out a way around that.
Thats one problem.
Now assuming we dont worry about the whole relative velocity thing, and we just try find a way of moving towards a point first. We could just update very frequently the target location and use our movetopoint(enemy.location) function lots. Not perfect, but would do the trick.
However, a movetopoint function is hard to develop, as it needs to figure out which direction we should thrust in order to cancel our current velocity components away from the target, and simultaneously increase our velocity towards the target.
This is harder than it sounds, again because we dont have access to velocities, just acclerations.
One solution is to simply take our current velocity, face the opposite way, and thrust until velocity == 0. Then go and face the target location, and thrust until you arrive at it. Thats fine, but very inelegant and leads missiles to behave really awfully. Anything else requires some relative velocity math, which is enormously complicated by the changing velocities of the homing missile.
I am confident that theres a way to solve this, but it doesnt seem to be easy to me.
If we could develop a movetopoint function, for use by an object with nonzero velocity, itd be a start. A function where we then tell it to moveto a targets predicted location instead of its current location would be a step up in complexity and efficiency.
Im sure these exist, but I cant find them...
Waverider:
Im not too bothered about that fact (the missile aquiring too much velocity). Assuming missile acceration is high in comparision with ship acceration, and any sort of decent prediction algorithim the missile should be able to hit its target. Well, not neccessarily hit, because as you pointed out, if its approcahing its target orthogonal to its targets velocity (ie, from the side) a small manuveour by the target will cause the missile too shoot by. However, it will pass _quite close by_, close enough to have its AI detonate its payload and do acceptable damage.
SHO_NUFF:
not perfect, no, just close enough to do enough damage.
Its in space - this means no friction, and considerably adds to the problem. With an atmospheric case, you just have to make the missile keep facing the target, and the missile will develop a max velocity (terminal velocity through atmosphere) which you can use for all the relative velocity calculations.
Again, our space game was unusual it that things behaved faily close to a newtonian physics model of space, unlike most games where things have max velocity, no momentum etc.
any further thoughts towards this problem? Again its one i dont need to solve, (the project is finished) but would really like to know the solution to...
feral
thanks for your replies so far.
fup:
Thanks for the link, ive only skimmed it, but will look through it at more detail later.
However, I dont think its really what Im after.
Those seeking/pursuit behavoirs are fine for 2d, when you know the velocities involved.
However, I need the same stuff in 3 space (not hard), but without access to velocities. ie: a ship has an acceleration, not a max velocity.
So if I need to intercept a target using simple linear vector algebra with relative velocities, I need to know my velocity to work out the targets velocity relative to me. However, I dont know my velocity, as it will be some sort of average velocity formed as I accelerate across the distance between my current location and the targets location.
So I could use calculus to work out that velocity, or might even need it, fair enough.
The problem is, I wont know the distance Im flying to intercept until I can work out which direction I should thrust in order to intercept, and this direction itself depends on the distance (coz of velocities).
I cant figure out a way around that.
Thats one problem.
Now assuming we dont worry about the whole relative velocity thing, and we just try find a way of moving towards a point first. We could just update very frequently the target location and use our movetopoint(enemy.location) function lots. Not perfect, but would do the trick.
However, a movetopoint function is hard to develop, as it needs to figure out which direction we should thrust in order to cancel our current velocity components away from the target, and simultaneously increase our velocity towards the target.
This is harder than it sounds, again because we dont have access to velocities, just acclerations.
One solution is to simply take our current velocity, face the opposite way, and thrust until velocity == 0. Then go and face the target location, and thrust until you arrive at it. Thats fine, but very inelegant and leads missiles to behave really awfully. Anything else requires some relative velocity math, which is enormously complicated by the changing velocities of the homing missile.
I am confident that theres a way to solve this, but it doesnt seem to be easy to me.
If we could develop a movetopoint function, for use by an object with nonzero velocity, itd be a start. A function where we then tell it to moveto a targets predicted location instead of its current location would be a step up in complexity and efficiency.
Im sure these exist, but I cant find them...
Waverider:
Im not too bothered about that fact (the missile aquiring too much velocity). Assuming missile acceration is high in comparision with ship acceration, and any sort of decent prediction algorithim the missile should be able to hit its target. Well, not neccessarily hit, because as you pointed out, if its approcahing its target orthogonal to its targets velocity (ie, from the side) a small manuveour by the target will cause the missile too shoot by. However, it will pass _quite close by_, close enough to have its AI detonate its payload and do acceptable damage.
SHO_NUFF:
not perfect, no, just close enough to do enough damage.
Its in space - this means no friction, and considerably adds to the problem. With an atmospheric case, you just have to make the missile keep facing the target, and the missile will develop a max velocity (terminal velocity through atmosphere) which you can use for all the relative velocity calculations.
Again, our space game was unusual it that things behaved faily close to a newtonian physics model of space, unlike most games where things have max velocity, no momentum etc.
any further thoughts towards this problem? Again its one i dont need to solve, (the project is finished) but would really like to know the solution to...
feral
You''re confusing me. One second you say you don''t have the velocity, the next you say you do. As an example...
Also, all Reynold''s steering behaviors work just as well in 3D as in 2D. You just have to be careful of the dreaded gimbal lock, but then I''m sure you''ll have solved that problem already.
Stimulate
quote: This is harder than it sounds, again because we dont have access to velocities, just acclerations.
One solution is to simply take our current velocity, face the opposite way, and thrust until velocity == 0. Then go and face the target location, and thrust until you arrive at it.
Also, all Reynold''s steering behaviors work just as well in 3D as in 2D. You just have to be careful of the dreaded gimbal lock, but then I''m sure you''ll have solved that problem already.
Stimulate
My Website: ai-junkie.com | My Books: 'Programming Game AI by Example' & 'AI Techniques for Game Programming'
Yikes, sorry about the confusion.
What I mean is that while we do have access to an objects velocity at any one time, we do not have access to what will be its average velocity between now and the time it intersects the target.
The latter is what we really need to have access to in order to do the proper relative velocity calculations, imo. However, it also depends on the outcome of said calculations, which is where I get lost.
I dont believe gimbal lock is an issue anymore - all the math was done with quaternions, and the facePoint method does some pretty clever absolute quaternion orientation to desired roll/pitch/yaw thrust values.
What I mean is that while we do have access to an objects velocity at any one time, we do not have access to what will be its average velocity between now and the time it intersects the target.
The latter is what we really need to have access to in order to do the proper relative velocity calculations, imo. However, it also depends on the outcome of said calculations, which is where I get lost.
I dont believe gimbal lock is an issue anymore - all the math was done with quaternions, and the facePoint method does some pretty clever absolute quaternion orientation to desired roll/pitch/yaw thrust values.
June 28, 2002 10:10 PM
neural net maybe? it checks to see whether it is closer or farther away from the object than last time?
All you need is the current velocity. It's this value that's used to do all the calculations...
For example:
forgive any typos - I've only just woken up.
Stimulate
[edited by - fup on June 29, 2002 2:33:52 AM]
For example:
//all the info you needstruct moving_object{ 3DVector velocity; 3DVector position; double MaxSpeed;};//the 'seek' steering behavior.3DVector Seek(const 3DVector ⌖, const moving_object &Player){ 3DVector ToTarget = Normalize(target - Player.position); return Player.vel - (ToTarget * Player.MaxSpeed);}
forgive any typos - I've only just woken up.
Stimulate
[edited by - fup on June 29, 2002 2:33:52 AM]
My Website: ai-junkie.com | My Books: 'Programming Game AI by Example' & 'AI Techniques for Game Programming'
Deleted due to repetition.
[edited by - fup on June 29, 2002 2:36:50 AM]
[edited by - fup on June 29, 2002 2:36:50 AM]
My Website: ai-junkie.com | My Books: 'Programming Game AI by Example' & 'AI Techniques for Game Programming'
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement