What are the limitations of CMSF in size ?

[dan/california]

The 32 bit issue locked in for Normandy, but it really needs to make the list for the Eastern Front family. 64 bits should be almost universal in another year or two.Then we can figure out what the other hardware limits are. For the most part you can throw money at the other factors.

[MikeyD]

On a 10km x 10km map...

10x10km on the Normandy beacheads you'd be counting your forces in Divisions, not mere Battalions. The battle of the Falaise pocket numbered roughly 15 Division each side, the Germans lost 60,000 men in nine days. You'll have to ponder what you're willing to give up in order to run maps that scale on your computer. 10x10 maps but the forces represented by 2-D sprites instead of animated 3-D objects? Then it wouldn't be CM anymore.

[DaveDash]

Some interesting perspectives:

Frontage (Attack/Defence) WW2

Division

Soviet: 4KM/50-120KM

German: 400-1000m/800-2000m

In the company level, where we mostly play:

Soviet: 350-1000m/700m-2000m

German: 500-800m/400m-1000m

British: 275m/925m

[gibsonm]

Yes but if the same engine / model is going to cover both the Second world War and modern timeframes, it needs to cope with both.

No one is forcing you to create a 10km x 10km hedgerow scenario, but if there are Eastern Front or Western Desert modules (or even if you want to cover a "post breakout" Western Front scenario) you may wish to while remaining in the Second World War timeframe.

[Alan8325]

10km x 10km isn't something I'd expect to see any time soon, it would just be fun. For modern combat however, larger map sizes than what are currently generally seen in CMSF would be nice for mechanized and armored combat so that the effective ranges of weapons don't cover the entire map. Advanced optics on vehicles could be utilized better as well. Even a 4kmx4km map would prevent most ATGMs on one side from hitting recon vehicles on the other side.

For missions in urban environments and complex terrain, smaller map sizes will always be ok because of the limits on engagement ranges and LOS. It doesn't really matter if you have plasma cannons with a 100km range.

[gibsonm]

10km x 10km isn't something I'd expect to see any time soon, it would just be fun. For modern combat however, larger map sizes than what are currently generally seen in CMSF would be nice for mechanized and armored combat so that the effective ranges of weapons don't cover the entire map.

Sure, its a tradeoff.

Which is why other products can offer bigger maps but the vegetation, etc. doesn't look as "nice" / "pretty" (it still works in terms of being simulated though).

[sfhand]

I just ran a test with ~20 tanks on a barren 4kX4k map with 10m elevation changes (this allows for movement and los checks rather than 2 battle lines 4k apart), everything went well in 2 player hotseat. Over the next couple of days I'm going to add other elements without increasing the force size just to see if adding anything other than units starts to cause problems.

I know that a few patches ago I made a 4kX4k map with about 1/2 of it filled in with differing vegetation and some buildings and the editor couldn't handle it (I believe that issue has been fixed). Since then I made another big map, which had pbem file problems as described in the OP, but the editor handled it fine. My best guess, because of that instance, is that the main problem is force size.

If that is true, the goal of a multiplayer mode that supports more than 2 players might be challenging (the more players the larger the forces involved, yes?)

[gibsonm]

To answer (hopefully in sequence).

Depending on what the tanks were doing, that's fine but once you start getting mutliple LOS checks (vehicles engaging multiple targets in a covered arc say), arty incoming, existing smoke billowing (and generating more LOS checks, etc.), air, each vehicle having multiple way points plotted, .... it tends to get "busier" and the load on the machine goes up.

2. as for multiplayer not necessarily. You could have as simple a setup as an Infantry commander looking after say a Mech Coy and and "Armoured commander" controlling a Tp of tanks and that's multiplayer (with all the C2 friction, etc.) without forcing the size of sides up.

[sfhand]

Tanks are moving on hunt commands with no target arcs (I assume this means more spotting calculations because of more area to scan). As I said earlier, my theory is that adding units is more detremental than adding map area. Much like your second point, adding players (like adding more map space) doesn't necessarily mean adding more forces, however, we can probably agree that basic human nature will lead to "more" sooner rather than later.

So, as a big fan of BF who is neither a game developer, progammer, or game market analyst, I know my views about what smart moves that would/could keep CMingeneral moving with the times are highly subjective. With that being said, from here it looks like time and resources spent on improving the game's ability to take advantage of multi-core 64-bit processing would be well spent. However, I suspect I am wrong because it could very likely mean starting over from scratch with a CMx3 engine.

[gibsonm]

Yes I think 64Bit wont happen until the market share of 64Bit machines (and OS's) is overwhelming (i.e. everyone's grand mother is using 64Bit Windows 7 or OS X Lion).

No one is going to buy a game that requires them to buy a new machine to run it on (die hard fans here excepted of course ).

Then its a marketing / business decision too.

Do they get Normandy "out the door" as 32Bit and then tell people that the next module is say 2 years away as they rewrite it from scratch to be 64Bit (and include all the "must haves" that pressure groups ask for) just to get say the UK module out?

Or do they stick with 32Bit, get the UK, SS / Bulge, Eastern Front, Desert, ... modules out accepting the limitation and have people complain that 32Bit is "so 2009" but with the advantage that Normandy purchases can still play the later modules as can people who buy new machines?

Then in say 2014 (absolute guess) we start the cycle over with a 64Bit CMx3 Modern Era and Second World War application coming out no doubt just in time to encounter the first consumer level 128Bit machines?

The joys of building something that takes time in an environment that is continually changing.

[sfhand]

I think it would take a dedicated effort, following the release of a new title, to try for major engine upgrades like x64 and multi-core support. Fortunately BF now has 2 coders, so one of them could dedicate himself to the new engine while the other supported the new release and its upcoming modules. This would keep the income stream going while the new/enhanced engine is in development.

The big trade off, if this were possible, would be in feature development. I'm pretty sure that right now most people would rather see the feature list expanded than to have an ability to play with larger forces on larger maps (say 4kX12k). While I like the optimism of your 2014 guess, I think you've lost you mind...

[gibsonm]

The big trade off, if this were possible, would be in feature development.

No the big trade off is that things will take twice as long to happen.

The two coders are currently fully committed to the current schedule (as I understand it) and we still have protracted release dates.

Cut that commitment by 50% and delivery dates will blow out still further.

Now if someone wants to give BTS / BFC enough money to employ 4 coders your plan of supporting current AND future ops concurrently has a chance.

As to the 2014 guess it doesn't matter (insert 2020, 2050 if you like) since people don't abuse me if its released a day, month, year later then they think they were "officially" promised.

[sfhand]

I don't think I've misunderstood when Steve has explained the difference between modules and games. I'm pretty sure he's said the difference was the game engine wouldn't, as a rule, have features added to it during module development, which is why I suggested that enhancing the engine wouldn't interfere with module development because they now have two coders (which came in handy with the development of a new game - CM:A - and a module - Nato -).

It seems clear that while a new game is being developed both coders would be busy on the task at hand (CM:N), and you have confirmed this. But once the game is developed the modules, by my understanding of Steve's comments, would take less coding because modules are based more on new content rather than new engine features.

So, I'm sticking to the big trade off being feature development, i.e., the time normally spent on feature development for a new game would be spent on porting the code to x64 multi-core.

[gibsonm]

Well by all means stick to it.

Merry Christmas.