Re: [pygame] trajectory

[James Paige <Bob@xxxxxxxxxxxxxxxxxxx>]

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 <jranalli@xxxxxxxxx> 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.open@xxxxxxxxx>
>      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 <jranalli@xxxxxxxxx>
> 
>          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
>          <nathan.open@xxxxxxxxx> 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 :-)