Jump to content

Why does Combat Mission use grid instead of direct placement?


Recommended Posts

I often find myself fussing about the coarse placement constraints of troops on the map.

So many times I find that I can't get my troops to the spot that would be most helpful because the 8 by 8 tile is either too far behind a ridge or too far over top of it. I wish buildings had other placement options beyond the facing of the troops.

There are many games out there that don't have these limitations.

The soldiers themselves are modeled very well but their environment is very fussy.

I don't want to debate whether this makes things more or less accurate; I'd just like to find out what is behind these limitations and whether there is likely to be game code break throughs that will allow pinpoint placement.

Link to comment
Share on other sites

I often find myself fussing about the coarse placement constraints of troops on the map.

Then you need to exercise some perspective. Your pTruppen will find the best cover they can for the direction they're facing in the bounds of their team separation. This would be equally true if you could set the "aim point" for the team/squaddown to centimetre precision.

So many times I find that I can't get my troops to the spot that would be most helpful because the 8 by 8 tile is either too far behind a ridge or too far over top of it. I wish buildings had other placement options beyond the facing of the troops.

You might find that the Face command helps in the open too.

There are many games out there that don't have these limitations.

Sure. They have all kinds of other limitations.

I don't want to debate whether this makes things more or less accurate; I'd just like to find out what is behind these limitations and whether there is likely to be game code break throughs that will allow pinpoint placement.

How fine do you want to go? First consider that LOS is checked to Action Spots. Going to 1m AS would multiply the CPU cycles needed for LOS checks by 64 on that basis alone, and probably by another 8 because there will be 8 times as many possible blocking intersections to check too. So for every unit, every LOS cycle, the processor would be doing 512 times as many calculations. And it would make no sense to have finer spatial definition without smaller time ticks, too, so going to 1s LOS cycle (from the current, AIUI, 7s) would take that to 3500-odd times as many CPU cycles. Your rig can't handle that, not in RT.

Then there's pathing, which would struggle with the same geometric progressions.

And still people would want more precise control over their pTruppen. And you're still talking about placing a "general point" for 2-6 men, who will find their own cover somewhere within a radius of there.

Link to comment
Share on other sites

I'm not really wanting to debate the placement issue. From what I've experienced I still find one grid box will never draw enemy contact and the next leaves my unit dead, whether I use the face command or not.

You've mentioned specifics as far as computer resources needed to get a more accurate placement. This is what I'm wanting to find out. My question out to game developers is; are these numbers and the way Womble describes the effects accurate?

Link to comment
Share on other sites

Womble - I would have argued along your line but while thinking about it I stumbled about one thing.

Remember when CMBN came out that Steve told a story about a bug where the cause was that the eyes of a TC were rotated by 90° so he couldn't spot properly. So LOS is calculated from every single soldier and not from the AS.

Another argument against that AS are used directly for LOS is that soldiers do cross AS limits and - while moving - some soldiers of a unit may be in one AS while others are already in the next. This does not stop them from spotting.

I guess that LOS from AS to AS is used as a filter to lower the actual necessary spot checks. If there is no chance for a unit in one AS to spot someone in another (e.g. behind a hill) then don't test at all. Saves time.

My guess the reasons for ASes is that it makes the placement of the individual soldier much easier. An AS is a well defined and not too big area that the algorithm has to consider. Without the confinements of an AS it would become exponentially harder to place them right.

What would be nice is if we could exert some more control about what our ptruppen do. The face command helps in most cases. But sometimes in an urban environment or, like Paul said, at ridges or similar it is frustrating.

If we could change the origin of the face command to change the weights (*) for the algorithm that would be nice.

I tried to put that in a picture:

facingm.jpg

I drew the origin for the 'possible' case very close to the front because that's my feeling what CM does. In the game the origin stays in the centre.

UI wise that could be handled like this:

You give a face command like it is now but then 'space' would cycle through 'front', 'back', 'centre'. Indicated by moving the origin of the face arrow. The origin will always stay in the AS. If you don't use it everything will stay as is. No new buttons.

(*)

by weights I mean this: CM places the individual soldier as good as it sees fit. Every spot in the AS has a certain 'usefulness'. This will be determined by factors like closeness to a wall or hedge, direction of the face command, availability of other cover etc... If for instance the weights would be 'back' then spots in the reverse direction of the face arrow would be calculated as to be more suitable for a soldiers position. Result: the soldier would not cling to the wall and stay a few meters back.

Link to comment
Share on other sites

Womble - I would have argued along your line but while thinking about it I stumbled about one thing.

Remember when CMBN came out that Steve told a story about a bug where the cause was that the eyes of a TC were rotated by 90° so he couldn't spot properly. So LOS is calculated from every single soldier and not from the AS.

This is true, and the mode upon which my arguments were based. It is calculated from every observer (whose numbers would remain constant) to every AS (I believe there are some broad-brush trimming algorithms that for example cut out everything the other side of tall walls that infantry are adjacent to). So for a given observer, with a given field of view, if you drop from an 8m to a 1m grid, there are 64 times as many AS to test for LoS to. And 8 times as many potential points of intersection with that LOS.

