Jump to content

Does different terrain add any protection from small arms at all?


skelley

Recommended Posts

  • Replies 99
  • Created
  • Last Reply

Top Posters In This Topic

In CMx1 engine there was no "blast shielding" advantage gained by having troops on the opposite side of a hill of an explosion occurred (HE, bombs, etc...). Only the slant distance between the explosion and the squad was considered in the modeling, not the interposing terrain.

Question: Outside of the current difficulties with firing passing directly through terrain, does the CMx2 engine now consider the intervening terrain in the calculations?

Cheers

MRD

Link to comment
Share on other sites

JasonC,

That's basically how things work already. An "LOS Map" is created at the beginning of each game and terrain types are a part of that. This is, in fact, what the Action Spot thing is all about. Without it the game wouldn't be able to function because the weight of LOS/LOF checks would crush the CPU :D

To recap the way things work... if Action Spot 123 can see Action Spot 789, in theory everything within each Action Spot can see everything in the other Action Spot. This theoretical ability is diminished depending on various game circumstances too numerable to list here (think real world terms like lack of optics, smoke, fog, suppression, etc.). If the unit in one Action Spot is allowed to Spot something in the other, it is not necessarily true in reverse since each unit has its own capabilities of spotting.

Presuming that units in two Action Spots do see each other, in theory they can both shoot at each other (provided their weapons are capable of doing so, of course). Theory is put to the test before allowing this, however, by determining of there is LOF between any two entities (individual soldier, vehicle, gun mounted on a tripod, etc.). Available cover, special types of terrain, the exact position of an individual entity, etc. all factor in here. If LOF is blocked then the entity can't shoot even though it may be able to see the other unit. This is fairly realistic since you can think of dozens of circumstances where soldiers can see things but can't actually bring their weapons to bear from their current position.

All of this works very well in general and there are no inherent problems with the system. But there are some problems with it, for sure. Besides outright bugs the TacAI needs to do a better job repositioning entities within an Action Spot so that they can either establish LOF (offensive) or break LOF (defensive). We've made some major improvements with v1.05, but this is definitely something we're going to have to work on over time. Like all TacAI work it's pretty easy to get "blunt" behavior out of it, time consuming to get "subtle" behavior.

To answer Claymore's question...

Terrain is in fact "solid". There are some issues in v1.04 where shots are being allowed through solid terrain "illegally", either thorough bugs or because special casing code hasn't been made. Version 1.05 does a lot to fix both of these, but I'm sure some situations will crop up that will need further refinement.

Another thing is that the code can't be too strict because it makes gameplay unreasonably difficult. In other words, there is a certain amount of "close enough" built into the system so as to lessen the number of times positioning a unit 1m too far to one side or the other nerfs the unit's chance of shooting. As TacAI and other improvements are made the "close enough" situations can be reduced so that the visuals match expectations better (i.e. not seeing shots chopping through very small amounts of terrain, but instead shooting over it).

Again, CMx1 was far more sloppy about things like this because the underlying system and graphics were so abstract that you didn't notice them.

Steve

Link to comment
Share on other sites

Steve - I know you precalculate the LOS "allowed or not" lines. But that is not all I am suggesting. I am suggesting that you then add up the number of tiles that can see each tile, and store it as a site-value for that tile, and "think of it" as the exposure of that tile for cover-seeking AI behaviors.

Imagine a flat open field. All the tiles will have the same values, equal to the sum of the number of tiles - all are equally exposed.

Now put a depression one tile in size somewhere, so deep that it can only see the tiles right around it, and LOS to all farther locations fails. Then its total will be only 9 - it can only see itself and 8 other tiles.

So, when a unit is fired on and needs to "look around" for cover, it doesn't check LOS to location X or Y (not even by looking up a visible or not question in precomputed LOS). But instead it would ask "where are the low value locations near me, in the overall visibility sweepstakes?" And so when that unit decides it is time to crawl out of fire, it will crawl toward that depression --- and not, say, toward the shooters.

Link to comment
Share on other sites

Originally posted by JasonC:

