Re: [pygame] trajectory
A more involved example, but a great site is red3d's steering movements. To do heat seeking missiles, you use the seek behavior. http://www.red3d.com/cwr/steer/ On Fri, Jul 22, 2011 at 11:45 AM, Joe Ranalli wrote: > Homing missile is by far the easiest thing to code. Every clock tick, find > the vector between the bullet and the target, move the bullet in that > direction according to its velocity. As long as the bullet speed is fast > relative to the target, it will eventually hit it. -- Jake
Re: [pygame] trajectory
Homing missile is by far the easiest thing to code. Every clock tick, find the vector between the bullet and the target, move the bullet in that direction according to its velocity. As long as the bullet speed is fast relative to the target, it will eventually hit it. On Fri, Jul 22, 2011 at 11:56 AM, James Paige wrote: > In most (but maybe not all) tower defense games I have ever played, > bullets *can* change direction in flight, and do behave like homing > missles. This isn't obvious visually if the bullets are fast, but it is > pretty common in tower defense games that if a target is in range when > the bullet is launched that it will always hit the target no matter how > it moves. > > That being said, I don't have any idea if Nathan Biagini wants to make > his own tower defense game work that way or not :) > > --- > James Paige > > > On Fri, Jul 22, 2011 at 08:24:51AM -0700, Lee Buckingham wrote: > >Unless the bullet can change direction in flight, it will have to > choose > >one, and only one spot to aim for, and therefore, one vector to guide > it. > >Homing missiles are a lot different to code for, since they have to > adjust > >course, and potentially deal with a synthesized form of inertia. > > > >A bifurcating tree of solutions seems to suggest looking at all > possible > >'likely' positions for the target in the future. That's not so much > >vector math as it is statistics and player-psychology. > > > >You also probably don't want to deal with linear solutions to this > >problem, unless you really really need pinpoint accuracy on each shot > >(again, assuming NOTHING changes direction or speed after a shot is > fired, > >which makes all that accuracy useless anyway). Breaking it up into > steps > >that are a little smaller than the clipping rectangles involved will > >probably get you more than close enough. Furthermore, there will be a > >different solution to the linear form of the problem for every firing > >angle (wide angles intercept later, etc...) It would get pretty ugly. > > > >It might suit better to 'fudge' in a calculation. Make an estimated > >change (just add a constant or something) to the current position of > the > >target, based on it's speed and direction, and fire at that position. > >Divide the x and y distance to the target each by the speed of your > bullet > >(you don't even NEED to do the trigonometry for speed calculations, > the > >player wouldn't notice much anyway) and make the bullet move that much > in > >the x and y directions each tick. Try it out... are your shots firing > too > >far ahead? Too far behind?? Change the estimation constant a little > bit > >and try again. If the target is in close, you might have to reduce > the > >estimate a bit, etc... You can probably tweak this one enough to > have a > >very satisfying "firing computer" without having to go through the > hassle > >of reading the physics chapter on ballistics. > > > >Just a few ideas... > > > >-Lee- > > > >On Fri, Jul 22, 2011 at 7:21 AM, Joe Ranalli > wrote: > > > > I'm not totally clear on what you're asking. If you're saying that > the > > targets might change direction after the bullet is fired, but you > still > > want the bullet to hit the target, then my second algorithm wouldn't > > work. That just doesn't make any sense. The algorithm I suggested > aims > > at the target, then shoots at it. If the target changes direction, > then > > it will no longer go to the spot you were aiming. > > > > If you're having this much trouble figuring this out I would > definitely > > suggest you take some time to sit down and think about what it is > you're > > trying to do and maybe read about some simple physics. This part of > the > > application really shouldn't be that difficult to figure out. > > > > On Fri, Jul 22, 2011 at 9:08 AM, Nathan BIAGINI < > nathan.o...@gmail.com> > > wrote: > > > >Hi. Thanks all for you replies i have one more question before > trying > >to write something on top of that, your algorithme Joe, does it > works > >if the way has some bifurcations, i mean, a fully linear way but > that > >contain bifurcations. > > > >Thanks. > > > >2011/7/20 Joe Ranalli > > > > It depends what you're trying to do. > > > > If you draw the straight line between the tower and the enemy > and > > use that vector to translate a bullet each tick, the bullets > might > > miss the enemy. Think about it this way, the bullet moves 2 > steps > > toward the enemy, then the enemy moves 1 step, then the bullet > moves > > 2, etc. Because the enemy moves the bullet will have to change > its > > direction through the flight. So you could calculate the > direction > > vector between the
Re: [pygame] trajectory
In most (but maybe not all) tower defense games I have ever played, bullets *can* change direction in flight, and do behave like homing missles. This isn't obvious visually if the bullets are fast, but it is pretty common in tower defense games that if a target is in range when the bullet is launched that it will always hit the target no matter how it moves. That being said, I don't have any idea if Nathan Biagini wants to make his own tower defense game work that way or not :) --- James Paige On Fri, Jul 22, 2011 at 08:24:51AM -0700, Lee Buckingham wrote: >Unless the bullet can change direction in flight, it will have to choose >one, and only one spot to aim for, and therefore, one vector to guide it. >Homing missiles are a lot different to code for, since they have to adjust >course, and potentially deal with a synthesized form of inertia. > >A bifurcating tree of solutions seems to suggest looking at all possible >'likely' positions for the target in the future. That's not so much >vector math as it is statistics and player-psychology. > >You also probably don't want to deal with linear solutions to this >problem, unless you really really need pinpoint accuracy on each shot >(again, assuming NOTHING changes direction or speed after a shot is fired, >which makes all that accuracy useless anyway). Breaking it up into steps >that are a little smaller than the clipping rectangles involved will >probably get you more than close enough. Furthermore, there will be a >different solution to the linear form of the problem for every firing >angle (wide angles intercept later, etc...) It would get pretty ugly. > >It might suit better to 'fudge' in a calculation. Make an estimated >change (just add a constant or something) to the current position of the >target, based on it's speed and direction, and fire at that position. >Divide the x and y distance to the target each by the speed of your bullet >(you don't even NEED to do the trigonometry for speed calculations, the >player wouldn't notice much anyway) and make the bullet move that much in >the x and y directions each tick. Try it out... are your shots firing too >far ahead? Too far behind?? Change the estimation constant a little bit >and try again. If the target is in close, you might have to reduce the >estimate a bit, etc... You can probably tweak this one enough to have a >very satisfying "firing computer" without having to go through the hassle >of reading the physics chapter on ballistics. > >Just a few ideas... > >-Lee- > >On Fri, Jul 22, 2011 at 7:21 AM, Joe Ranalli wrote: > > I'm not totally clear on what you're asking. If you're saying that the > targets might change direction after the bullet is fired, but you still > want the bullet to hit the target, then my second algorithm wouldn't > work. That just doesn't make any sense. The algorithm I suggested aims > at the target, then shoots at it. If the target changes direction, then > it will no longer go to the spot you were aiming. > > If you're having this much trouble figuring this out I would definitely > suggest you take some time to sit down and think about what it is you're > trying to do and maybe read about some simple physics. This part of the > application really shouldn't be that difficult to figure out. > > On Fri, Jul 22, 2011 at 9:08 AM, Nathan BIAGINI > wrote: > >Hi. Thanks all for you replies i have one more question before trying >to write something on top of that, your algorithme Joe, does it works >if the way has some bifurcations, i mean, a fully linear way but that >contain bifurcations. > >Thanks. > >2011/7/20 Joe Ranalli > > It depends what you're trying to do. > > If you draw the straight line between the tower and the enemy and > use that vector to translate a bullet each tick, the bullets might > miss the enemy. Think about it this way, the bullet moves 2 steps > toward the enemy, then the enemy moves 1 step, then the bullet moves > 2, etc. Because the enemy moves the bullet will have to change its > direction through the flight. So you could calculate the direction > vector between the bullet and the enemy every tick and have the > bullet move that direction. That would make the bullets kind of arc > to the target. > > If you want to have the bullet go straight to the right spot, you > need to: > 1) calculate how long the bullet will take to get to the enemy > 2) calculate where the enemy will be at that time (newposition) > 3) calculate how long it will take the bullet to get to newposition > 4) recalculate newposition based on the new time > > Tec
Re: [pygame] trajectory
Unless the bullet can change direction in flight, it will have to choose one, and only one spot to aim for, and therefore, one vector to guide it. Homing missiles are a lot different to code for, since they have to adjust course, and potentially deal with a synthesized form of inertia. A bifurcating tree of solutions seems to suggest looking at all possible 'likely' positions for the target in the future. That's not so much vector math as it is statistics and player-psychology. You also probably don't want to deal with linear solutions to this problem, unless you really really need pinpoint accuracy on each shot (again, assuming NOTHING changes direction or speed after a shot is fired, which makes all that accuracy useless anyway). Breaking it up into steps that are a little smaller than the clipping rectangles involved will probably get you more than close enough. Furthermore, there will be a different solution to the linear form of the problem for every firing angle (wide angles intercept later, etc...) It would get pretty ugly. It might suit better to 'fudge' in a calculation. Make an estimated change (just add a constant or something) to the current position of the target, based on it's speed and direction, and fire at that position. Divide the x and y distance to the target each by the speed of your bullet (you don't even NEED to do the trigonometry for speed calculations, the player wouldn't notice much anyway) and make the bullet move that much in the x and y directions each tick. Try it out... are your shots firing too far ahead? Too far behind?? Change the estimation constant a little bit and try again. If the target is in close, you might have to reduce the estimate a bit, etc... You can probably tweak this one enough to have a very satisfying "firing computer" without having to go through the hassle of reading the physics chapter on ballistics. Just a few ideas... -Lee- On Fri, Jul 22, 2011 at 7:21 AM, Joe Ranalli wrote: > I'm not totally clear on what you're asking. If you're saying that the > targets might change direction after the bullet is fired, but you still want > the bullet to hit the target, then my second algorithm wouldn't work. That > just doesn't make any sense. The algorithm I suggested aims at the target, > then shoots at it. If the target changes direction, then it will no longer > go to the spot you were aiming. > > If you're having this much trouble figuring this out I would definitely > suggest you take some time to sit down and think about what it is you're > trying to do and maybe read about some simple physics. This part of the > application really shouldn't be that difficult to figure out. > > > On Fri, Jul 22, 2011 at 9:08 AM, Nathan BIAGINI wrote: > >> Hi. Thanks all for you replies i have one more question before trying to >> write something on top of that, your algorithme Joe, does it works if the >> way has some bifurcations, i mean, a fully linear way but that contain >> bifurcations. >> >> Thanks. >> >> 2011/7/20 Joe Ranalli >> >>> It depends what you're trying to do. >>> >>> If you draw the straight line between the tower and the enemy and use >>> that vector to translate a bullet each tick, the bullets might miss the >>> enemy. Think about it this way, the bullet moves 2 steps toward the enemy, >>> then the enemy moves 1 step, then the bullet moves 2, etc. Because the >>> enemy moves the bullet will have to change its direction through the >>> flight. So you could calculate the direction vector between the bullet and >>> the enemy every tick and have the bullet move that direction. That would >>> make the bullets kind of arc to the target. >>> >>> If you want to have the bullet go straight to the right spot, you need >>> to: >>> 1) calculate how long the bullet will take to get to the enemy >>> 2) calculate where the enemy will be at that time (newposition) >>> 3) calculate how long it will take the bullet to get to newposition >>> 4) recalculate newposition based on the new time >>> >>> Technically you could iterate that repeatedly until newposition >>> converges. Practically, iterating once probably gets you close enough >>> unless the movement is extremely complicated. >>> >>> >>> On Wed, Jul 20, 2011 at 9:14 AM, Nathan BIAGINI >>> wrote: >>> Hi everyone, i would like to know what are the common way to handle "trajectory" in a 2d game. In fact, i think of writing a tower defense game and i wonder how to handle the trajectory of the missile launch by the towers. I though of getting the pos of the tower and the target and create a vector between this two entitites to make a sprite translation of this vector but there is maybe some tricky stuff to do it. Thanks in advance and happy game making all :-) >>> >>> >> >
Re: [pygame] trajectory
I'm not totally clear on what you're asking. If you're saying that the targets might change direction after the bullet is fired, but you still want the bullet to hit the target, then my second algorithm wouldn't work. That just doesn't make any sense. The algorithm I suggested aims at the target, then shoots at it. If the target changes direction, then it will no longer go to the spot you were aiming. If you're having this much trouble figuring this out I would definitely suggest you take some time to sit down and think about what it is you're trying to do and maybe read about some simple physics. This part of the application really shouldn't be that difficult to figure out. On Fri, Jul 22, 2011 at 9:08 AM, Nathan BIAGINI wrote: > Hi. Thanks all for you replies i have one more question before trying to > write something on top of that, your algorithme Joe, does it works if the > way has some bifurcations, i mean, a fully linear way but that contain > bifurcations. > > Thanks. > > 2011/7/20 Joe Ranalli > >> It depends what you're trying to do. >> >> If you draw the straight line between the tower and the enemy and use that >> vector to translate a bullet each tick, the bullets might miss the enemy. >> Think about it this way, the bullet moves 2 steps toward the enemy, then the >> enemy moves 1 step, then the bullet moves 2, etc. Because the enemy moves >> the bullet will have to change its direction through the flight. So you >> could calculate the direction vector between the bullet and the enemy every >> tick and have the bullet move that direction. That would make the bullets >> kind of arc to the target. >> >> If you want to have the bullet go straight to the right spot, you need to: >> 1) calculate how long the bullet will take to get to the enemy >> 2) calculate where the enemy will be at that time (newposition) >> 3) calculate how long it will take the bullet to get to newposition >> 4) recalculate newposition based on the new time >> >> Technically you could iterate that repeatedly until newposition >> converges. Practically, iterating once probably gets you close enough >> unless the movement is extremely complicated. >> >> >> On Wed, Jul 20, 2011 at 9:14 AM, Nathan BIAGINI wrote: >> >>> Hi everyone, >>> >>> i would like to know what are the common way to handle "trajectory" in a >>> 2d game. In fact, i think of writing a tower defense game and i wonder how >>> to handle the trajectory of the missile launch by the towers. I though of >>> getting the pos of the tower and the target and create a vector between this >>> two entitites to make a sprite translation of this vector but there is maybe >>> some tricky stuff to do it. >>> >>> Thanks in advance and happy game making all :-) >>> >> >> >
Re: [pygame] trajectory
Hi. Thanks all for you replies i have one more question before trying to write something on top of that, your algorithme Joe, does it works if the way has some bifurcations, i mean, a fully linear way but that contain bifurcations. Thanks. 2011/7/20 Joe Ranalli > It depends what you're trying to do. > > If you draw the straight line between the tower and the enemy and use that > vector to translate a bullet each tick, the bullets might miss the enemy. > Think about it this way, the bullet moves 2 steps toward the enemy, then the > enemy moves 1 step, then the bullet moves 2, etc. Because the enemy moves > the bullet will have to change its direction through the flight. So you > could calculate the direction vector between the bullet and the enemy every > tick and have the bullet move that direction. That would make the bullets > kind of arc to the target. > > If you want to have the bullet go straight to the right spot, you need to: > 1) calculate how long the bullet will take to get to the enemy > 2) calculate where the enemy will be at that time (newposition) > 3) calculate how long it will take the bullet to get to newposition > 4) recalculate newposition based on the new time > > Technically you could iterate that repeatedly until newposition converges. > Practically, iterating once probably gets you close enough unless the > movement is extremely complicated. > > > On Wed, Jul 20, 2011 at 9:14 AM, Nathan BIAGINI wrote: > >> Hi everyone, >> >> i would like to know what are the common way to handle "trajectory" in a >> 2d game. In fact, i think of writing a tower defense game and i wonder how >> to handle the trajectory of the missile launch by the towers. I though of >> getting the pos of the tower and the target and create a vector between this >> two entitites to make a sprite translation of this vector but there is maybe >> some tricky stuff to do it. >> >> Thanks in advance and happy game making all :-) >> > >
Re: [pygame] trajectory
> i would like to know what are the common way to handle "trajectory" in a 2d > game. http://hyperphysics.phy-astr.gsu.edu/hbase/traj.html
