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 <jrana...@gmail.com> 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 <jrana...@gmail.com> > > 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.o...@gmail.com> 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 :-)