Tower Defense games: How they're made?

Question

I've done a bit of research (about a friggin hours worth) and have come up relatively empty on how these tower defense games are created. Generally speaking I figure if I learn how certain situations are handled in TD games, I can gain a good insight into other forms of android games. I have a few general questions I hope you smart folks could give me some insight on, or at least point me to somewhere I can get some information.

1. How is pathing handled? The only assumption I can make is the actual path is drawn as a background image, the enemies are drawn as regular images (maybe repainting at a fast rate to create animation?) and the points at which they turn are just coordinates on the screen... I'm sure it has to be more complicated than that...

2. Considering my assumption was somewhere in the ballpark for #1, how is targeting handled? How is shooting animation handled - i.e. does a tower firing an arrow actually create an arrow entity that travels to a predetermined destination and, once there, inflict damage or miss, or is the arrow simply an animation and hit/miss/damage is predetermined at some point?

Those are probably stupid questions given how vague and... inarticulate they are, but I'm not sure how to phrase the question to get the answer I'm looking for. Basically: When I am creating a Tower Defense style game, Am I creating a virtual world with individual entities that affect each other in real-time, or am I creating a pseudo world, simply a stage for background events? Whats the first step in learning the concepts I can use to create such an environment?

I'm sure there are some frameworks or libraries out there that already include a bunch of pre-built stuff to handle this kindof stuff, but using someone else's pre-fab game wouldn't exactly be a solid learning experience for me. That would teach me how to use what's there, I wanna learn why its there, where it is and figure the how out on my own.

Answer 1

I think the crux of your question is whether the graphics play a big part in the logic/simulation of the game. Without looking at actual implementations of such games I would wager heavily that they do not.

You would want to represent the path as a list or array of discrete spots that the attackers can occupy. It would most likely be in two-dimensional space; I haven't seen 3D tower defense games. But then, I've only played a few.

(Another approach could be to represent the path as a piecewise function / series of curves, but the math to determine next step would be much more intense. I would possibly prefer to bite the bullet and plot out paths as described above.)

The locations where the towers can be built would also be represented as coordinates.

You would then start a loop that on each iteration takes (at least) the following into account:

• For each enemy, what is its next step? Maybe it only steps every N iterations of the loop (for a slow enemy) or maybe it takes N steps for every iteration (fast enemies).
• For each tower, what enemies are in range? I'd think you would have to iterate over the list of current enemies, or perhaps you could maintain a list of tiles that are within range and check them for enemies that are present. If an enemy is in range, is the tower allowed to fire at it? (For instance it takes N shots per iteration or shoots once every N iterations). If it does shoot, you calculate damage and see if the enemy is still alive.

As for the question of how to shoot an arrow that travels across space and time, I do think it will be deterministic but there are likely several approaches. However, it will be deterministic. Either you could delay the animation that is on screen by several iterations so that you can animate what happened when the tower shot the arrow, or you could calculate where the arrow is going to intercept N iterations from now and essentially your arrow is a tower of its own that is not at a fixed point but moves a predetermined path and has a predetermined target.

Just some thoughts on the subject. But the gist is that what you see on the screen is just a representation of internal game state, not "the real world".