Steve - I know you precalculate the LOS "allowed or not" lines. But that is not all I am suggesting. I am suggesting that you then add up the number of tiles that can see each tile, and store it as a site-value for that tile, and "think of it" as the exposure of that tile for cover-seeking AI behaviors.

Imagine a flat open field. All the tiles will have the same values, equal to the sum of the number of tiles - all are equally exposed.

Now put a depression one tile in size somewhere, so deep that it can only see the tiles right around it, and LOS to all farther locations fails. Then its total will be only 9 - it can only see itself and 8 other tiles.

So, when a unit is fired on and needs to "look around" for cover, it doesn't check LOS to location X or Y (not even by looking up a visible or not question in precomputed LOS). But instead it would ask "where are the low value locations near me, in the overall visibility sweepstakes?" And so when that unit decides it is time to crawl out of fire, it will crawl toward that depression --- and not, say, toward the shooters.

You're talking about a pre-calculated cover map, which I think is a non started because there's so many variables between shooter and shootee that would over-ride the cover map that it's probably just as quick to calculate various cover seeking routines based on those factors.

e.g. if you're being hit by a mortar the cover map is opposite to that of an MG (kinda) so do you have a cover map for each type of fire, shooter type, elevation etc? Or do you just have various routines for seeking the closest cover for shooter type.

Link to comment
Share on other sites

This is a quote from a thread which was locked and merged into this one:

There is a VERY fine line, unfortunately, between making the LOS/LOF too strict or too liberal. For the vast majority of situations things are fine, but for certain specific situations the calcs may be too tough or lax...Sometimes Charles can put in a "hack" to massage the calcs for a particular situation. The problem is that if the situation isn't readily identifiable (like a wall end, building corner, etc) it might not be possible to put in a fix specifically for that situation...Not to worry, though. As hardware improves Charles can increase the fidelity of certain calcs so that the extremes become fewer and less relevant when they do happen. The beauty of the new game engine is that these improvements are "relatively" easy to add compared to CMx1...
So does this mean that at least for now, we should expect to be able to fire through berms as described in the other thread, or is this being fixed in 1.5 as well?
Link to comment
Share on other sites

JasonC,

Well, I'm confident that Charles has the most efficient system for checking for cover already coded. The problem is coding the TacAI to use the information that is already there. Remember, EVERYTHING that the AI does has to be coded, which includes rather rudimentary logic like "do I actually need cover?" and "I need cover, fine, but what type of cover?" etc. That's the sort of stuff Charles has been refining, but AI is always an evolutionary process (unfortunately). There are no quick fixes to make the AI smarter, in other words.

76mm,

What you can expect is occasional situations where the visuals and the modeling don't quite line up. The specific thing that C3K wrote about has, actually, been tweaked so I'm sure that one won't happen now smile.gif The problem is there are THOUSANDS and THOUSANDS of possibilities out there and until we can refine the calcs more you will see some situations that don't look right.

Oh, and I meant to add that "as hardware improves" does not imply years before major changes can be made. It could be weeks for all I know. What I do know is that Charles is constantly pushing the envelope and that he's keen to see if the present hardware can handle a little bit more than the last time he checked. LOS/LOF refinement is a top priority. The current system is very good, far better than CMx1, but hey... we've never been one to call things "good enough" and call it a day. We're kinda stupid like that :D

Steve

Link to comment
Share on other sites

Other Means - no, there is nothing different about it for a mortar vs. an MG, and no, it isn't faster to calculate everything in real time. Current cover seeking is pretty hopeless, so it would be an improvement even on low sophistication versions.

Here is the way it would be implemented perfectly, but it may be too computationally intensive within the turn. Hence the simpler suggestions.

Perfect way - you store the LOS connections as an array of 1s for point-to-point visible or 0 for not, with one such array per location.

To get the neutral cover field you literally add those arrays - all of them.

To get a really simple side-weighted cover field, you multiply each array before adding by an array with 0s in the friendly set up zone and 2s in the enemy set up zone, then add them. Thus you care more about exposure to a location where enemy crew served weapons are more likely to be, or where enemy reinforcements might arrive - while carrying less about exposure to locations likely to be free of enemy etc. This alone would be enough to induce some asymmetry in the cover value calculations, and e.g. favor putting buildings between yourself and the enemy side of the map, compared to running around in the front side of the streets etc.

