Friendly fire--redux

[John Kettler]

Steve,

You said that from a development standpoint, friendly fire is a black hole. Why should it be such a big deal to model it when you already are tracking the particulars of every shot fired? Why is it so hard to pull some weapon/target interaction X out and apply it to victim Y? We had this in CMBO to at least some degree. I know this because I failed to turn off my MG-42 HMG before sending in the Panzergrenadiers in their 251 to storm a stone house, and wound up shooting my own force in consequence.

Personally, I think friendly fire casualty modeling is an important/vital part of the game, in that it is one of the major concerns of real world combat commanders, and we're trying to properly model real world combat, right?

This was even an issue in "primitive" societies. One Polynesian culture's warriors used to wear wicker integral full cuirrasses with special protective panels covering the neck and back of the head. Why? So that the "fire support" (rocks) hurled by the villagers not planning to engage in hand to hand combat with clubs didn't brain or injure the assaulting men! Seems to me that if it was that big a deal to Polynesians, real commanders would be far more concerned about MGs, grenade launchers, autocannon, tank main gun rounds, artillery and tacair which could hit friendlies.

Even if we ridiculously specify to the contrary, there's another important matter: real world constraints on own force dispositions. Things doable in the game simply won't work on the real

battlefield, in turn permitting troop densities, formations and positionings not otherwise possible, therefore yielding artificial, unrealistic results. Nor is this the first time the issue's been raised, for certain CMBO/CMAK/CMBB players like to use AFV densepack

formations which were simply impossible on the WW II battlefield, thanks to "minor" constraints like opaque vehicles made out of drastically velocity attenuating, fuze detonating armor, one's fellows' displeasure in being shot near, much less at and through, in order to engage the foe with direct fire weapons, etc.

Summing up, I think it's a serious to grave mistake to not incorporate this vital matter in the game and modules to come. Friendly fire isn't, and players need to adjust their plans and actions accordingly.

Regards,

John Kettler

[Pandur]

thats a good suggestion, and also i wonder about why this is so "hard"!?

Why should it be such a big deal to model it when you already are tracking the particulars of every shot fired?

as far as i remember even steve himself said that small arms fire is not abstracted, means it creates casualties where it hits. no matter if it was aimed at that spot or not.

also i belive i saw that in the game already by suffering casualties by a unit behind the action. there was just one squad wich did draw fire, but a salvo missed them and killed a guy 150m behind. i looked that up in wego X times, it must have been like that. i couldnt find another reason.

so, why not allow that for friendly infantry too!?

as example i could name moon´s 2nd AAR, overrun. you see that more often but i take that as example as everyone can look it up at youtube. nothing agains the AAR itself, its great, but you can see the problem good.

he played a QB as syrians against the AI, tha AI attacked in a big "blob", actually verry much along the lines of the "fight tight" concept

it was a big bunch of strykers and dismounted infantry. now, no matter how many troop where in front of the rear guys in that blob, they fired right through their man and thier vehicles.

that, as seen in the video, is insanely effective(syrians had not tanks there to take out strykers) as it was more or less a company or more, on one spot combining their fire power onto some squads and BTR´s.

now i guess the biggest problem is exactly here, the AI, that could be the "limitation". you would need much code, i guess, to tell the AI how to not fire its own man.

but on the other hand, if the sripted AI plan could take partly care of that by moving forces meaningfull, i wouldnt care if i see the AI hitting itself from time to time.

it would be a great solution to get rid of that annoying "random" friendly fire.

[Peach Operations]

This is a significant limitation in my view as well.

If you don't want to model small arms friendly fire, one alternative would be to have your squads refuse to fire through friendly dismounted units. In other words, LOS would go through for spotting purposes, but would be considered to be blocked for shooting purposes. LOS would get a little more unpredictable, but that's the price you pay for trying to shoot past friendly units.

