Trenches, foxholes, and slit trenches

[akd]

I think that is marvelous idea. Pretty hardcore, and probably only usable in wego mode, but still would make it unique experience. And maybe not so hard to implement, i guess.

When i try to picture it, i think it would be a little pain to play, but would shift the game towards realism.

The big problem I see is that the commander still needs an overhead map from which to issue orders, and if the 3D map is used, no problems above are avoided. You would need to be able to bring up an abstracted 2D tactical map that provides basic topography and known features from which to issue orders (ala Operation Flashpoint), otherwise, how do you order a unit to cross over a hill or to the far side of a forest?

[Lurker765]

I could live with trenches having no FOW. But many of my defensive plans and fun in the game comes from placing good ambushes, which involves hidden foxholes.

I would really like foxholes to be true defensive positions rather than a shell scrape. The defender is usually outnumbered and without some true cover from return fire the ambush will be broken by sheer volume of fire from the ambushees.

[Battlefront.com]

Stikkypixie,

I guess this "modifier" is applied generally no matter where the guy being hit is in. That is to say I think the game engine can't make the distinction between a hole in the ground and a foxhole. All it sees is a deformation of the terrain mesh.

Correct. The mesh doesn't really care what the shape is, so a shell crater caused by artillery while in the game or a foxhole created between Setup and the game starting... no difference from the basic game mechanics. Nor should it be. Trenches aren't trenches either, from a terrain standpoint. It's just a more directed and difficult modification of the mesh.

What happens on top of that is other portions of the game assign "meaning" to the objects. The game understands that a big boxy thing is a building and has all kinds of special attributes, while the terrain system just thinks of it as one of the easiest things to draw A trench is identified by the scenario designer, so it's easy for the game to understand that a particular Action Spot has a trench in it going in a specific direction. That's what gives the pathing, TacAI behavior, animation placement, etc. the sense of what it's importance is to movement, combat, etc.

Back to my previous point about the guy's butt visually hanging out... what MIGHT happen is the bullet intersects the polygons, which technically is a "hit". But then the system says "hmmm... boy, it really was just barely a hit. So, what kind of cover did the guy have? Wow... he's behind a vehicle. Hmmm... well, that's pretty good cover so let's reduce the amount that the guy was hit by some semi-random number. Oh look... he wasn't hit after all, that's cool."

In other words, the system is sometimes "generous" with infantry hits because the fidelity of cover, placement, position of the bodies, etc. is just not good enough to be literal. It's far, far, FAR more precise than CMx1, but it is technically impractical (I'm going to guess with today's home computers IMPOSSIBLE) to simulate things down to the point where a true 1:1 can be achieved. Until then we can only do what we've been doing since CMBO... making the simulation of the real world less and less abstract as is technically feasible.

Steve

[Battlefront.com]

Because of the interest shown during CMx1 play, Iron Man camera rules were considered for CM:SF. Unfortunately, to do it right involves a lot of other features to make it viable. Therefore, the design was shelved until the sub component pieces could be added. We intend on adding some of them over time anyway, so like many specialized requests this one will become naturally more viable over time. But I don't expect it will exist for quite a while.

Getting back to what specific defensive stuff we'll include in CM: Normandy... too soon to say. Definitely a lot more variety of bunkers than we have now, for example wood. Bunkers big enough for AT Guns is also going to happen. Barbed wire is a sure bet. But beyond that, I can't say.

Steve

[Michael Emrys]

Lids are a completely different concept which has no parallel in the game at all. To do it right the lid would have to connect with all of the points of the trench/foxhole, which would mean the original map information (i.e. before deformation) would have to be retained. I forget how f'n big the terrain mesh is in RAM, but IIRC it's the single biggest thing stored. The game would also have to generate two pathing maps, two TacAI maps, two LOS maps, and I have no idea what else. Then the game would have to be able to selectively use information from one and dynamically integrate it in with yet a third representation, which is the way the game is at that present moment.

Oh, and that's not even including if Realtive Spotting were paid attention to. In that case you'd have to allow each unit in the game to specify to the system, when you click on the unit, which foxholes and trenches it can see then wait for the mesh to update (which may, or may not, cause the framerate to stutter).

