Is CM:SF fundamentally flawed ??

[Battlefront.com]

Dale,

I fail to see how denegrating your CMx1 efforts, and our embracing of same, is supposed to convince us that CMx2 is more than what it appears to be.

Hey, I'm just following your own logic, that's all Through argumentation you are the one denegrating CMx1, not me. It was a great game system. Not perfect, but not inherently flawed in my opinion. Apparently not in your opinion either even though the "fundamental flaws" you point to in CMx2 are worse in CMx1 (or at least no better). So it is you that is arguing that CMx1 is fundamentally flawed, not me.

Again, if you want to argue that you enjoy CMx2 less than CMx1, fine... no argument there. So why not just keep it to an opinion that can't be argued with instead of a flawed line of logic that is so easy to take issue with that your only defense is to try and get me to stop highlighting that fact each time you make it? As I said, criticism without context is meaningless, so if you don't like the context I'm putting it in... suggest another that is applicable.

Oh, and I am not trying to say CMx2 is more than it appears to be. That's what other people are doing when they try to hold it against an impossible standard and saying that since it falls short of it then it has failed. CMx2 must be judged in context and that context must be reasonable if you wish to make an argument that is anything other than a personal opinion. The easiest way for this to be sidestepped is to try and remove context and argue in a vacuum. As I've said over and over again, that is an utterly pointless position to take.

Steve

[ September 29, 2007, 10:38 PM: Message edited by: Battlefront.com ]

[dalem]

Originally posted by Battlefront.com:

Dale,

</font><blockquote>quote:</font><hr /> I fail to see how denegrating your CMx1 efforts, and our embracing of same, is supposed to convince us that CMx2 is more than what it appears to be.

Hey, I'm just following your own logic, that's all Through argumentation you are the one denegrating CMx1, not me. It was a great game system. Not perfect, but not inherently flawed in my opinion. Apparently not in your opinion either even though the "fundamental flaws" you point to in CMx2 are worse in CMx1 (or at least no better). So it is you that is arguing that CMx1 is fundamentally flawed, not me. </font>

[bwgulley]

Christ man let it go. It's flawed you win, feel better.

[Sirocco]

Blue squad has LOS [action spot], but only half the squad members have clear LOF. Red squad has LOS and all squad members have LOF to blue squad members.

Until the remaining blue squad members re-position to gain LOF - assuming, for simplicity, there are no complicating factors - then CMx2 is flawed.

If that's an impossible standard to attain then what are we doing with 1:1 instead of the previous abstractions? In the above example the red squad has a 2:1 advantage purely based on a game flaw.

I understand this is extraordinarily difficult to program, and I admire the attempts so far made, but let's call a spade a spade for where we are with 1.03. I trust 1.04 will take another step forward with it.

[The DesertFox]

Hey it´s quite natural for BFC to say it isn´t flawed.

However it isn´t necessary for them to admit that, because everybody with eyes at the right place can make up their own minds basing on how the game performs right now.

Really a waste of time to further bother with the shortcomings of the engine. Either they fix it into something remotely working or people will move on, shrug and don´t bother anymore.

Fact is that in its current state this engine is far from something I would invest time into.

FWIW

[BeauCoupDinkyDau]

Originally posted by The DesertFox:

Really a waste of time to further bother with the shortcomings of the engine. Either they fix it into something remotely working or people will move on, shrug and don´t bother anymore.

Fact is that in its current state this engine is far from something I would invest time into.

I fully agree. I, like others, have stated why I don't care for CMSF. Once that is done, there is nothing left to do but sit back and hope that future versions of CM are better than what we are currently being offered.

There's no reason for most of the people who are upset with this game to keep going off, over, and over, and over.

Unless you have something new to add, then state your case and move on.

[Elmar Bijlsma]