You could also implement small arms friendly fire for human players only, if the computer player can't handle it. Even better, have a setting in the options menu. Options would be: [None / Human only / Human & Computer player].

[TheVulture]

Originally posted by John Kettler:

Steve,

You said that from a development standpoint, friendly fire is a black hole. Why should it be such a big deal to model it when you already are tracking the particulars of every shot fired? Why is it so hard to pull some weapon/target interaction X out and apply it to victim Y?

I suspect that the actual calculating the effects of friendly fire is pretty trivial - a slight increase in the amount of CPU time required to do the extra hit calculations and that is all.

But that's not all there is to it. You have to have units' AI responses make allowances for friendly fire, and deciding when to cancel a fire order when a friendly unit moves in to the danger zone (which can vary from weapon to weapon). And there is a very big difference between calculating the trajectory of a single shot and what it hits, versus calculating the danger area of the firing 'cone' (all the possible trajectories a shot might take from a given shooter aiming at a given target - before we even consider moving targets, travel times, area fire orders, spatially dispersed shooters and targets). The danger area of a firing cone projected on to the ground, potentially with different parts of the cone occluded by different objects at different distances, is something I really doubt can be done quickly enough to be useful in CM:SF, which means fudging it, which means errors - possibly glaring ones.

And even if you are prepared to have your own forces shoot each other and chalk it up to your own stupid fault 9which is fair enough), an AI player would have to be aware of this stuff to give sensible fire orders or movement orders. Throw in the very important fact that in practice you often have to anticipate where a unit will want to fire and avoid blocking that LoS with movement of friendly forces, and it really is a black hole. Any AI algorithm that is going to look at an AT gun on a map, decide where it might want to fire in the near future (based on where enemy armour assets have been seen recently, and where they were heading) and plot movement orders for its own infantry and vehicles to try and minimize the interruption to the function of the AT gun 9as opposed to parking a half-track in front of it since it is a good firing position), is an algorithm that a) simply isn't going to work, and has no guarantee (after you've spent a month or so developing it) that it is actually going to improve game play as opposed to simply making some horribly exploitable AI behaviour (worst case scenario).

There is a very useful rule in software development: don't think "how do I do this right", think "in how many ways can this go wrong". You have to start out looking at the complications that might arise, or what you end up with is code that works fine in the 'textbook' case in your head, but falls over in the real world where 98% of situations are uniquely different from your textbook case in some vital way.

So finding a solution to the few examples of how friendly fire should work in your head is trivial. Finding a general solution that is going to be robust in all circumstances, and do so without crippling the AI player, is a whole different story. It really is a black hole, because there are so many potential complications to doing it well. No doubt some of them won't turn out to be problems at all, but you don't solve programming issues by writing something and hoping that the problems aren't too bad - that is a great way to go out of business.

[Raton]

I've noticed another way of friendly (¿?) fire... I had a squad behind a wrecked tank and i ordered them support another squad avancing towards a building. When the supporting squad began to fire they used both missile launcher (don't remember the name...) and they hitted the tank... one meter away from them. They killed themselves and 4 or six squadmates...

I mean... as in CMx1 HE friendly (and stupid in some cases) fire works fine, but I think it don't exist with smal guns and piercing shots.

That resolves some cases they could be in PBEM games but, IMHO the game results limited because permits some situations very unrealistics in real life (as supporting fiercingly a friendly squad involved in close combat).

[ChrisND]

Originally posted by Raton:

I've noticed another way of friendly (¿?) fire... I had a squad behind a wrecked tank and i ordered them support another squad avancing towards a building. When the supporting squad began to fire they used both missile launcher (don't remember the name...) and they hitted the tank... one meter away from them. They killed themselves and 4 or six squadmates...

Part of the issue here is that the AI seemingly does not take a wrecked vehicle in the line of fire into account. I have many times see a crew bail out of a tank, land on the side opposite of enemy infantry, and the infantry will try to shoot them in a futile attempt that burns through ammo like crazy.