To get a situation-weighted cover field, you multiple each array by a sparse array that has 1s at known enemy locations and 0s everywhere else. Or you can get more threat-specific and change those 1s to threat assessments (MBT 5, IFV 3, crew served weapon 2, infantry 1, whatever).

In a perfection case, you average the first and last (this weights some for unseen enemies, but heavily for known ones).

The cover field can be recalculated once a minute or so, if you use the situational-weight version.

Any unit in good morale can ignore the cover field and just follow its plotted waypoints.

A unit under fire, sufficient to depress morale, seeks the nearest low point in the cover field. You can weight "lower" vs. "nearer" according to a speed-sensitive assessment - a faster unit will be willing to move farther to get to a significantly better cover score location, while a slow one will want the nearest any better than where it is now.

As for the wall question, assuming you can see things on your own side of the wall more easily than things on the other side of it, obviously locations on your own side of it contribute more to the visibility number.

Any location in shadow to anything, is better than a location that can't shelter from anything. But with the adaptive version, a position that specifically shelters from known enemy locations will be automatically favored.

If keeping arrays for each location in too memory intensive for the updating part, just divide the map into a smaller number of grid squares - e.g. 10 by 10 - and weight enemy presence only by those. It will suffice, because the cover field that results will get the general direction in which shadowing is wanted, right, for most units and most of the time etc.

Cover seeking will be somewhat less efficient for surrounded troops, or men approached from an unexpected direction etc. Which is as it should be, and not something that would need to be fixed.

"Distance field" or "influence field" calculations like this are used all the time in other applications (including other parts of AIs).

Link to comment
Share on other sites

I guess it is sufficient to check the vicinity of the squad under fire for LOS-breaking action spots. After all, what sense does it make to evade 100s of meters under fire. The better solution would be to drop and return fire as well as possible.

By the way, has the bug where troops try to seek cover in buildings behind long tall walls been fixed (compare: "Return to Ba Bado")?

Best regards,

Thomm

Link to comment
Share on other sites

Originally posted by JasonC:

Other Means - no, there is nothing different about it for a mortar vs. an MG, and no, it isn't faster to calculate everything in real time. Current cover seeking is pretty hopeless, so it would be an improvement even on low sophistication versions.

Here is the way it would be implemented perfectly, but it may be too computationally intensive within the turn. Hence the simpler suggestions.

Perfect way - you store the LOS connections as an array of 1s for point-to-point visible or 0 for not, with one such array per location.

To get the neutral cover field you literally add those arrays - all of them.

To get a really simple side-weighted cover field, you multiply each array before adding by an array with 0s in the friendly set up zone and 2s in the enemy set up zone, then add them. Thus you care more about exposure to a location where enemy crew served weapons are more likely to be, or where enemy reinforcements might arrive - while carrying less about exposure to locations likely to be free of enemy etc. This alone would be enough to induce some asymmetry in the cover value calculations, and e.g. favor putting buildings between yourself and the enemy side of the map, compared to running around in the front side of the streets etc.

To get a situation-weighted cover field, you multiple each array by a sparse array that has 1s at known enemy locations and 0s everywhere else. Or you can get more threat-specific and change those 1s to threat assessments (MBT 5, IFV 3, crew served weapon 2, infantry 1, whatever).

In a perfection case, you average the first and last (this weights some for unseen enemies, but heavily for known ones).

The cover field can be recalculated once a minute or so, if you use the situational-weight version.

Any unit in good morale can ignore the cover field and just follow its plotted waypoints.

A unit under fire, sufficient to depress morale, seeks the nearest low point in the cover field. You can weight "lower" vs. "nearer" according to a speed-sensitive assessment - a faster unit will be willing to move farther to get to a significantly better cover score location, while a slow one will want the nearest any better than where it is now.

As for the wall question, assuming you can see things on your own side of the wall more easily than things on the other side of it, obviously locations on your own side of it contribute more to the visibility number.

Any location in shadow to anything, is better than a location that can't shelter from anything. But with the adaptive version, a position that specifically shelters from known enemy locations will be automatically favored.