Some people are still confusing "has flaws" (which BFC haven't denied, DesertFox) with "beyond any redemption".

[H.W. Guderian]

Originally posted by CptWasp:

<SNIP>I don't worry about micro-managing the squads; if they get destroyed, I think they have been caught by an ambush... <SNIP>

. . . but they *haven't* been "caught in an ambush."

They've decided to skip the gaping hole on the "safe" side of the house you ordered them through and instead ran around the front - in clear view of that BMP 40 metres away that your other squad in the house next door - the one on the radio - has had located for 5 minutes.

OR

They just stood around looking at funny muzzle flashes in thin air coming from the enemy squad they somehow can't see 30 metres away in plain view?

Hopefully the "pathfinding" issues can be resolved (?) but it seems hard to get around the fact that while CMX2 looks "1:1" what we really get is "8 X 8".

[dalem]

Originally posted by bwgulley:

Christ man let it go. It's flawed you win, feel better.

Relax, I'm just having a discussion. If you don't like the topic, don't click the link.

-dale

[W1ll1am]

Steve,

Originally posted by Battlefront.com:

It would take a LOT more than 4 times the computing resources (do not forget about RAM... it's a huge limiting factor) because the hardware intensive features of a wargame (LOS/LOF and Pathfinding) have exponential needs to increase fidelity. I'm a math moron, but here's a way to think about it:

Picture a grid of 20x20m squares. You want to travel 100m as the crow flies to another spot on the grid. The Pathing system, no matter how efficient it is, has to check all sorts of possible combinations of how to get from A to B. It could be, for example, that the ONLY way to get to where you want to go is to go backwards, then around something else. Your unit may have to go through 20 squares, to travel the equivalent distance of 5 (as the crow flies). Now reduce the size of the grid to 10x10m squares. Are there twice as many different ways to get from A to B, or now (because of the more refined grid) far more than that? The answer is far more than twice as many possibilities. A math guy will have to tell you what the actual number is, because I am a math moron

I'm not a math guy but a game AI developer who picked up the game to check-out your AI and improve my understanding of modern combined-arms tactics. Thusfar, I've really enjoyed your approach to 'hands-off' tactical AI, since I hate micro-managing units. (And I love zooming in on the Javelin team and seeing them take down a bunker).

FYI, in theory the cost of pathfinding increases with a factor between 2 and 4.6 for a factor 2 increase in resolution, and not more than that. There is no exponential increase in costs.

This is best understood as follows (assuming some kind of A* algorithm is used):

- the terrain surface (number of action spots) explored by the A* algorithm for a certain path depends primarily on the cost-function and heuristic used, and will be same regardless of the resolution. In the worst case, this is the full map and contains 4 times as many spots if the resolution is doubled. In the best case, the path is a straigth line, and contains 2 times as many spots.

- the 'open list' in A* (best interpreted as the out-line of the terrain surface being explored by the algorithm) will be about twice as large, for 2 to 4 times as long a search. Manipulation of the open list is O(log(size of open list)). When 'open list' manipulation is your bottleneck, the cost increase is (worst-case) (4*N * log(2*N)) / (N * log(N)), which is between 4.4 and 4.6 for N > 100 (closer to 4.4 for larger N).

For a change from 8m action spots to 1m action spots, the increase in costs can be computed along these lines (somewhere between 8 and 90). However, in those situations (basically "FPS situations"), you're better off doing two path finding calls; a first at (say) 8m resolution, and a second at 1m resolution but constrained to those 8m spots (and neighboring spots) found in the first search. That's probably in the order of 2 to 5 times as expensive as a single 8m resolution search, and with very good worst-case behavior.

Oh, but it gets worse

Currently each Team can only occupy one square. It can stretch out when moving between two, but as far as pathfinding goes there was only one calculation done for all those individual guys within the Team. Meaning, 5 guys may occupy two or more Action Spots at a given time while moving, but they will eventually get to the same spot from the same spot. If the grid is reduced this means the "units" have to be reduced to match the grid size. Otherwise you'll have 5-9 guys all in one square of whatever the new grid size is (let's say 1x1m). Well, since you can't have 9 guys all standing in one square meter you MUST break the unit up into, I dunno, 9 individual units. So you reduced the terrain resolution by a factor of 8, but potentially increased the number of units by a factor of 9. And guess what? Each one will now have to calculate its own LOS and paths.

Now, take the two concepts above and combine them. You get an explosion of LOS/LOF and Pathing calculations for each individual unit, then you increase the number of units by a huge number. Er... hopefully the results of that are obvious for you all to see. Major increases in computing resources are needed for even a modest increase in fidelity.

For path-finding, it should be sufficient to find a path for the unit's leader, and have the other members move into positions based on steering behaviors. This costs less, and won't suffer from sub-optimization where one of the team's soldiers breaks cohesion because he himself is able to find a marginally cheaper path on the other side of a building.

For grid reduction, LOS probably is much bigger problem (in the games I worked on, LOS/LOF consumed much more CPU than pathfinding). In addition to the problems you mention, an increase in resolution is likely to give a decrease in robustness for picking cover and attack positions. If the attack or cover position is picked based on the 1m action spot of the (known) opposing units, a slight displacement of those units is more likely to invalidate the cover or attack position (than when using 8m action spots).

Again, a hybrid approach with action spots at two levels of detail (8m action spots consisting of 64 1m spots) may give you the best-of-both worlds. Only when LOF/LOS checks between 8m action spots are inconclusive, you'd need to fall back on more detailed LOF/LOS checks. In the (FPS) games I worked on, we employed a mix of action spot sizes (large sizes when terrain geometry was trivial, and small sizes when geometry was complex), we pre-computed part of the LOS/LOF checks in a compressed table, and only performed ray casts when the table's answer was inconclusive or would not be representative (there were dynamic obstacles present or absent between the unit and it's opponents). Because of these savings, we were be able to do path finding with LOF checks per position ("tactical path-finding").

As a reference, only a few FPS games today come close to the vehicles mix and unit counts as exhibited in CMSF (think Battlefield series, and Bohemia Interactive's Armed Assault [recommended, it's the Operation Flashpoint successor]). Both these games seem to use >1m tiles or exhibit sloppy cover / attack position picking.

Kind regards, thanks for the Javelins,

looking forward to more of your team's games (and patches).

William

[Guest]

...and won't suffer from sub-optimization where one of the team's soldiers breaks cohesion because he himself is able to find a marginally cheaper path on the other side of a building.

I was trying to think of an additional upside to lead path + steering last night (given the possible complexity of implementing it within their current engine). Good one.

[dan/california]

FYI, in theory the cost of pathfinding increases with a factor between 2 and 4.6 for a factor 2 increase in resolution, and not more than that. There is no exponential increase in costs.

This is best understood as follows (assuming some kind of A* algorithm is used):

- the terrain surface (number of action spots) explored by the A* algorithm for a certain path depends primarily on the cost-function and heuristic used, and will be same regardless of the resolution. In the worst case, this is the full map and contains 4 times as many spots if the resolution is doubled. In the best case, the path is a straigth line, and contains 2 times as many spots.

- the 'open list' in A* (best interpreted as the out-line of the terrain surface being explored by the algorithm) will be about twice as large, for 2 to 4 times as long a search. Manipulation of the open list is O(log(size of open list)). When 'open list' manipulation is your bottleneck, the cost increase is (worst-case) (4*N * log(2*N)) / (N * log(N)), which is between 4.4 and 4.6 for N > 100 (closer to 4.4 for larger N).

Steve, meet Charles's new assistant. In our generosity the community will give him one week to quit whatever he is doing and move into Charles's basement and or doghouse like a good apprentice. I recommend a six month trial before his brain is decanted into a jar.

[Guest]

Huh. That's almost exactly what I was thinking when I read his post, except for the decanting bit.

[dan/california]

That is two votes for him, should we start a separate thread for the poll?

And we will give him a year to adjust to the idea of the jar. :cool:

[Battlefront.com]

Dale,

I really can't follow you here. CMx1 said "Hey, we're the best abstraction around, so good that it approaches realism at some points!" I don't see any flaws there, because that's what it did, at least on-screen.

From what I have gathered, and I may be completely wrong, CMx2 says "Hey, we are 1:1, baby! Hear us roar 1:1!" I see a flaw there, because that's not what it does, at least on-screen.

That's the crux of the problem, Dale. We never said the CMx2 implementation of 1:1 is perfect. In fact, I have explicitly stated that it never will be because, drum roll...., there is no way it ever can be. If you want to boil it down to simpleton terms... CMx1 was a reasonable abstraction of combat, CMx2 is a more refined abstraction of combat. Because CMx2 is not perfect doesn't make it "fundamentally flawed" any more than CMx1 was "fundamentally flawed". Each has its sets of abstractions, side effects and benefits combined, so it is not credible to argue that by only looking at the flaws in one and not the flaws in the other when making a pronouncement such as "fundamentally flawed". Without a context such an argument holds no value and therefore comparison to similar games is not only relevant, it is necessary.

There can be no closer comparison made to CMx2 than CMx1 since one came from the other and both came from the same developer. That is why I keep bringing it into the discussion. Instead of you challenging the points I raised in the direct comparisons, you instead challenge the need to have context. To me this is an admission that your line of argumentation is flawed, since the best way to argue a position that is impossible to support is to argue in a vacuum. This is why discussions with people who utterly reject something fundamental, such as war or atheism, hate it when "irrelevant" things like history, Human biology, science, etc. are brought into the mix. It's a LOT easier to say "I think war is fundamentally flawed" if you don't have to answer the question "what happens if your neighbor doesn't agree and invades with a military force?". I've had arguments with people like this and the answer is, "if everybody rejected war then this wouldn't happen". It's as out in left field of logic as what is going on here. The perfect world doesn't exist, so using that as your "context" is intellectually convenient, but logically flawed.

I'll repeat myself... you may personally find that the lack of true 1:1 representation kills enjoyment for you. That's a reasonable position to take and it can not be argued with. But that is night and day different from trying to establish a factual claim, which is empirical and universal. Saying CMx2 is "fundamentally flawed" is the latter type and it is why it is being so vigorously rejected by me.

Elmar,

Some people are still confusing "has flaws" (which BFC haven't denied, DesertFox) with "beyond any redemption".

That's it in a nutshell! So... CMx1 fan out there... what would you say to a Steel Panthers fanatic that says that because CMx1 is not top down it is "fundamentally flawed"? What would you say to a Close Combat fan who says that CMx1 is "fundamentally flawed" because individuals soldiers aren't explicitly simulated? I know what you'd say because you already said it... "sod off!" So now we have some people that don't like CMx2 and they are trying to argue it is "fundamentally flawed" using the same logic. And that is "I don't like it, therefore it is fundamentally flawed". It's not a sound argument to make.

William,

Welcome! There are a few other AI programming guys on this Forum from time to time, so you're not alone

For a change from 8m action spots to 1m action spots, the increase in costs can be computed along these lines (somewhere between 8 and 90). However, in those situations (basically "FPS situations"), you're better off doing two path finding calls; a first at (say) 8m resolution, and a second at 1m resolution but constrained to those 8m spots (and neighboring spots) found in the first search. That's probably in the order of 2 to 5 times as expensive as a single 8m resolution search, and with very good worst-case behavior.

CMx2 already uses two different passes on the pathfinding, so that's true that it cuts down on the exponential degree of resolution increase. The other methods of reducing pathfinding calls, as I understand it, is to restrict how many different directions and how many different times it searches. However, the devil is in the details, so the results are often suboptimal from a user standpoint even though they are acceptable from the system's standpoint.

For path-finding, it should be sufficient to find a path for the unit's leader, and have the other members move into positions based on steering behaviors. This costs less, and won't suffer from sub-optimization where one of the team's soldiers breaks cohesion because he himself is able to find a marginally cheaper path on the other side of a building.

This is how it currently works within Teams and, to an extent, within Squads (i.e. 2-3 Teams). But again the devil is in the details One of the outstanding pathing issues we have with Squads now is that it is not always possible to "follow the leader" and is in fact sometimes suboptimal to do so. Therefore, the internal components of a Squad require the ability to direct themselves to some extent. Charles has managed to improve the outcome of this behavior quite a bit in v1.03 and v1.04, but there is still a particular circumstance that he needs to fix.

For grid reduction, LOS probably is much bigger problem (in the games I worked on, LOS/LOF consumed much more CPU than pathfinding).

Bingo. From a technical standpoint LOS calculations are very straight forward and less inclined to produce negative results when compared to pathfinding. However, computationally LOS checks are expensive and can't be abstracted very well because, well, LOS isn't supposed to be abstracted As far as I know CMx2 currently uses the same sort of "rough check, refined check" system. Regardless, dramatically increasing BOTH the number of entities checking AND the complexity of the terrain to check is a very bad thing from a performance standpoint. There isn't any way to change this fundamental reality, though one can use tricks to reduce its impact.

I guess what I'm saying here is that pathing will tax the system more if we break the terrain and units down into smaller pieces. How much more? I don't know. But it is only one of the many side effects. The other major one is LOS since it is a very expensive calculation and if you break individuals on their own, then each will need to calculate its own LOS. Now we go from a couple dozen calculations at a given time to several hundred. It's not something that Charles feels is possible.

Some of the other problems are more straight numbers. It takes x bits of memory to store information about the location and composition of a single piece of terrain, what's currently on it, how it relates to other terrain, its elevation, etc. Take an 8x8 terrain grid and make it into 1x1 and you have something like a 63 fold increase in RAM footprint (probably not quite that much, but closer to that then not). A finer resolution of terrain also means a finer resolution of the terrain graphics, which means more work for the GPU (video card) and VRAM as well. Then there is the other big one which is AI since the more autonomous individuals are the more AI is required to keep them acting as coordinated entities rather than individual rogue elements. In fact, it is clear that people are unhappy with some of this AI now and the resolution is not nearly as refined

As a reference, only a few FPS games today come close to the vehicles mix and unit counts as exhibited in CMSF (think Battlefield series, and Bohemia Interactive's Armed Assault [recommended, it's the Operation Flashpoint successor]). Both these games seem to use >1m tiles or exhibit sloppy cover / attack position picking.

I've not played Armed Assault (my system wouldn't handle it well), but I have played Battlefield 2. One trick they use is to have vast areas of uniform terrain. As with CMx1's 20x20m terrain tiles, it's a lot easier to draw a 20m straight line knowing that there is nothing to get in your way