[c3k]

I have to admit that I like how small arms friendly fire is being handled right now. I play WeGo. Within that framework it is nearly impossible to time the coordination of assaults and suppressing fire. Meaning, while my support element pours fire on a position, the assault element closes for the kill.

In real life, the support element would, hopefully, know about the assault and not hit the assault element. In game, I have NO way to stop or shift the fire.

The "design for effect" of having small arms not cause friendly casualties simulates, to me, the shifting of fires.

Otherwise, I would have to take a full turn to issue cease fire orders, then order the assault. That lull in fire would allow the enemy to recover.

Regards,

Ken

[c3k]

Raton,

I have noticed the same exact situation; my men fired an AT rocket at a close tank which blew up catastophically, killing the whole squad. That was a lesson learned for me. (Savegames help take the sting out of such lessons. )

Regards,

Ken

[Battlefront.com]

The TheVulture summed it up well. It's not the physics at all... that's a piece of cake, no problemos there. It's the AI and the UI that are the problems.

There is a very useful rule in software development: don't think "how do I do this right", think "in how many ways can this go wrong".

heh... I've never seen that saying before, but it is SO VERY TRUE!

When we look at something in the real world our first thought is "how important is this to CM's scope?" If it fails to pass this test it's out of mind right there. But the next question is, "how viable is this to incorporate into the game?" This is a very complex question which hits on things like hardware limitations, framerate considerations, length of time to program, and most importantly side effects.

We could have a concept that is important to CM's scale, doesn't hit the hardware hardly at all, leaves framerate pretty much alone, is fairly easy to program in and of itself, but fails miserably with the side effects portion. This doesn't happen too often, but friendly fire is one of them. Other infamous one that comes around and around and around here are map edges. Both of them share the same major issue... side effects.

The problem is that once we get into a feature we have to be reasonably sure that we have the capability to make it work well with everything else that is already in there. The degree of doubt that we can do this, practically, influences how we approach the feature itself. Usually we find a simplified method of inclusion, which is not ideal but it is possible to do. But with truly realistic friendly fire there is no way we can simulate it. Period.

Currently friendly fire is in the game a little bit. If you blow up a building, for example, that has friendlies in it, you risk causing casualties to your own soldiers. At night friendly small arms fire is also possible. Both of these situations are the only two that are in CMBO, CMBB, CMAK, and CM:SF. It's all we feel we'll ever be able to do.

Would we like to do more than simple, narrow conditioned friendly fire simulation? Hell yes! But we understand what it takes from an engineering standpoint and we simply don't have 6 months to dedicate to this one particular feature. Would it really take that long? We don't know. Could take much longer. I'm not kidding. Now think of all the things we could put into the game in that period of time (Hell, even 1/2 that time!) and then ask yourself... "is it really that important?" The answer should be "no".

Steve

[Childress]

"is it really that important?" The answer should be "no".

Are you sure? As I posted earlier (ahem), Deliberate Friendly Fire- the game already has inadvertent FF- was a minor issue in the earlier titles. It's become a significant limitation in the modern, urban setting, opening up a can of exploits. Can you say Magic Bullets?

So please fix it.

[Battlefront.com]

I'll give you guys a concrete example based on something TheVulture wrote above:

The danger area of a firing cone projected on to the ground, potentially with different parts of the cone occluded by different objects at different distances, is something I really doubt can be done quickly enough to be useful in CM:SF, which means fudging it, which means errors - possibly glaring ones.

We looked at doing this as one of those "limited exceptions", like HE and night time friendly fire. We quickly determined it wasn't practical. Let's look at it from a real world standpoint first to see why this is so difficult...

