Improved missile behaviour / picky=1;

Foxomaniac · Post by **Foxomaniac** » 06 Oct 2006, 14:43

Ok ok, this might be confusing but I'll try my best to explain :

Missile behaviour in spring is made of FAIL.

You can clearly see it in surface-to-air missiles.

Ex .

10 Fighters are in the range of 10 missile towers

10 missile towers fire their missiles at ONE Fighter, 1 or two of them hit the fighter and the fighter dies and the other missiles are wasted.

In small numbers this behaviour isn't terribly ineffiecient but when in some other examples such as this :

Mod ( Nanoblobs ) :

around 100 wolves are in the sky, you're trying to counter them with a close or an equal number of archers.

your archers get picked off one by one while all the damn archers keep firing at a single wolf and waste their missiles, better yet - when their missiles fall on the ground and they hit something in your base you might lose something valuable *cough 75% of your sheep cough*

What I'm proposing is a tag for guided weapons, such as picky=1;.

This would force the unit to pick a target that is not being targeted by other units of it's kind while at the same time complying with badtargetcategory so it would focus on air units rather then ground if it had ground units in it's badtargetcategory.

This would greatly improve missile efficiency in general and help balance mods like nanoblobs a lot more.

Thoughts?

rattle · Post by **rattle** » 06 Oct 2006, 15:23

Wouldn't it be better if missiles could pick up another target if the current one is gone (destroyed, out of LOS, ...)?

LordMatt · Post by **LordMatt** » 06 Oct 2006, 15:30

Tobi · Post by **Tobi** » 06 Oct 2006, 16:11

I don't think a tag is needed, if the default behaviour is somewhat smarter it would be fine.

Or is there a good reason a modder would want missiles to be fired at the first unit in LOS?

RaiFox · Post by **RaiFox** » 06 Oct 2006, 16:18

At the very least the missiles should not fly off in random directions, I've had my metal maker farm destroyed because of those rockets.

10053r · Post by **10053r** » 06 Oct 2006, 16:31

I think it is totally cool that missles fly off randomly after their target disappears. Railfox: Don't build your metal makers right next to each other (or anything else that can chain explode).

However, I also think that missles should target a little more intelligently. They should only be targetted at the same unit if it takes more than one missle to kill a unit. That is:

Long Range Missle Tower vs peeper = 1 missle per peeper
SAM vs Liche = however many missles neccesary to kill the liche

Actually, the OTA engine did this. A bertha would fire exactly however many shots were neccesary to kill something, then retarget before the shells even hit. Of course, it wasn't good it knew how many shots were neccesary to kill something it couldn't see, but you get the idea.

FizWizz · Post by **FizWizz** » 06 Oct 2006, 16:53

10053r wrote:Actually, the OTA engine did this. A bertha would fire exactly however many shots were neccesary to kill something, then retarget before the shells even hit. Of course, it wasn't good it knew how many shots were neccesary to kill something it couldn't see, but you get the idea.

I'm not so sure about that, you might want to check OTA again...

The thing that annoys me about guided missile behavior is the way they act after they lose their target. Rather than pull insane Gs to snap around instantly to some random vector and then go straight until they crash (a royal pain in the behind if these SAMs are in your base), they ought to *just* do the going-straight-until-they-crash thing

Fanger · Post by **Fanger** » 06 Oct 2006, 16:58

Id prefer if burnblow=1; could work on missiles and upon reaching max range, or a distance after max range (flying straight mind you) they simply detonated in midair..

Caydr · Post by **Caydr** » 06 Oct 2006, 18:22

If they could pick a random target unless ordered to attack a specific one, that'd fix the problem.

Could also have it calculate the liklihood of a unit being distroyed, then pick a new one if it's probably going to be, etc, etc, but for 100 units or something I'd bet that would be pretty computationally expensive.

KDR_11k · Post by **KDR_11k** » 06 Oct 2006, 18:33

Perimeter uses damage limit targeting, i.e. units retarget when a lethal dose of projectiles has been fired at their target already. To implement that into Spring you'd have to keep track of which projectile is aimed at what so you know when that dose has been reached. Though I'd say there should still be a tag limiting this behaviour to weapons that are very likely to hit, a spray and pray weapon for example wouldn't hit the target with all shots so it wouldn't know when to stop shooting at the target.

