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 :-)