In the real world there is a major overpressure event when an Abrams goes to fire its main gun. There is a cone of injury related to this that is quite large, though obviously the further out the less of a problem it will likely be. So distance is one factor. Another is interceding terrain and relative heights. For example, if someone is in a 3rd story building right next to the tank, he's going to be OK while 1st story he's likely going to experience some risk of injury. If he's on the street right next to it injury is pretty much a sure thing. There's also the issue of the SABOT round's danger area related to when it sheds its petals, but let's forget about that other condition for right now (just note that even my simple example has complications!)

OK, so let's say we implement realistic damage to nearby infantry based on the physics of the overpressure and secondary effects (flying gravel for example). It's not easy to do this, but it is within the realm of possibility. Some hit to the CPU, but probably not "fatal". So we implement it and then go to play test.

The testers report that they are losing guys like flies because the TacAI commanding the tanks isn't taking into account friendlies when it goes to fire. "How can I control when the Tank decides to open up on a T-72? I mean, I can't keep my infantry 100m away from my tanks 100% of the time... that's ludicrous!". So here we go with the first big problem.

We then code the TacAI to be aware of friendlies that are around it. This is not trivial and it adds more burden to the CPU. But when we've finished the tanks will no longer blast away when there are friendly infantry around. So it goes back to the testers.

Now the testers are complaining that their tanks are getting slaughtered because they just sit there and don't fire at all when friendly infantry is around. In short, if you have infantry near a tank then your tank is effectively defenseless. Well, that's not good, is it?

So we go back to coding more AI. The tanks now have to take into consideration risk to itself vs. safety of those around it. So after more coding and hits to the hardware, back to the testers it goes.

Now the testers are pissed because of many different things. One, they don't agree with the TacAI's evaluations of when to fire and when to not. So we have that problem. Two, they point to situations where the Tank Commander is unbuttoned and could have easily yelled a warning to nearby infantry before firing. Or he could have advanced the tank a few meters and left the infantry out of the overpressure danger area. But there is no coding for that in the game, so the tank either didn't fire (missing an opportunity or becoming a victim) and preserved the infantry, or it did fire and the infantry suffered. None of this is acceptable to the testers so it gets kicked back to us.

We try for a fairly simple fix and that is to have the tank maneuver in a way that preserves its ability to engage the enemy tank, but yet get away from the infantry. More coding and more hardware involvement, then back to the testers.

The testers aren't pleased. The tanks are now driving around willy nilly completely ignoring other factors, such as threats to flanks or the danger of the unknown in front of it. The testers insist that this is a blind alley and what we should be doing instead is having the infantry move and leave the tank alone. Wasted coding effort it might be, but they're right... we'll never get it right if the tank moves instead of the infantry, so back to the drawing board we go.

Now the AI has to be able to broadcast its intentions to the units in the immediate area. This can be simulated with the C2 links as well as button/unbutton status and proximity to the tank, etc. This takes time to code and hits the hardware some more. But that's the easy part. The hard part is to get the infantry to move logically based on their own specific tactical considerations. This then produces all kinds of negative end results which the testers tell us sucks and we need to fix.

And so on and so on and so on.

As I said, it's a black hole. Even this one specific feature is enough to suck up MONTHS of coding and yet still have a sub-optimal system that people are going to complain about, either from a playability standpoint or realism standpoint or (likely) both.

And I haven't even reminded you that each time something is programmed there are bugs and evaluation problems that need to be identified and fixed. This part can easily be as involved as the features themselves.

The other thing I haven't even touched on is how to convey this sort of information to the player so he knows basic things like where the overpressure danger area is relative to the specific situation.

So again... simple on paper, not simple to make happen. Which is why I have no second thoughts about our ability to simulate this sort of thing. It's not possible in any practical way, therefore we're not going to waste our time on something we know with 99% certainty won't turn out well. We've got far more certain good things we can do.

Steve

[Battlefront.com]

Childress,

Are you sure?

Extremely sure See previous post. If someone put a gun to our heads and we were given a choice between trying to realistically simulate friendly fire or abandoning realistic tactical wargaming forever... we'd choose the latter. I'm not kidding. It's that bad.

Steve