If it were tested from every AS to every AS, the number of tests ([number of AS]squared) would, on switching from an 8m grid to a 1m grid, multiply by 64 for the origins and 64 for the potential points of observation, multiplying the needed work by 4096...

Link to comment
Share on other sites

I guess that LOS from AS to AS is used as a filter to lower the actual necessary spot checks. If there is no chance for a unit in one AS to spot someone in another (e.g. behind a hill) then don't test at all. Saves time.

IIRC this is how it does work. I also vaguely recall that the AS to AS checks are done at beginning of the game and saved so they don't have to be repeated, although there are presumably circumstances where they are, such as when terrain is deformed by artillery or buildings are destroyed.

Link to comment
Share on other sites

If it were tested from every AS to every AS, the number of tests ([number of AS]squared) would, on switching from an 8m grid to a 1m grid, multiply by 64 for the origins and 64 for the potential points of observation, multiplying the needed work by 4096...

As VAB said - this calculation needs only to be done once at the beginning and when the terrain changes. So even if the calculations go up exponentially with the (smaller) size of ASes it is not 'costing' anything during the game.

I guess there are only two types of LOS checking going on in the game:

1) from unit to anything that is in the FOW (units, vehicles, fortifications)

2) from unit to the spot of a targeting order

(IMHO a lot of confusion and frustration could be amended if 2) would be more self-explanatory, just saying)

So AS are not used for LOS in game - neither as source nor as target.

But all this has nothing to do with the gripe of the OP: that he does not have more control over the positioning of his troops. IME CM does it very well on its own MOST of the time. One could argue that when it does not the cause is the confusion/bad behaviour of the soldiers themselves. So CM is even simulating that (this is were bug and feature get indiscernible :)).

One exception is when you want to peek around something (to shoot a Bazooka around the corner of a house for example). This is currently not possible. I hope this will be fixed when we get to the more urban environments.

Long story short: IMHO it's ok how it works now but there's still room for improvement.

Link to comment
Share on other sites

As VAB said - this calculation needs only to be done once at the beginning and when the terrain changes. So even if the calculations go up exponentially with the (smaller) size of ASes it is not 'costing' anything during the game.

So, if it takes a second to do that calculation, you'd not mind waitng 4000s for the game to set up?

Link to comment
Share on other sites

Steve has been known to laugh derisively at some of their competition whose apparent 'advantages' invariably mask under-the-hood cheats and trade-offs they're simply not willing to make. It doesn't make much difference if you precisely place a soldier then the game engine entirely fudges the ballistics model. Until someone starts selling supercomputers over the counter everything is going to be a trade-off. I happened across a game recently, very nice gameplay, phenominally huge maps. But no infantry, minimal environment besides distant haze, no shadows, low poly count models. It wasn't a bad game but they made big trade-offs to get the game that they wanted.

Link to comment
Share on other sites

Womble - I would have argued along your line but while thinking about it I stumbled about one thing.

Remember when CMBN came out that Steve told a story about a bug where the cause was that the eyes of a TC were rotated by 90° so he couldn't spot properly. So LOS is calculated from every single soldier and not from the AS.

Another argument against that AS are used directly for LOS is that soldiers do cross AS limits and - while moving - some soldiers of a unit may be in one AS while others are already in the next. This does not stop them from spotting.

I guess that LOS from AS to AS is used as a filter to lower the actual necessary spot checks. If there is no chance for a unit in one AS to spot someone in another (e.g. behind a hill) then don't test at all. Saves time.

My guess the reasons for ASes is that it makes the placement of the individual soldier much easier. An AS is a well defined and not too big area that the algorithm has to consider. Without the confinements of an AS it would become exponentially harder to place them right.

What would be nice is if we could exert some more control about what our ptruppen do. The face command helps in most cases. But sometimes in an urban environment or, like Paul said, at ridges or similar it is frustrating.

If we could change the origin of the face command to change the weights (*) for the algorithm that would be nice.

I tried to put that in a picture:

facingm.jpg

I drew the origin for the 'possible' case very close to the front because that's my feeling what CM does. In the game the origin stays in the centre.

UI wise that could be handled like this:

You give a face command like it is now but then 'space' would cycle through 'front', 'back', 'centre'. Indicated by moving the origin of the face arrow. The origin will always stay in the AS. If you don't use it everything will stay as is. No new buttons.

(*)

by weights I mean this: CM places the individual soldier as good as it sees fit. Every spot in the AS has a certain 'usefulness'. This will be determined by factors like closeness to a wall or hedge, direction of the face command, availability of other cover etc... If for instance the weights would be 'back' then spots in the reverse direction of the face arrow would be calculated as to be more suitable for a soldiers position. Result: the soldier would not cling to the wall and stay a few meters back.

I like your line of thinking. I would not be fixated about being able to pinpoint place troops if it were possible to better position and face within the box. To carry this a step further this would be great for placement in the large buildings that well exceed the 8 by 8 size.

It appears that with the developement of the latest game engine that the purpose of the area square has become less prominent. The tax on the CPU with smaller area squares appears a bit unclear.

Long story short: IMHO it's ok how it works now but there's still room for improvement.

