I'm creating a TD game with MMF 1.5.
When a enemy comes in range they'll shoot.
But witch enemy should they shoot at?
And if i just decide they'll shoot a random enemy, maybe they'll shoot at somone less important when the castle actually is in great danger.
How should i make the towers AI?
You set up a list of enemies, sorted by threat level. Then you make it so that each tower starts checking for enemies from the top of the list. If it finds an enemy in range, it attacks it; if it doesn't, it continues to the next enemy on the list.
Well okay, you don't need to set up an actual list, but you get the idea.
And then make the towers prioritize, so that they shoot enemies with higher threat first.
n/a
Peblo Custom ratings must be 50 characters or less
Registered 05/07/2002
Points 185
2nd May, 2007 at 13:51:18 -
With a lot of enemies though, that distance formula won't work... unless you want an awful amount of slowdown. I was testing it near 500+ objects though.
"Isn't it always amazing how we characterize a person's intelligence by how closely their thinking matches ours?"
~Belgarath
Well, I have yet to see a TD game with 500 enemies on-screen at the same time.
n/a
Peblo Custom ratings must be 50 characters or less
Registered 05/07/2002
Points 185
2nd May, 2007 at 14:30:57 -
Eo Neo was meant to be a tower defense game originally, but slowdown issues made me change it slightly.
For the tower AI, you could possibly try this: Have the turret pick the closest enemy in range, and have it 'lock on' to that enemy until the enemy leaves the range of the tower. Then the tower would pick a new target and repeat.
"Isn't it always amazing how we characterize a person's intelligence by how closely their thinking matches ours?"
~Belgarath
I'd say go with the previous suggestions.
Before I go any further, I haven't actually done anything to test this.
Anyways, apparently computers are relatively slow at calculating square-roots, since it's far more complicated than just adding or subtracting or whatever (see http://en.wikipedia.org/wiki/Methods_of_computing_square_roots ). Unless you desperately need to know the distance in actual pixels (which you don't in this instance) you can skip the square-root part altogether, and maybe get less slowdown with lots of active objects. Like I said, never tested it so don't know, but would be interested to find out.
Also, there's an extension called the "value finder" object (I forget the author) which could be very useful in helping you find the closest object with the minimum of hassle and code.
The only other suggestion I'd have, is to build some other factors into the "threat" rating if neccessary. Like maybe an enemy catapult would pose a greater threat than a swordsman at the same range. I don't know how your game works so I can't give a better example, but you get the idea. Obviously that means more calculation and less speed though.
The alternative would be to use a circular active object as a detector, but I'm not sure if that'd be faster than calculating the distance directly. You could also avoid square roots by using the slightly less accurate "manhattan method": ΔX + ΔY.
The Euclidean distance is the straight-line distance between two points. It is calculated using Pythagorus' theorum, and is sometimes referred to as "Pythagorean distance".
Computers are relatively slow at calculating square-roots. The following approximation avoids doing so, but remains accurate to within 3% of the actual distance.
The Chebyshev (Tchebyshev) distance is similar to the Manhattan distance, but allowing for vertical, horizontal, and diagonal movement. An analogy would be the number of squares a king or queen would have to cover, in order to move between the two points on a chessboard.
Distance = Max(Abs(X1 - X2), Abs(Y1 - Y2))
The Manhattan distance can be thought of as the distance between two squares in a grid, allowing only vertical and horizontal movement. An analogy would be the number of squares a rook would have to cover, in order to move between the two points on a chessboard. This is the least accurate method (furthest from the Euclidean distance).
they're not just for grid based games, though the chessboard analogy is a bit confusing (and they are *really* useful for grid movement). you can imagine each screen pixel as a grid square. if you look at the example file, you'll see that the Chebyshev distance is actually a very close approximation in spite of its simplicity (Manhattan less so).
Advertisement
Post Reply
Edited by the Author.