Kind regards, thanks for the Javelins,

We have a special affinity for the Javelins

looking forward to more of your team's games (and patches).

Thanks!

Having said all that I've siad... it is our intention to refine the terrain over time. 1x1m is probably never going to happen, but 4x4m may be possible at some point in the near future. We have to just wait and see.

Steve

[MikeyD]

It sounds like some people are using the phrase "fundamentally flawed" in the same way Neocons always throw around the term "existential threat". The phrase isn't accurate or decriptive of what they're talking about but it fulfills a certain dramatic purpose. If uploading CMSF corrupted your operating system it would be fundamentally flawed. If it wasn't entertaining to play it would be fundamentally flawed. But its not.

[Battlefront.com]

Oh, the other shortcut FPS games, and others, take with pathfinding and LOS (amongst others) is to simplify the model. The most obvious one is limiting the number of individual entities requesting attention for the game system. Fewer units, fewer demands, better performance.

Further than that, there is simplifying the game mechanics so that basic things, such as pathing and LOS/LOF, can be calculated faster and with less hardware impact. Most FPS games have very binary systems. The terrain is either passible or impassible, something blocks LOS or doesn't block LOS. In playing Battlefield 2 I found no noticable difference moving through open ground, roads, grass, or inside of buildings. Same movement rate (speed), same drain on stamina. In fact, going up ladders in BF2 goes at a single rate and there is no hit to stamina at all. Infantry also has only three speeds... full stop, moderate, and fast. Vehicles have only two speeds... full stop and fast. Acceleration for infantry is instant, acceleration for vehicles is simulated (though quite "gamey").