If keeping arrays for each location in too memory intensive for the updating part, just divide the map into a smaller number of grid squares - e.g. 10 by 10 - and weight enemy presence only by those. It will suffice, because the cover field that results will get the general direction in which shadowing is wanted, right, for most units and most of the time etc.

Cover seeking will be somewhat less efficient for surrounded troops, or men approached from an unexpected direction etc. Which is as it should be, and not something that would need to be fixed.

"Distance field" or "influence field" calculations like this are used all the time in other applications (including other parts of AIs).

I think the approach you're positing has some advantages in that it brings some sort of SA to the units, in that they know to avoid exposure to possible enemy positions. No bad thing, but I think there's some issues with it.

You can't have a generic "cover" value. If you're getting shot at by and MG, go for the trees, if you're getting shot at by a mortar then go anywhere there's overhead. Therefore it's a different cover map for each type of incoming fire, with an array for each action spot and code to link them all together into what seems reasonable behaviour. This is an awful lot of data, being {cover vs weapon type * action spots in LOS to action spot * number of action spots} = {cover map} – an array of arrays of LOS maps with cover values against each weapon type for each action spot.

You have to differentially re-calculate the cover map triggered by events rather than scheduled due to building collapse, AFV cover etc. bringing a large overhead.

I think it would be easier to just have an array of {action spot * cover vs weapon type} so it's a single array of cover values (which can be recalculated as needed as this is a much smaller array).

The seek-cover routines would then need to be more complex to create a path to good cover. Figuring out the best route against certain weapon types and the position they’re taking fire from. This might be towards possible enemy positions but if they’re not currently taking fire from them what does this matter?

So as the use of the cover map:

* Has a large data size overhead

* Has a large computational overhead – cover map needs to be recalculated even if there’s no unit currently in it

* Provides SA – but this SA may be irrelevant as the unit is not currently taking fire from that direction.

Not using a cover map but having cover values:

* Demands larger cover-seeking behaviour

* Would only be done as needed

* Does not have a large data size overhead

IMHO, the more complex cover seeking behaviour coupled to cover values is the clear winner.

Link to comment
Share on other sites

Originally posted by Battlefront.com:

Hoolaman,

</font><blockquote>quote:</font><hr />Not inherently, but if a map-maker wants to make it so basically flat open terrain has a degree of lumpy cover, I understand there is no way to do it?