I couldn't sum it up better. I love this game but there are a couple things that remove you from the immersion experience as it is now.

Thank you for the feedback everyone!

Link to comment
Share on other sites

0h the debates that could evolve.

Precompute LOS from every point to point when the map is created:

Well, that works easily if everyone's LOS point is the same elevation (Z coordinate), but start mixing in the various elevations for infantry lying, standing, kneeling, 'short' armor, 'tall' armor, hull guns, turret guns, and TC LOS versus gunner LOS for short and tall, and it rapidly becomes a debacle just in terms of map file size. Ugh.

For immersion, I just plot as close as I can, and issue a 'face' command. In a sense, there's little more that a platoon leader could do -- get behind that wall and face that-a-ways. If you consider turn-based play, there's already a huge level of abstraction you're playing under. Still the best sim out there in my opinion, but to each his own. More eye-candy in others, but that's not what I'm playing for.

Link to comment
Share on other sites

0h the debates that could evolve.

Precompute LOS from every point to point when the map is created:

Well, that works easily if everyone's LOS point is the same elevation (Z coordinate), but start mixing in the various elevations for infantry lying, standing, kneeling, 'short' armor, 'tall' armor, hull guns, turret guns, and TC LOS versus gunner LOS for short and tall, and it rapidly becomes a debacle just in terms of map file size. Ugh.

They could just limit to calculating the worst case scenarios no? As in, no possible way of getting LOS no matter the stance and height of the vehicle?

Link to comment
Share on other sites

Paulervisor64,

If you think your infantry positioning is challenging, just wait until you try to site a gun. You'll just love the gun stuck in a wall, halfway in and halfway out of a house, partially embedded in a church and wall and worse. One guy I know of had to use a demo charge to free a PaK 40 stuck with its gun barrel through the wall and out the other side. Let's say we didn't have high hopes for such an unorthodox approach, but amazingly, the gun was freed and still worked!

Given excellent firing position, the AI will unfailingly position the gun where it has absolutely no LOS from its part of the AS. In one case, I carefully placed my gun into a keyhole position behind a house and firing diagonally to the right, only to wind up with no gun, except for the last three feet of the trails sticking out of the house the gun was supposed to be behind! Tried about five times (on both sides of the keyhole) before giving up in despair. Wound up putting the gun in a crater to the right and in front of the house. Only slightly more fun is trying to put a gun in a gully such that the barrel's practically flush with the ground. Said gun wind ups either out of the gully, thus hopelessly exposed, or in the the gully, completely unable to see or shoot. And forget rolling it smartly forward into battery barely above mask, firing, then retiring. Why? No provision was made for doing this. Moving a gun is a nightmare (pick up trails, drag gun backward, turn gun around; get shot to pieces throughout). Contrast that with both period and reenactment group footage of infantry guns and antitank guns being brought into and out of action.

If BFC's going to fix something, as soon as the direct fire mortars and MGs are sorted out, I hope gun siting and movement get some love. Really needed!

Regards,

John Kettler

Link to comment
Share on other sites

So, if it takes a second to do that calculation, you'd not mind waitng 4000s for the game to set up?

I don't know when that calculation actually happens. Could as well be when the map is saved so you wouldn't notice when you start the game.

And I'm not arguing for a 1m AS anyway. Some more control about placement INSIDE the 8m AS would be nice.

...

Precompute LOS from every point to point when the map is created:

...

That would be silly and that's no the point of the pre-calculation: it is there to FILTER out unnecessary LOS checks later in the game.

Example:

Two groups of 100 men on a flat map with only a 100m ridge dividing them. Obviously there's no way to spot the enemy battalion but the computer doesn't know 'obviously'.

200 men spotting each other is 19.900 checks.

Now we use the precalculation: it tells CM that the ASes on one side of the ridge cannot see the ASes on the other side of the ridge. So don't try LOS between them (that also costs time but presumably much less than an actual LOS check).

That leaves 2 groups of 100 men spotting themselves - 9900 checks. 50% saved. And you get that save every few seconds when spotting is renewed.

CM does probably a lot of other things to avoid unnecessary LOS checks. LOS checking is probably one of the most expensive operations for CM. I think I would earn me a lifetime free CM subscription if I had an algorithm that would cut them in half! ;)

Link to comment
Share on other sites

That would be silly and that's no the point of the pre-calculation: it is there to FILTER out unnecessary LOS checks later in the game.

Erm, precisely. I wouldn't store all the "can't see here" data, just the "might see here" -- there's the first step reduction. From this AS, I only have to check these other ASes. At runtime, net those ASes against ASes that the OpFor actually occupies at the time of the check (the second step reduction), and you do the "real" calculation based on just those pairings. If a unit can see 10k ASes, but none contain OpFor, you do zero complex checks. You don't get to see failed checks, just 'successful', so no information bleed occurs.

This doesn't do anything for aural contacts. Even with that ridge in the way, I certainly might have a clue (sound contact?) if there are 3 Tigers rumbling along on the other side.

All in all, a sticky wicket any way you play it, but that's why we pay Steve, Charles, et al the big bucks. They get to worry about implementation.

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...