The list goes on and on, I'm sure. The point of listing these things is not to say Battlefield 2 sucks (it doesn't , rather it illustrates the sorts of game design choices the developer made in order to free up hardware resources for other things. In other words, the more simple the core of the game, the more options there are for other things. CMx2 is all about the core game, so we've got to do different things to keep the hardware from grinding to a halt.

The primary one is to have a less refined terrain mesh than a FPS game and focus on units instead of individuals. Same was true for CMx1. But since hardware has improved a LOT over the past 5 years, so too has CMx2's ability to handle more refined terrain and more attention to individuals. It isn't 1:1 in either case, at least compared to the real world, but it is closer to that ideal than CMx1 was.

Steve

[ September 30, 2007, 11:44 AM: Message edited by: Battlefront.com ]

[Sirocco]

Originally posted by MikeyD:

It sounds like some people are using the phrase "fundamentally flawed" in the same way Neocons always throw around the term "existential threat". The phrase isn't accurate or decriptive of what they're talking about but it fulfills a certain dramatic purpose. If uploading CMSF corrupted your operating system it would be fundamentally flawed. If it wasn't entertaining to play it would be fundamentally flawed. But its not.

To me, 1:1 combat means that each element (1:1) of your, and the OPFOR, should be able to play some sort of part on the battlefield. This isn't happening in this game. Yeah, i'm seeing 1:1 soldiers on the map, but what's the point if most of them don't appear to be doing FA ?

