1
\$\begingroup\$

For my map, it's very curvy and the node sizes aren't consistent. I have everything finished so that projectiles will actually fly at an enemy, however if a projectile is going too slow it will miss. I am wondering if I should just go the easy route, and just make the projectile homing, or if I could get help here on where to start. The enemy is changing directions, and moving around, although never changes speed.

\$\endgroup\$
  • \$\begingroup\$ I guess I'm asking where I'm supposed to start. \$\endgroup\$ – jacob24068 Apr 12 '18 at 0:51
  • 1
    \$\begingroup\$ Can you show us what your map and enemy movement patterns look like? Remember we've never seen your game before, so taking the time to bring us up to speed on how it works can ensure the answers you get are relevant to what you need. \$\endgroup\$ – DMGregory Apr 12 '18 at 1:49
1
\$\begingroup\$

I'm unsure if this is for the purposes of the look of the game, or if it's for balance.

  • If it's for balance, I think projectile speed is totally fair as an attribute the user will have to consider. In this case, just don't worry about it and perform "real" hit detection. Some users (like myself) like this.

  • If it's for looks and you don't want speed to be part of the balance, I think you could "predict" where something will be (after you've chosen your target so you don't waste tons of calculation time on objects you're not firing at) by (without displaying it) having the move function occur several times and the firing angle/time-to-target occur several times, then pick which one is a hit, then let the game use those values.

This would look something like: `

Target = someCreatureObject
OldPosition = Target.Position

for (i=0; i<5; i++)
    Target.Move()
    if(Tower.FramesToTarget() == i)
        PositionToAimAt = Target.Position
        break
Target.Position = OldPosition
return PositionToAimAt

` Where FramesToTarget would be some calculation of the speed vs. the distance. A note: you'll have to give yourself a way to know if none of the positions it could shoot would hit and then decide what to do from there.

This would make the coding a tiny bit easier, but I don't think the function I posted would be too hard.

I'll mention that one of the original Tower Defense games (my favorite of them) Flash Element TD had a mix of projectile speeds and I believe used homing (you can tell if you use the cannons.) This homing was virtually un-noticable.

NOTE: in all of the above cases, Area of Effect weapons should use real hit detection for the AOE damage after decided where the hit occurs.

\$\endgroup\$
1
\$\begingroup\$

Even if you could predict the enemy's movement, you mentioned they might change direction, so that would either not work or be too complicated.

My favourite way is to make the missile homing. Keep the enemy's position in the missile's code as target (careful, don't keep a copy of it, keep a reference of it, so you get enemy's new position). Every frame approach target in a linear fashion, depending on missile's speed. This could go wrong if you had a missile that has a speed lower than the enemy's speed.

A lot of games have done this in the past, including warcraft 3, and if I'm not wrong, dota2 still does this. It's the safest way to guarantee that once you fire a missile, you will eventually damage the enemy.

\$\endgroup\$
  • \$\begingroup\$ Even if direction changes the turret can read the heading and speed to predict where it's going to be in the next frame. \$\endgroup\$ – Sidar May 19 '18 at 22:19
  • \$\begingroup\$ @Sidar not if the enemies collide with each other, or if there are towers that can "push" enemies (like a bomb tower?) - it depends on the game \$\endgroup\$ – TomTsagk May 20 '18 at 0:21
  • \$\begingroup\$ Even if they collide it's fairly easy to "predict" where the enemy ends up next frame, or the next couple of frames. As you said it depends on the game, but more importantly the design choice you are going for. If the projectiles are fast enough the approach probably doesn't matter here. If the distance is big enough the homing projectile might actually make weird turns or shift ever so slightly if the enemy makes an unpredictable move. Making towers predict the next move ( rather than homing) allows for a design choice that can extend to things like less accurate over larger distances. \$\endgroup\$ – Sidar May 20 '18 at 0:49
  • \$\begingroup\$ Of course it's the desired result that you're looking for and the kind of interaction you want in your game. I was just pointing it out because I feel like making it just a homing missile might limit the scope of what you could do with it mechanic wise. A tower missing its shot over larger distances could make things more interesting. Or not if you just want a full lock on homing projectile. \$\endgroup\$ – Sidar May 20 '18 at 0:51

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.