[Battlefront.com]

Oh, I forgot to mention this point that John raised:

I know this because I failed to turn off my MG-42 HMG before sending in the Panzergrenadiers in their 251 to storm a stone house, and wound up shooting my own force in consequence.

This should happen in CM:SF already, at least in similar conditions. Try Area Fire on a building and rush some infantry in and I think you'll see that this presents a bit of a problem for the infantry

Steve

[Jon L]

Originally posted by Battlefront.com:

This should happen in CM:SF already, at least in similar conditions. Try Area Fire on a building and rush some infantry in and I think you'll see that this presents a bit of a problem for the infantry

I'm not sure that's the case. I just tried a quick test with a Stryker engineer platoon (because they don't have HE weapons). One squad was placed in a small building and the rest of the platoon + vehicles were given area fire orders from a hundred meters away. After a couple minutes the lone squad had suffered no ill effects and their suppression meter hadn't budged.

[Battlefront.com]

Hmm... well, maybe that got changed at some point due to tester feedback. I know for sure we had to "dumb down" friendly grenades because guys were fragging each other left and right. The real fix would be AI work similar to what I described above, but not the same. Which is why this is such a black hole... there are many specific circumstances which each require a ton of programming, testing, and tweaking that generally doesn't help out any of the other related issues. Individually they are problematic, so when combined it's just scary.

Any of you guys who have seen the discussions about limiting the "Player as God" problem should see the similarities. The solution to the player having too much control over units is to remove units from the player's control when C2 is broken, or other things like that. Simple in concept, but in reality it means we have to have AI of such high quality that it's not even worth contemplating. Having inadequate AI is simply not good enough. Plus, players would hate the ramifications of having less control. Friendly fire stuff has almost identical problems for us and players.

Steve

[Lee]

A very good explanation, Steve. It clearly shows why certain features or AI abilities are deliberately not simulated in CM. Namely, they would take forever to program, still not work right even after a ton of programming because of the sheer complexity involved, cause very severe and undesirable side-effects to other aspects of the combat simulation, take a super computer to run, or a combination of the above.

In any case, they are effectively impossible to put in a wargame as complex as CM. Much better to focus on things that can be added to CM, like M113 APC's and M60 tanks.

[Peach Operations]

Not to be too repetitive, Steve, but --

If you don't want to model small arms friendly fire, one alternative would be to have your squads refuse to fire through friendly dismounted units. In other words, LOS would go through for spotting purposes, but would be considered to be blocked for shooting purposes. LOS would get a little more unpredictable, but that's the price you pay for trying to shoot past friendly units.

Would that work? The biggest problems with lack of small arms friendly fire that I've seen are that

a) the game allows you to suppress a building while it's being assaulted, and

there isn't as much of a need to maneuver around an objective's flank in CMSF, because the game allows your support element to fire through the assault element without consequences.

If your squads simply refused to fire through friendlies, both of these would be (mostly) addressed without having to dive into the complications of actually implementing small arms friendly fire. You'd essentially be treating friendlies as a LOS obstacle, similar to a cloud of smoke, and you could have the LOS tool change color to reflect that. Players can deal with the smoke clouds that the TacAI fires off, after all.

The AI player might have a little more trouble, but not by much -- most scenarios have red's squads sitting in static defensive positions that have been designated by the scenario designer (and presumably the scenario designer is smart enough to deal with friendlies blocking LOS). If Red is on the offense, that's harder, but in that case the scenario designer needs to make the AI attack from different angles.

The biggest problem I could see is that the player attacks (or counterattacks) from an angle the AI's setup doesn't account for, and so some of the AI's fires are masked by its own troops. I'd call that more of a feature than a bug, though. A good setup for the AI (and AI triggers, if/when they are implemented) should help with that, in any case.

[bodkin]

WEGO players could be worse off depending how friendly fire was implemented. Unlike in realtime you wouldn't be able to turn off supressive fire while your squad rushed a building or crawled into harms way.