Aaaaarrrrgggghhhhhh! This is a perfect example of the kinds of problems that can be encountered when we try to duplicate Reality inside a computer. Even very simple things that we take for granted, like objects that appear as we near them, are actually extremely complex beneath the surface. And that "beneath the surface" part is what's so hard to reproduce sometimes in a computer. They ain't the same, so to speak. Computers, wondrous machines that they are, are still only able to address a narrow range of problems compared to the vast and vastly complex universe that we inhabit. And they can only address those problems that can be translated into a form that they can operate within. And that translation, to be commercially useful, has to be doable within a human lifetime.

Michael

[SlapHappy]

So if I understand the discussion properly, BFC could implement a "foxhole" object which is transparent and displaces a certain shape into the terrain mesh, but does not solve the FOW problem because it is not necessarily the transparent foxhole object we are seeing but the actual deformation of the terrain mesh. Correct?

And the "lids" idea is that this transparent 3-d foxhole object would have a non-transparent surface-matched texture that would only become transparent (revealing the actual foxhole) if a spotting unit were close enough to the foxhole object to trigger that view? I could see how this might work in theory, but how do you manage to match the foxhole object terrain lid to the surrounding texture so that it wouldn't be obvious? I can't see how this would be easy to do. All you would need to do is look for the slightest irregularity in the mesh texture and you would still know that most likely that is where there are foxholes. It would have to be completely seamless before a savvy player would be incapable of picking out the probable foxhole locations.

[kulik]

The big problem I see is that the commander still needs an overhead map from which to issue orders, and if the 3D map is used, no problems above are avoided. You would need to be able to bring up an abstracted 2D tactical map that provides basic topography and known features from which to issue orders (ala Operation Flashpoint), otherwise, how do you order a unit to cross over a hill or to the far side of a forest?

I dont find it too hard give orders in 3D even if camera is positioned too low. (Except when two units are standing in line and you need to target the one which is more far away.) Your concerns are that you can issue orders only in your FOW, right? It sounds great when it comes to realism, but your right that will probably render this system useless. Maybe wego in 30 sec intervals, would make it playable (forest combat would be still a problem) or harder to implement the 2D tactical map as you said)

[Battlefront.com]

Well, Emrys has another "he's absolutely right" to add to his sigline Visualizing how something should work may be very simple, but getting it to work that way can be technically impossible. Kinda like in the other thread where US engineers found that x amount of hastily employed explosives could knock a hole in a hedgerow. But when the logisticians added up how many tons of TNT would be needed for a single Company the amount was enough to cripple the supply system. Or like how in theory a Stryker Brigade can be deployed anywhere in the world within a couple of days, but the heavy lift capacity necessary is in excess of what the US Air Force has and/or what the airports can possibly handle in terms of air traffic. Creativity is often squashed by hard reality, and not just by computers

SlapHappy,

Correct about the lids having to be "perfect" in order to work. If the terrain mesh were completely flat and uniformly textured that would be pretty easy to do. But that's not the case at all in CMx2, obviously. So it becomes "expensive" to do right, and since anything less than that won't work it's something that just won't work.

Steve

[TheVulture]

Correct about the lids having to be "perfect" in order to work. If the terrain mesh were completely flat and uniformly textured that would be pretty easy to do. But that's not the case at all in CMx2, obviously. So it becomes "expensive" to do right, and since anything less than that won't work it's something that just won't work.

Steve