SpikedHelmet · Post by **SpikedHelmet** » 06 Oct 2006, 22:55

Fanger wrote:Id prefer if burnblow=1; could work on missiles and upon reaching max range, or a distance after max range (flying straight mind you) they simply detonated in midair..

:O

Or, the missiles would detonate at the approximate range to the target... which is how real SAMs behave (they explode within proximity).

Pxtl · Post by **Pxtl** » 07 Oct 2006, 02:48

I still think constant reacquisition is the best approach. Obviously the best approach in combat is to fire at the first target that enters your firing range, and if multiple are available to target the best target. A little randomness might help in that "multiple available" scenario, maybe. Anything else would cause confusing behaviour in small groups. The only time I'd want this to change is if a "group attack" command was added (unless there's already an undocumented trick exists), wherein random targetting would be appropriate.

Edit: consider that random targetting behaviour is suddenly a liability in cases where concentrated firepower is desirable. Imagine having an arsenal of small units that can target a handful of big ones, where the big ones will take a dozen volleys to destroy. For example, consider a field of MTs against 3 Krows in AA. In that case, you'd want to concentrate your fire - you'd want them all to shoot at _one_ Krow until it's dead, since 2 healthy Krows and one dead Krow does much less damage than 3 somewhat-damaged Krows. In other RTS games where everything has much more health compared to the highly-lethal TA, this is the more intelligent tactic. Only in TA where many units die in a single shot is concentrating fire a bad thing.

Argh · Post by **Argh** » 07 Oct 2006, 09:02

Firstly, I'd like this proposed variable to be called TargetRandom.

I just want to be able to CHOOSE this behavior- not have it be a default. With some units, it'd be inappropriate. Here are some examples from NanoBlobs:

1. Archers vs. Wolves. Archers need to random-target incoming targets to be as effective as they should be. An incoming pack of Wolves vs. an equal number of Archers should take massive casualties- this is not what actually happens. Instead, the first few Wolves die, then the rest of the swarm passes through, or kill a lot've the Archers

2. SpireRooks vs. Knights. Here, concentrated firepower would be great. I want SpireRooks to kill Knights, so I've balanced for the current fire-behaviors- Two SpireRooks, working together, will kill a single Knight. Multiples of them tend to kill Knights in large bunches, because the Knights are coming in a blob or stream. If a player micros the Knights to use a line abreast and has enough room, though, then the Knights win because too many SpireRooks fire on the nearest target, failing to kill the Knights on either side. Which is perfect.

3. MegaSheep vs. Ground Targets. Definately should use random target selection, instead of all firing at the same thing. MegaSheep would be much less effective in some ways, but more in others- and I would balance them accordingly. But in an ideal world, MegaSheep would tend to saturate areas with fire.

Basically, I want this to be a choice, not a "well this is smarter, so make it default" thing. Sometimes random targetting is desireable... sometimes it's not. Modders should get to choose.

I'm not really in favor of using complicated target-weighting systems, etc., on the unit-AI level, unless it can be demonstrated conclusively that this code could be kept very fast. In most mods, I think it would be perfectly acceptable to merely have the targetting routine make a random choice.

Lastly... I'd like to have one other tag, besides TargetRandom. This would provide support for a target-matrix approach, if modders REALLY NEEDED IT, but wouldn't require it all the time.

This tag would be TargetPreferred. It'd work like this(using the categories from NanoBlobs):

Code: Select all

TargetPreferred=LAND, AIR;

Basically, if given two choices via TargetRandom's code... TargetPreferred would get shot at first. This would pretty much remove the necessity for badTargetCategory, because instead of a weak-kneed randomizer (which modders can't control) we'd just have units do the logical thing, and shoot at the target that was their top priority

Warlord Zsinj · Post by **Warlord Zsinj** » 07 Oct 2006, 15:19

I think this would be a useful addition, but I think it is important that when the player gives a clear target order to his unit, this overrides any random targetting, so that the unit fires all it's available weaponry at the selected target. Nothing more frustrating then a unit thinking it is smarter then you, and going off and doing something stupid when you least need it.

Argh · Post by **Argh** » 07 Oct 2006, 21:00

Agreed.

Spring RTS Engine

Improved missile behaviour / picky=1;

Improved missile behaviour / picky=1;