Jump to content
  • Advertisement

Archived

This topic is now archived and is closed to further replies.

Homing Missile AI in 3space with momentum (hard!)

This topic is 5800 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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.

Share this post


Link to post
Share on other sites
Advertisement
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

Share this post


Link to post
Share on other sites
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]

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
You''re confusing me. One second you say you don''t have the velocity, the next you say you do. As an example...

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

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
neural net maybe? it checks to see whether it is closer or farther away from the object than last time?

Share this post


Link to post
Share on other sites
All you need is the current velocity. It's this value that's used to do all the calculations...

For example:


//all the info you need
struct moving_object
{
3DVector velocity;

3DVector position;

double MaxSpeed;
};




//the 'seek' steering behavior.
3DVector Seek(const 3DVector &target, 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]

Share this post


Link to post
Share on other sites

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

Participate in the game development conversation and more when you create an account on GameDev.net!

Sign me up!