Dragging this discussion back up again (and I'm not entirely sure why - just musing in public I guess).

I'm not sure why you'd need multiple copies of the entire terrain mesh in order for spottable trenches to work. Well, if you just had the mesh and nothing else, you would. But you have the basic map info, you know which tiles contain trenches, so you know which tiles you need to have multiple copies of. Namely just those with trenches (and probably some adjoining ones for e.g. trenches that cross diagonally between two tiles - presumably some parts of the other two tiles meeting at that corner need some adjustment too.

It all then hinges on how easy it is to insert copy A or copy B of a given tile into the buffer stream. (Which, I admit, nay not be trivial, depending on how you are optimising the polygon draw order: may well not be tile by tile, and the fact that the trenchful and trenchless copies of the tiles will have greatly different numbers of polygons in them).

Assuming it is possible to do that without a big performance hit, then the matter of determining which copy to draw is fairly trivial and low processor impact. For each tile affected by trench ambiguity, loop over enemy units and determine which have LoS to that tile (done from the pre-computed LoS maps). An even lower impact version (if a little more convoluted algorithmically) is to generate a list of which tiles can be seen by which units at the start, and just update it when a unit moves from one action spot to another.

The main complication obviously comes from applying terrain deformations to both tiles, which depends on how the code for deforming stuff is handled. Ideally, it is possible to apply the deformation to both tiles when a shell explodes to make a crater. But (and that might be another big 'but') that's assuming that it is possible to add a crater to the trenchless tile depending on where the shell detonates in the trenchful tile (which may be e.g. at the bottom of the trench). And that other aspects of the crater won't cause discontinuities and glitches between the two versions of the tile (and the way the merge with the surrounding single-copy tiles which may also contain part of the crater).

Obviously only the real (trenchful) copy is used in all game calculations - the copy is just inserted into the draw buffer depending on the spotting determination. It is the updating of both copies in response to explosions / terrain deforming that might throw up trouble.

Thought?

[Battlefront.com]

TheVulture,

It is the updating of both copies in response to explosions / terrain deforming that might throw up trouble.

As Charles has explained it to me, this appears to be the biggest of the problems.

Another of the problems, as I understand it, is the mesh has no understanding of "tiles". It's just one big flowing mesh, so there are no distinct edge to what is an Action Spot in terms of points. This means if he is going to slice out one Action Spot, and put it back in, the connections must be recomputed. I don't think this could possibly be precomputed since we have dynamic deformation. Meaning, one can not assume that because A1 and A2 fit together with B before the game started that when you go to swap out A1 for A2 that it will still fit with B. If there were no dynamic terrain modification I would presume a swap out would be no problem because assumptions can be made.

This is one of those things which I've asked about for several years and the answer back from Charles is always the same... it would be a mess to try and do this. Point of diminishing returns means that such a large development effort, if even possible, isn't worth the sacrifice to other things.

I think it's telling that other games don't have FoW terrain meshes, as far as we know.

[Guest Guest]

deleted per user request

[Redwolf]

Would giving up deformable terrain in favour of adding FOW not be a pretty damned good trade?

Don't you need deformations to actually make the foxholes and/or small trenches?

[Lanzfeld]

Would giving up deformable terrain in favour of adding FOW not be a pretty damned good trade?

I vote no. I want FOW on trenches as much as you do but it simply isnt possible yet and I want deformable terrain. At this point it would probably be too much work to undue the terrain and go back to full FOW.

[Guest Guest]

deleted per user request

[Battlefront.com]

Redwolf,

Don't you need deformations to actually make the foxholes and/or small trenches?

Actually, terrain mesh deformation has nothing to foxholes or anything else. The problem is that the terrain mesh is complex and not easily modified on the fly. So yes, we could have no deformable terrain while in the game (no shell craters), but it wouldn't change a thing regarding trenches and foxholes.

Now, we can theoretically have 2D foxholes and trenches and not run into the terrain mesh problem. It wouldn't mean we would have to get rid of deformable terrain, it would mean we'd have to fudge a 2D environment into an inherently 3D environment. You're a programmer, so I'm sure you can imagine that this could get really ugly fast

Charles is pretty sure he could fudge 2D foxholes and I'm definitely in favor of that. They are fairly shallow and don't have issues with direction like trenches do. In other words, they rely less on the 3D world compared to trenches, therefore they are easier to fudge compared to trenches. Charles doesn't think fudging trenches would work out very well, not even considering the damage to the 3D visuals that would come from that.

Steve

[dan/california]

Am I crazy, or has or has Steve's position on foxholes evolved a little bit. I admit that one does not exclude the other.

[Battlefront.com]

dan/california,

Am I crazy, or has or has Steve's position on foxholes evolved a little bit. I admit that one does not exclude the other.

Foxholes? Not really. Out of the two I've always considered the foxholes to be the problematic one worth trying to solve. Trenches... I'd like to have that one solved too, but technically it's not practical. Fortunately, trenches aren't all that important to either the game (CMBO had no trenches, people complained, people survived ) or to the overall realism of the theater. This is not as true with foxholes.

Put another way, no FoW trenches is probably 20% unrealistic to 80% acceptably realistic, foxholes are probably the inverse of that. The idea of cramming a 2D simulation of foxholes into an inherently 3D game system is probably practical, not practical for trenches. So I'm focused on getting FoW for foxholes and not concerned about trenches.

Steve

[sfhand]

As I said before, sort of, I think it is entirely reasonable to have trenches considered pre-discovered - especially for Normandy. I'm glad to see BF continuing to consider ways to save FOW for foxholes and I am now wondering if curved 3d lids (slightly curved to allow for LOS from within the foxhole) that can be completely destroyed by one bullet might not be easier than fudging 2d foxholes... I understand how lidded trenches could produce pathing problems, but I don't really see that problem extending to foxholes - if their use is limited, which it sounds like it will be.

[Redwolf]

Actually, terrain mesh deformation has nothing to foxholes or anything else. The problem is that the terrain mesh is complex and not easily modified on the fly. So yes, we could have no deformable terrain while in the game (no shell craters), but it wouldn't change a thing regarding trenches and foxholes.

That was my understanding, I didn't get how Adam would "trade" deformable terrain for FoW fortifications.

Now, we can theoretically have 2D foxholes and trenches and not run into the terrain mesh problem. It wouldn't mean we would have to get rid of deformable terrain, it would mean we'd have to fudge a 2D environment into an inherently 3D environment. You're a programmer, so I'm sure you can imagine that this could get really ugly fast

Charles is pretty sure he could fudge 2D foxholes and I'm definitely in favor of that. They are fairly shallow and don't have issues with direction like trenches do. In other words, they rely less on the 3D world compared to trenches, therefore they are easier to fudge compared to trenches. Charles doesn't think fudging trenches would work out very well, not even considering the damage to the 3D visuals that would come from that.

Well, you know my opinion on it

I'd accept a pretty horrible look to get them in a Normandy 1944 game.

I think the major problem wouldn't be the "carpet" foxholes per se, the major problem would be to cut the men in half when they are in the foxhole. That can easily look like they are waist-deep in a swamp. But alas it's worth it.

When it comes to ugly foxholes people should also keep in mind that screenshots posted in magazines or on the web and presumably attracting customers based on looks are usually "action" shots of 3D soldiers running around, not some GI having a smoke in his foxhole.

Programming-wise I would expect that the major problem is that the engine so far might lack a mechanism that is a modifier for exposure based on the terrain the soldier is in?

And let's not forget that herding a 12-man 1:1 squad into existing foxholes might be not trivial. We wouldn't want to see half the squad staying out after we ran them to the - foxhole - foxholes? I'd assume there's a fixes set of foxholes belonging together that fit a squad and the move command order recognizes it and maneuvers everybody into a foxhole?

[Battlefront.com]

Redwolf,

That was my understanding, I didn't get how Adam would "trade" deformable terrain for FoW fortifications.

Correct. The complexity of the mesh is the issue. Or more exactly, the limitations of the computer handling dynamic deformations and "undeformations" (I like that new word!). CMx1 wasn't able to deform terrain at all, for any reason, including things like trenches. It was just too much for the computers of the day to swallow. Now we can have a vastly more complex terrain mesh, complete with dynamic deformations... but "undeformations" based on circumstantial reasoning is not within the computer's grasp.

Well, you know my opinion on it

Indeed

I'd accept a pretty horrible look to get them in a Normandy 1944 game.

I think the major problem wouldn't be the "carpet" foxholes per se, the major problem would be to cut the men in half when they are in the foxhole. That can easily look like they are waist-deep in a swamp. But alas it's worth it.

Actually, the fudge would include them being above ground much the way CMx1 was. I think "swimming" would look way, way worse.

When it comes to ugly foxholes people should also keep in mind that screenshots posted in magazines or on the web and presumably attracting customers based on looks are usually "action" shots of 3D soldiers running around, not some GI having a smoke in his foxhole.

This isn't a major concern. The bigger concern is rejection of this by customers after they have seen the game for themselves. I think we can get away with it for foxholes, but I am convinced we'd be slapped around a lot if we applied it to trenches. Fortunately for us, the technical problems are with the trenches more than foxholes, not the other way around.

Programming-wise I would expect that the major problem is that the engine so far might lack a mechanism that is a modifier for exposure based on the terrain the soldier is in?

Exactly. The "fudge" part of this feature mostly revolves around applying conditions to something in one situation which it wouldn't have in any other situation.

And let's not forget that herding a 12-man 1:1 squad into existing foxholes might be not trivial. We wouldn't want to see half the squad staying out after we ran them to the - foxhole - foxholes? I'd assume there's a fixes set of foxholes belonging together that fit a squad and the move command order recognizes it and maneuvers everybody into a foxhole?

From what I remember, what happens is the Team (remember, it is 1x Team per Action Spot) is spread out in good defensive positions and foxholes are put beneath them. They aren't all in one big foxhole, nor are they arranged along some predefined pattern. In real life foxholes are usually populated by 2-3 men in optimal conditions. Density has a lot to do with terrain, but like CMx1 we are somewhat limited as to how far guys can spread out without having the unit split by the user.

Steve

[thewood]

Unless your men are Syrian and not allowed to have teams.

[Battlefront.com]

thewood,

Unless your men are Syrian and not allowed to have teams.

Even the Syrians have one Team per Action Spot. The difference is you can't split them up. That restriction is realistic, overall, for the Syrians, not applicable to any of the forces in CM: Normandy.

Steve

[Londoner]

Thanks for the honest and pragmatic explanation Steve.

[c3k]

Steve,

Right now when a shell hits the ground, you can look under the map and see the particles falling into the nether-regions. If we have foxholes with men sticking up out of the ground, will we be able to see their legs dangling under the bottom of the maps?

Of course, that'd bring a whole new gamey dimension into battlefield recce; just get the "mole camera" into action underneath the map!

Thanks,

Ken

[Redwolf]

Steve,

Actually, the fudge would include them being above ground much the way CMx1 was. I think "swimming" would look way, way worse.

Not sure I can parse that. The fudge would be just a carpet, or a little 3D object buildup representing the front wall of a fighting position?

This isn't a major concern. The bigger concern is rejection of this by customers after they have seen the game for themselves. I think we can get away with it for foxholes, but I am convinced we'd be slapped around a lot if we applied it to trenches. Fortunately for us, the technical problems are with the trenches more than foxholes, not the other way around.

As far as I'm concerned I don't like the word "trenches" in this context anymore. All I ever wanted is, given fighting positions (foxholes), it would be even better if they could be connected by terrain slits or whatever you call them that allows you to move back from the foxholes into cover terrain, or between foxholes.

But CMBB/CMAK trenches didn't really do that either. They were just long foxholes but didn't support movement while a firefight was going on upstairs.

%%

I suspect that I speak for a good portion of those who want the FoW foxholes in this thread by stating this:

the thing that's really pressing is that I can set up my AT guns, my MGs and my squads anywhere in the defensive zone, freely, preparing an ambush.

This wouldn't be possible if either you can't use any kind of terrain protection from setup, or if the foxholes are known to the attacker.

All the other stuff is just icing on the cake.

I don't know what other people did with CMx1, but the most enjoyable game I had involved one of two things:

• With a Calvin like grin on my face place defending units in a gridlock that will make the attacking player crawl up in an embryo position under the computer before the game is over.
  
• Attack somebody who, with a Calvin like grin on his face placed... (see above)...
  

Foxholes with FoW and decent protection and FoW is what's needed for this. Everything else is icing on the cake.

As I mentioned, CMBB/CMAK trenches were semi-useless as trenches anyway, the only reason I used them was that they offered better protection than the foxholes (I think you placed some of the foxhole protection too low, 45% exposure is a little much for a soldier that prepared a fighting position that his life depends on). So they were just used as glorified foxholes anyway.

As a result I feel confident that screwed up trenches won't do even a fraction of the harm that lack of FoW basic static positions would do.

From what I remember, what happens is the Team (remember, it is 1x Team per Action Spot) is spread out in good defensive positions and foxholes are put beneath them. They aren't all in one big foxhole, nor are they arranged along some predefined pattern. In real life foxholes are usually populated by 2-3 men in optimal conditions. Density has a lot to do with terrain, but like CMx1 we are somewhat limited as to how far guys can spread out without having the unit split by the user.

Steve

Yeah, but don't underestimate that there might be an actual mess coming up when you want to direct a squad to move to and occupy foxholes.