Sure there is :D Rocky gives a bit more protection than Dirt, but (as I've said before) only when the unit is prone. If you really want to spice things up, use the Direct elevation tool and change the heights of individual tiles all over the place. This will make the 8x8 space depress or rise relative to the surrounding tiles.

But all of this is rather academic. In real life it is rare to have "basically flat" terrain. Even in Arid environments there are at least subtle undulations in elevation over a significant area. This means that LOS/LOF isn't possible from one spot to all spots on a map at all times. Well, unless you get high enough. And when you do that the small pockmarks and what not in terrain don't amount to much cover anyway. </font>

Link to comment
Share on other sites

Other Means - I understand what you are after in trees vs. overhead, weapon-specific protection. But I just don't think it matters a hill of beans in CMSF. The only protect that really works is totally breaking LOS. And that is the same for all enemy weapon types, really. If the enemy can still see you, you can and will still be torched. You can't expect being physically in better terrain to help much at all. (Buildings vs. light infantry fire some, sure, but enemy fire won't be limited to that).

This is quite different from the way it worked in CMx1, where you expected to live for long periods in full LOS of multiple enemies, in order to be able to engage them yourself. If the cover you were physically on was good enough - or your unit type stealthy enough - that would work. The enemy would run out of ammo before he'd mess you up too seriously, unless he brought a specific weapon type to bear against you (direct fire HE vs trenches and buildings, mortars or FOs vs trees, MGs or infantry vs open, etc).

In CMSF, all of that is completely academic. If the enemy sees you with functioning units, you will be shot to rags within 2 minutes flat, unless your own fire (own or from friends) breaks them first. In those circumstances, the only relevant cover is "few enemy units can see me - and those are under my side's fire". The only part of that a unit can create for itself with a movement order, it complete LOS breaking movements. Which is what my proposal is meant to steer for.

It is just a suggestion, and they can use it if it is helpful or leave it if it is not. I feel I have explained it enough for it to be understood, and debating it strikes me as pointless.

Link to comment
Share on other sites

Debating your description of the idea is, of course, pointless. Debating whether it has any merit - well yes, that is also probably pointless, just for different reasons. But then actually stating it is by those reasons also pointless, yet you did, so I debated it, and found it to be less than ideal - in my opinion.

This is a forum.

Link to comment
Share on other sites

Hoolaman,

I am sure it is rare to have flat terrain IRL, but in a 3d game you often get perfect billiard table flat terrain.
Right... but if the simulation is fairly realistic (as CMx2 is), then you should expect results proportional to what you see. In other words, you can not use the real world as a yardstick for judgement when you're using an unrealistic environment. So if you have a flat, featureless, elevation neutral expanse of ground that is unrealistic to the extreme in real life... expect very different results from the elements using that terrain. The biggest one I can think of is heightened affects of fire (suppression, casualties, morale drops, etc.)

The problem with manually doing it in the editor is that a single tile changed by one elevation creates a dip big enough to park a car in. Even so it is pretty shallow and not exactly a ditch or gutter to take cover in.
You can "lock" the surrounding tiles so that there is only a 1m dip within the center of a single 8x8m tile. 1m, given level terrain all around it, is enough to give significant cover but not enough to ensure complete safety. Specifically, standing infantry and vehicles will still be visible given shooters with clear LOS/LOF on the same or higher elevation.

But that aside, what I was talking about are "undulations". Look at any map's contour lines and you will see that in even relatively flat areas there is some degree of unevenness of the terrain. It is not billiard table flat even though there may be no significant deviation from a particular elevation above sea level. Say, 2m one way or the other. This tends not to make a difference on extremely small sections of turf (say less than 50x50m), but anything over that it can start to come into play. The bigger the expanse simulated, the bigger even a small amount of elevation means in terms of cover. And since this is the way even "flat" terrain looks in real life the overwhelming majority of the time, then that's the minimum you should expect to see from a user made map.

I can not emphasize enough that there is inherent cover for all terrain. The issue here is that unless there is some sort of significant feature within it, that value is not very big. A couple of guys in one unit may fair better, a couple of guys may fair worse. That's realistic.

Elevation changes, which should be expected in real life, also play a big part in offering protection separate from inherent terrain qualities. If the enemy can't see a spot that's the best form of cover and concealment you can get ;) If the enemy has LOS/LOF to the spot you're in, any form of inherent cover or concealment is going to be inherently subject to failure. Obviously there is a wide range of possibilities.

It goes back to things like foxholes that people will expect by the time the WW2 game comes up. When you add craters to the map, it seems to roughen up the terrain in a smaller resolution than the map tiles. Maybe this could be adapted to give natural terrain lumpyness. I realise this makes the terrain and LOS even more complex.
Again, do not confuse the visual smoothness of a particular tile with "no cover". That's just not the case, as I restated above. The reason for this isn't LOS calcs so much as the requirement for a more highly refined terrain mesh. That's beyond the capability of home computers now so that's not a possibility. Therefore, you're just going to have to accept that the visuals can't be as realistic as you wish them to be, even though they are far more closely resembling the real world than CMx1. Inherently there is only so many little polygons we can push and we're really pushing hard as it is.

When we move to Normandy we'll of course be introducing, and removing, all sorts of terrain types. The terrain set currently is for a specific country and therefore it is obviously in need of changing as we alter the setting.

Steve

[ December 14, 2007, 09:17 AM: Message edited by: Battlefront.com ]

Link to comment
Share on other sites

Playing the same scenario as the one that I started this thread about in 1.05. Infantry behavior and use of cover is much better than it was yesterday. I have still taken casualties (mainly due to an rpg round landing in the middle of my squad) but much fewer. I can now target units on the roof that I used to have to target the floor beneath in order to suppress them. Also infantry stick closer to building walls and use as cover when assaulting down a street or dismounting.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Unfortunately, your content contains terms that we do not allow. Please edit your content to remove the highlighted words below.
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


×
×
  • Create New...