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 <[email protected]>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 <[email protected]> > 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 < > [email protected]> > > 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 <[email protected]> > > > > 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 > > <[email protected]> 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 :-) >