[Battlefront.com]

Peach Operations,

If your squads simply refused to fire through friendlies, both of these would be (mostly) addressed without having to dive into the complications of actually implementing small arms friendly fire. You'd essentially be treating friendlies as a LOS obstacle, similar to a cloud of smoke, and you could have the LOS tool change color to reflect that. Players can deal with the smoke clouds that the TacAI fires off, after all.

It's not that simple First of all, I'll say again that the ballistics, LOS, LOF, and other such things aren't a problem at all. We could easily implement a feature that would have a unit not fire through the path of a friendly unit. We already do that for vehicles to some extent. It's the implications that come as a result of that which present the problem. Specifically, the cascading AI problems.

Picture this situation. You have Unit A which has an AT weapon and has clear LOS to a tank which has been menacing you for most of the game. Unit A is about to fire when all of a sudden friendly Unit B unexpectedly plops down in the LOF. Say it was moving using HUNT and stopped at exactly the wrong spot. Unit A is no longer able to fire even though, as it so happens, Unit A is only 3m away from the nearest Unit B member. Without any sort of coordination of movement between these two units each will pursue it's own functions irrespective of the other.

In this case Unit A just sits there and Unit B also just sits there. In real life Unit A would instruct Unit B to get the Hell out of the way or at least hit the dirt. Either that or Unit A would try to get to a quick alternate firing position. None of this is possible without the sort of AI stuff I've described above. So the reality is that Unit A just sits there and does nothing until the player manually intervenes to put things right. Fat load of good that does if the tank sees them first and, having no friendlies in front of it, either blazes away or gets out of LOF.

Again, this is why we never have, and never will, simulate Friendly Fire in a general way. Even with the more heavily abstracted CMx1 system this sort of thing would have been a nightmare to handle so we didn't touch it with a 10' pole. In CMx2, with its more refined underlying system, the physics are much easier to account for than CMx1, but the AI to handle it is effectively just as difficult. So nope... this one will have to be accepted "as is" just like map edges, Player as God, and a small handful of other things that are unrealistic but unavoidable.

Steve

[stikkypixie]

How about making small arms area fire lethal to friendly units?

That would be already a big improvement IMHO.

[c3k]

How would I suppress enemy units I KNOW are in a specific location without area fire? If they're pinned and out of LOS and I want to keep them pinned I need to use area fire. While they're forced down, my assault element moves in for the kill. Playing WEGO there is no way to lift the suppressing fire with any degree of coordination. Gaming it so the area fire does not harm the assaulting troops works. I imagine the fire is being shifted slightly.

Regards,

Ken

[Guest Guest]

deleted per user request

[hoolaman]

Originally posted by stikkypixie:

How about making small arms area fire lethal to friendly units?

That would be already a big improvement IMHO.

I'd be fully in support of adding that as a difficulty option.

In the situation Steve describes above, it will be the PLAYER's responsibility to ensure team A doesn't get between team B and the tank. If they do they might get clobbered.

It will create a very different, but much more realistic playing style.

[Peach Operations]

I'd be fully in support of adding that as a difficulty option.

In the situation Steve describes above, it will be the PLAYER's responsibility to ensure team A doesn't get between team B and the tank. If they do they might get clobbered.

It will create a very different, but much more realistic playing style.

That sounds acceptable to me. If a squad is close enough that the TacAI could move it into the line of fire, then I need to put more space in between the squads.

[TheVulture]

Originally posted by Hoolaman:

</font><blockquote>quote:</font><hr />Originally posted by stikkypixie:

How about making small arms area fire lethal to friendly units?

That would be already a big improvement IMHO.

I'd be fully in support of adding that as a difficulty option.

In the situation Steve describes above, it will be the PLAYER's responsibility to ensure team A doesn't get between team B and the tank. If they do they might get clobbered.

It will create a very different, but much more realistic playing style. </font>