Predict Interception
Author
I've been working on a project for my final college project before i can graduate for my bachelor degree.
And i've run into quite of a problem.
I can't seem to figure out how to calculate where i need to go to intercept my pathfinding players.
The AI is search 'n Destroy and looks for my players which determine their path according to A*.
they have an acceleration or velocity whatever you want to call it.
And they have a yaw to show me what they are looking towards.
Their position is put in a D3DXVECTOR3 so x,y,z
How am i gonna go about calculating their position.
I've found a book that showed me how to do it on a 2d plane but he spoke of a Magnitude function which i've never heard of or seen in his book.
Any ideas?
What i did right now was calculate the distance between them.
Calculate the cell they were in on the grid.
And look in which direction the cell of the player they've seen should be raised or decreased.
I did this by the amount of the distance but that will never work.
// EDIT
Basically i'm trying to figure out.
How to calculate what cell i need to move my AI players to
In order to meet up with my human players.
[Edited by - Darsin on January 26, 2009 6:08:23 AM]
Your description is sort of confusing. You lost me at "an acceleration or velocity whatever you want to call it." Acceleration and velocity are different things, and I don't get to choose what to call it.
If you enter "magnitude" in Google with query suggestions enabled, the first thing it suggests is "magnitude of a vector", which is probably what they are talking about.
Now if you make a more clear question (an example would be great), we can probably help out.
If you enter "magnitude" in Google with query suggestions enabled, the first thing it suggests is "magnitude of a vector", which is probably what they are talking about.
Now if you make a more clear question (an example would be great), we can probably help out.
Author
i've done a little throw-up in paint to illustrate the issue.
2D:
3D:
As seen in the 2nd image.
The green blob thingy saw the red blob thingy and has calculated his path towards that position.
that's the code i have now. works perfectly.
Problem is the red blob thingy moves.
So i want to calculate the position of the purple blob thingy.
According to velocity and the yaw of the red blob thingy in relation to the velocity and distance of the green blob thingy
[Edited by - Darsin on January 26, 2009 6:21:44 AM]
2D:
3D:
As seen in the 2nd image.
The green blob thingy saw the red blob thingy and has calculated his path towards that position.
that's the code i have now. works perfectly.
Problem is the red blob thingy moves.
So i want to calculate the position of the purple blob thingy.
According to velocity and the yaw of the red blob thingy in relation to the velocity and distance of the green blob thingy
[Edited by - Darsin on January 26, 2009 6:21:44 AM]
from my understanding, you might want to try using steering behaviours instead/as well (eg. pursuit)
otherwise it should be a simple matter of predicting which cell the player will be in on the next update- as opposed to pathing towards their current position which is what i believe you are currently doing?
otherwise it should be a simple matter of predicting which cell the player will be in on the next update- as opposed to pathing towards their current position which is what i believe you are currently doing?
Author
That would be a great solution indeed if i had time to redo my entire AI section but sadly i don't.
It would be a nice upgrade since now it's really static and looks kind of shocky.
But we're gonna have to think of a "fairly" quick solution to the prediction and then in my free time i will build on this application to get it to run smoother than it is doing now.
i guess i could find some kind of way to incoorperate both of the methods in a future update.
using steering as soon as they have a target.
It would be a nice upgrade since now it's really static and looks kind of shocky.
But we're gonna have to think of a "fairly" quick solution to the prediction and then in my free time i will build on this application to get it to run smoother than it is doing now.
i guess i could find some kind of way to incoorperate both of the methods in a future update.
using steering as soon as they have a target.
Hehe I remember coding a solution for that problem for a code example that was requested by a potential employer, albeit in 2d.
The best&easiest would be an iterative solution. Cycle between evaluating these values:
-Evaluate "t" the time to reach the other player at position p (using your pathfinding code)
-Guess where ("p") the other player will be at time t
until p and t converges. If the other player is a cpu you can cheat by looking at its pathfinding data to find "p", else if its a user you will have to guess where the player is headed and which path he will take to go there.
edit:
I think I remember what I did back then. Was a tad simpler. Every node in my pathfinding data was an intersection. I had the purser find the shortest path to the intersection his target his running forward that doesnt pass through the current target location. I re-evaluated each time the target pass an intersection. Looked great, depending on how convoluted the map is.
The best&easiest would be an iterative solution. Cycle between evaluating these values:
-Evaluate "t" the time to reach the other player at position p (using your pathfinding code)
-Guess where ("p") the other player will be at time t
until p and t converges. If the other player is a cpu you can cheat by looking at its pathfinding data to find "p", else if its a user you will have to guess where the player is headed and which path he will take to go there.
edit:
I think I remember what I did back then. Was a tad simpler. Every node in my pathfinding data was an intersection. I had the purser find the shortest path to the intersection his target his running forward that doesnt pass through the current target location. I re-evaluated each time the target pass an intersection. Looked great, depending on how convoluted the map is.
You have a heading and a velocity of the target, and the only thing you can do is change your own heading and velocity. Let's assume for a moment that we are both the same speed.
So the only output of the situation is NewHeading.
If the target is running directly away from us, then we should face them. Another way to say this is if the target is presenting it's 6:00, then we should put them in our 12:00. This is also true if the target is charging directly towards us.
If the target is presenting it's side, so that we are looking at it's 3:00 or 9:00, then we should also present our complementary side. That way we are running in parallel, until the target shifts direction.
We now have both extremes: Facing directly at the target, and running parallel, a 90-degree spread. What about the in-between cases, where the target is not facing directly at us nor facing sideways?
Then we have a 90-degree arc of facing for him, and a 90-degree spread of where to put him for us. It maps perfectly.
Now to add speed differences: If the target is moving only half as fast as we are, then the angle difference is only half.
Also, constant bearing means collision. If the heading to target seems to drift, minor corrections can be made to keep it in place.
[Edited by - AngleWyrm on February 6, 2009 1:17:15 AM]
So the only output of the situation is NewHeading.
If the target is running directly away from us, then we should face them. Another way to say this is if the target is presenting it's 6:00, then we should put them in our 12:00. This is also true if the target is charging directly towards us.
If the target is presenting it's side, so that we are looking at it's 3:00 or 9:00, then we should also present our complementary side. That way we are running in parallel, until the target shifts direction.
We now have both extremes: Facing directly at the target, and running parallel, a 90-degree spread. What about the in-between cases, where the target is not facing directly at us nor facing sideways?
Then we have a 90-degree arc of facing for him, and a 90-degree spread of where to put him for us. It maps perfectly.
Now to add speed differences: If the target is moving only half as fast as we are, then the angle difference is only half.
Also, constant bearing means collision. If the heading to target seems to drift, minor corrections can be made to keep it in place.
[Edited by - AngleWyrm on February 6, 2009 1:17:15 AM]
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