I just thought I'd repost the original premise of this thread, as it's become obscured by the amount of smoke being thrown around.

[KNac]

I do see soldiers do stuff. Other thing is that they always don't do what they should, and we allready know why this happen and that eventually will get better (hopefully soon, I espect 1.05 to be really fun and very playable).

[Nick Schieben]

>>If it wasn't entertaining to play it would be fundamentally flawed. But its not. >>

Yes it is. ..and that's it's not its

[dalem]

Originally posted by Battlefront.com:

That's the crux of the problem, Dale. We never said the CMx2 implementation of 1:1 is perfect. In fact, I have explicitly stated that it never will be because, drum roll...., there is no way it ever can be. If you want to boil it down to simpleton terms... CMx1 was a reasonable abstraction of combat, CMx2 is a more refined abstraction of combat. Because CMx2 is not perfect doesn't make it "fundamentally flawed" any more than CMx1 was "fundamentally flawed".

-snipperoo for space -

Well, I still think that CMx2 "gets wrong" the single key thing it must "get right", but I think we're just talking past each other at this point, so I'll drop it. Thanks for the jawing though, I appreciate it.

-dale

[aka_tom_w]

Originally posted by dan/california:

</font><blockquote>quote:</font><hr /> FYI, in theory the cost of pathfinding increases with a factor between 2 and 4.6 for a factor 2 increase in resolution, and not more than that. There is no exponential increase in costs.

This is best understood as follows (assuming some kind of A* algorithm is used):

- the terrain surface (number of action spots) explored by the A* algorithm for a certain path depends primarily on the cost-function and heuristic used, and will be same regardless of the resolution. In the worst case, this is the full map and contains 4 times as many spots if the resolution is doubled. In the best case, the path is a straigth line, and contains 2 times as many spots.

- the 'open list' in A* (best interpreted as the out-line of the terrain surface being explored by the algorithm) will be about twice as large, for 2 to 4 times as long a search. Manipulation of the open list is O(log(size of open list)). When 'open list' manipulation is your bottleneck, the cost increase is (worst-case) (4*N * log(2*N)) / (N * log(N)), which is between 4.4 and 4.6 for N > 100 (closer to 4.4 for larger N).

Steve, meet Charles's new assistant. In our generosity the community will give him one week to quit whatever he is doing and move into Charles's basement and or doghouse like a good apprentice. I recommend a six month trial before his brain is decanted into a jar. </font>

[Battlefront.com]

Dale,

Well, I still think that CMx2 "gets wrong" the single key thing it must "get right", but I think we're just talking past each other at this point, so I'll drop it. Thanks for the jawing though, I appreciate it.

OK. Just remember that "get right" is a matter of opinion. You feel CMx2 hasn't gotten it right, tons of people didn't think CMx1 got it right. It's a matter of opinion and therefore there is room for disagreement. On the matter of CMx1 we are in agreement with each other and disagreement with many. On the matter of CMx2 we disagree with each other and can see that others have disagreements over this too.

Personally, CMx2 has it about right. Some bugs and some limitations we're looking to overcome, but these are fairly minor compared to the system as a whole. However, even as it was months ago (long before it was released) it was clearly a massive improvement over CMx1. Obviously that is just my opinion, but since this is all about opinion we'll just have to agree to disagree.

Steve

[Charlie901]

Man,

With all the time Steve has to spend in here Defending the game, where's he gonna get the time to fix it?

[TheNathan]

So, if the refinement in LOS/LOF is much more taxing on hardware, shouldn't the game be true we-go so the machine can effectively process what is going on in 60 second intervals like in CMx1? From what I read back in the day, the reason why CMx1 was we-go was that it would be impossible to run the game on computers of the time if the game was real-time. So, given advances in computer technology, shouldn't we go for as much of a refined and realistic system as current systems allow by utilizing we-go?