Dissapointed by CMBN

[Rocken]

All in good/due time, suffice to say more then half of the bugs fixed by the programmers I have yet to see them reported as a bug here on this general forum. This thread had an earlier discussion regarding tank accuracy, in particular firing on the move. Now, moving tanks fire their weapons with even less accuracy.

well wouldnt it be nice to have it fixed all at once?

btw nr3 is fixed: "Tankluck"...

[Guest]

well u know that bug? k tell me about the others

me as a customer would be very excited to her about them and the patch

and tyvm for ur honest statement!

First, you're welcome.

Second, if there are any bugs in your list that are unreported, please report them in a separate thread so that they can be discussed and tracked more easily.

Third, if the bugs in your list were reported on the forum then they've been looked into. Whether they're actually bugs, fixable, etc., is another story, but they've been looked at.

I can't say without your list being clearer (as in, clear enough that we know what you're talking about) whether the bugs in question have been fixed or not, and honestly even if I knew what they were I still couldn't say for some of them - we're still testing the patch so it may turn out that things are going to need additional work.

[MikeyD]

Lets differentiate between 'bugs', 'broke' and 'insufficiently advanced'. We knew this game was an ongoing long-term project. Expanded units and equipment showing up in modules, refiinements and fixes showing up in patches. There's an old Chinese homeowners proverb "House all finished. Now we can die." I suspect the CMx2 game engine is not going to be 'finished' until Steve & Charles retire or until the seas rise to engulf us all. Whichever comes first.

[WineCape]

well wouldnt it be nice to have it fixed all at once?

What?! And leave nothing for dessert?

btw nr3 is fixed: "Tankluck"...

I thought it referred to the sound of the tank tracks.

[Rocken]

First, thank you

Second, i did report these bugs in the general forum, even with screenshots..

Third, me as a customer want a proper response to flaws in the game, not mentioned in the manual.

Fourth, i want to know when these bugs are fixed

[Guest]

First, thank you

Sure.

Second, i did report these bugs in the general forum, even with screenshots..

Excellent, then they've been looked at.

Third, me as a customer want a proper response to flaws in the game, not mentioned in the manual.

Fourth, i want to know when these bugs are fixed

If you'd like to know when we're fairly certain these bugs have been fixed, then you will be. There will be a list of fixes in the patch when the patch is released. That's when we release the patch: when we've addressed what bugs we're going to address, and we're as sure as we can be that they're fixed.

So what's the proper response, then? A list of bugs? Our internal bug list and any list of bugs out here will bear little resemblance to each other. To make them match up would be an ongoing job, and it still wouldn't be accurate. Bugs usually have many moving parts - something you regard as one bug may require a lot of separate pieces of work. Tracking it is hard; somehow tying it back to the massive list of "possible" bugs out here would be a nightmare.

[Vanir Ausf B]

We're always working on improving performance. Is that suddenly going to double frame rates? No. The game is *fast* considering what it does under the hood.

Believe me, I understand. I would love to switch over to CM and suddenly have it be twice as fast. You have no idea how much I would love that. The thought of it makes me smile involuntarily. And if I thought it could actually happen I would do everything in my ability to make it so.

How much would CMx2 benefit from multithreading were it capable of it?

[Broken]

But I've spent my career optimizing applications - beyond AI that's really my primary skillset. And CM is... well, let's just say Charles has done a fantastic job. We'll keep working on it, but unless we compromise our design goals - thousands of units, all driven by individual AI, on very large and complex maps requiring real pathfinding - or suddenly everyone gets supercomputers we're never going to run as smoothly on the highest settings as your next $50 million RTS.

Why aren't you guys multi-core? It doesn't make sense to beat one-core optimization to death when you can easily access four cores on your typical customer's setup.

I can understand the reluctance to thread on multiple cores, but why not at least run multiple processes with memory-mapped communication? Even I, not exactly a high powered programmer, have written that functionality in a few man-weeks. Every new PC has at least two, sometimes eight+, cores. I have 12.

[Guest]

Why aren't you guys multi-core? It doesn't make sense to beat one-core optimization to death when you can easily access four cores on your typical customer's setup.

We're looking at months, not weeks. At least. And "access" doesn't equal "optimization". We'd have to rewrite parts of the engine to properly use multiple cores. Without that we'd just be doing a lot of work - and testing, mind - to get an extra half a frame, if that (if we were lucky and didn't take a performance hit for it).

*With* algorithms rewritten we'd get something, but how big would it be? Clearly Charles doesn't think it would be huge. I've got to say I agree with him.

I can understand the reluctance to thread on multiple cores, but why not at least run multiple processes with memory-mapped communication? Even I, not exactly a high powered programmer, have written that functionality in a few man-weeks. Every new PC has at least two, sometimes eight+, cores. I have 12.

Because the engine is enormous, and it wasn't built for that in the first place? You're recommending a massive amount of work. I have written that functionality, too, in some very complex applications, and after spending a year in CM's code I can safely say it would be very hard.

[ClarkWGriswold]

This thread had an earlier reference wrt tank accuracy, in particular firing on the move. Now, moving tanks fire their weapons with even less accuracy.

The real question is, do the tanks now stop to shoot? Making firing on the move less accurate is a good thing, but if the tankers never bother to stop (and, therefore, don't give themselves the best chance of hitting), then it could wind up being almost a step backwards.

If the tanks don't stop on their own to fire, it's going to be fun (read: frustrating) getting your men to stop and take a shot when they should. Should be especially "fun" in WeGo. I've no idea how you'd even attempt to time orders to maximize your chances of a good shot.

[Battlefront.com]

The real question is, do the tanks now stop to shoot? Making firing on the move less accurate is a good thing, but if the tankers never bother to stop (and, therefore, don't give themselves the best chance of hitting), then it could wind up being almost a step backwards.

No CM game, since 1997 when we started writing what became CMBO, has ever had vehicles automatically firing from short halts. In that sense, CM:BN is as "broken" as CM:A, CM:SF, CMAK, CMBB, and CMBO. 11+ years of gaming pleasure has, therefore, been ruined by this consistent issue. Or not

What we've always done is allowed them to fire on the move with slightly better accuracy than they would have in order to compensate. The problem we have in CM:BN now is "slightly" isn't "slight" enough. It's been tweaked for v1.01.

Steve

[Broken]

We're looking at months, not weeks. At least. And "access" doesn't equal "optimization". We'd have to rewrite parts of the engine to properly use multiple cores. Without that we'd just be doing a lot of work - and testing, mind - to get an extra half a frame, if that (if we were lucky and didn't take a performance hit for it).

*With* algorithms rewritten we'd get something, but how big would it be? Clearly Charles doesn't think it would be huge. I've got to say I agree with him.

Interesting. Because to me, it seems there is a lot of parallelism in your application. Line-of-sight, Line-of-fire(?) are not light-weight calculations but are mainly read-only to the database and therefore easy to make parallel. Likewise, path-finding and other AI which can be done independently on a unit by unit basis is a natural for parallel code.

Because the engine is enormous, and it wasn't built for that in the first place? You're recommending a massive amount of work. I have written that functionality, too, in some very complex applications, and after spending a year in CM's code I can safely say it would be very hard.

I can believe the engine is enormous. My point is that an initial investment in multi-core pays big dividends down the road in product performance and programmer productivity. Single-core optimization becomes less critical, so you don't waste resources on it. One nice advantage is you can run one core process in C/C++ for performance and another in python,lua,ruby, or c# for productivity.

[Guest]

Interesting. Because to me, it seems there is a lot of parallelism in your application. Line-of-sight, Line-of-fire(?) are not light-weight calculations but are mainly read-only to the database and therefore easy to make parallel. Likewise, path-finding and other AI which can be done independently on a unit by unit basis is a natural for parallel code.

Being natural for parallel code, and being easy (or even possible) to decouple to effectively parallelize, are two entirely different things.

What this comes down to - both of the suggestions here - is rewriting the engine, an engine with years of code and more importantly years of testing invested in it. If we made these fundamental changes... the amount of testing necessary to be certain things hadn't broken would be enormous, on top of the number of developer hours required to get it done.

I can believe the engine is enormous. My point is that an initial investment in multi-core pays big dividends down the road in product performance and programmer productivity. Single-core optimization becomes less critical, so you don't waste resources on it. One nice advantage is you can run one core process in C/C++ for performance and another in python,lua,ruby, or c# for productivity.

I've got to think maybe you've never attempted to debug a very large multithreaded application? "Wasting resources" is precisely the phrase that comes to mind. If I'm wrong let me know, but I've done it before and getting an extra 5 or 10%, if we were lucky, would come at a cost of vastly increased code complexity.

The bulk of the engine is number-crunching or OpenGL. To steal an awful colloquialism, it's very "close to the metal". None of the productivity languages you list would be all that useful to us, frankly, and I've happily built products in most of them. I've also been asked to build AI in most of them, and I can say unequivocally that number crunching isn't their thing.

So - vastly increased code complexity (at least for us; realize that a game written in C++ and an application written in C# are at very different places in the spectrum of starting complexity), no real fringe benefits, and a massive amount of testing and no small amount of new code to be written - for what? That's the question we have to ask ourselves, and so far the answer has been "not enough".

[Broken]

Being natural for parallel code, and being easy (or even possible) to decouple to effectively parallelize, are two entirely different things.

What this comes down to - both of the suggestions here - is rewriting the engine, an engine with years of code and more importantly years of testing invested in it. If we made these fundamental changes... the amount of testing necessary to be certain things hadn't broken would be enormous, on top of the number of developer hours required to get it done.

I agree with you here: it is usually far easier to build parallelism in from the start than to modify a large program to be parallel. But you guys have parallelism already: your engine runs on a CPU plus a GPU. Adding parallelism isn't just about adding threads.

I've got to think maybe you've never attempted to debug a very large multithreaded application?

I am speaking of multi-process, not multi-thread. Run a separate process on each core. Each process can be single-threaded if you like. The processes share data structures through OS-provided memory-mapping. The interaction is quite similar to CPU-GPU multiprocessing, which I am sure your game engine must employ.

It is much easier to migrate most single-core designs to multi-core via multi-processing instead of multi-threading, at least for me.

"Wasting resources" is precisely the phrase that comes to mind. If I'm wrong let me know, but I've done it before and getting an extra 5 or 10%, if we were lucky, would come at a cost of vastly increased code complexity.

Yes, that is my experience with multi-threading as well. It sucks, although some astro-physics friends have had good luck with openMP on their application. OpenMP does not appeal to a control freak like myself.

Multi-processing, however, has worked well for me on a neural network engine I built. This is an app that scales to 5 cores with 80% efficiency, so I get 4 times the throughput of a single core. At 6 GBytes memory footprint, it is not a tiny application.

The bulk of the engine is number-crunching or OpenGL. To steal an awful colloquialism, it's very "close to the metal". None of the productivity languages you list would be all that useful to us, frankly, and I've happily built products in most of them. I've also been asked to build AI in most of them, and I can say unequivocally that number crunching isn't their thing.

You guys don't script at all!? Python and Ruby have gotten 2X-3X faster in recent years. One of the physicists I know has his postdocs do heavy number crunching in Python which has been pre-compiled into C.

I prefer C/C++ with Intel intrinsics for number crunching, but that's because I'm obstinate.

So - vastly increased code complexity (at least for us; realize that a game written in C++ and an application written in C# are at very different places in the spectrum of starting complexity), no real fringe benefits, and a massive amount of testing and no small amount of new code to be written - for what? That's the question we have to ask ourselves, and so far the answer has been "not enough".

Even your GUI is in native C++? That IS old school.

Actually, I think your code gets simpler in with multiple processes because you don't need to optimize nearly as much. Optimizing code for speed is a huge complexity driver.

I think you guys got frustrated with parallelism because multi-threading is pretty sucky. Look into multi-process instead. It is way easier to design and get big performance boosts.

[Agua]

No CM game, since 1997 when we started writing what became CMBO, has ever had vehicles automatically firing from short halts. In that sense, CM:BN is as "broken" as CM:A, CM:SF, CMAK, CMBB, and CMBO. 11+ years of gaming pleasure has, therefore, been ruined by this consistent issue. Or not

<snip>

Steve

Isn't that what the old "hunt" command provided? Upon spotting an enemy unit, it halted and fired, then once the threat was out of los, it moved on? Maybe I'm remembering it incorrectly.

[Edited to include the following:] Sorry, I gotcha. Yes, the old hunt did this, but that did not preclude AFV from doing so under other movement orders.

[G B Scurlock]

I haven't experienced any of the points he talks about.

[Guest]

Broken - I want to continue this conversation at some point, but I want to stop now and say that games aren't as easy (or fruitful) to parallelize as AI. I have some insight into this, because I spent a decade doing the latter, in a very big way.

Basically, this is a good discussion, but it's not offering me anything that wasn't in my bag of tricks already, and believe me when I say I've already considered applying them (and the ones that do apply well are already in, or they will happen when there's time). Charles' bag is even more applicable to the problems we're facing, he's looked into it as well, and he thinks we won't get much from it. As I said before I'm inclined to agree with him.

[panzermartin]

To help the beta team, here is the "mountbug" Rocken is refering to:

http://www.battlefront.com/community/showthread.php?t=98943

TCP/IP seems like the less tested game area. Other TCP/IP bugs:

Treebug (fixed in 1.01)

Phantom artillery (rounds are heard but not seen explode-guest side)

[Broken]

Broken - I want to continue this conversation at some point, but I want to stop now and say that games aren't as easy (or fruitful) to parallelize as AI. I have some insight into this, because I spent a decade doing the latter, in a very big way.

Basically, this is a good discussion, but it's not offering me anything that wasn't in my bag of tricks already, and believe me when I say I've already considered applying them (and the ones that do apply well are already in, or they will happen when there's time). Charles' bag is even more applicable to the problems we're facing, he's looked into it as well, and he thinks we won't get much from it. As I said before I'm inclined to agree with him.

Thanks for being as polite as you have been. This type of discussion can get heated in a hurry.

But now you have me interested in the challenges of multi-core game engines....

[ClarkWGriswold]

No CM game, since 1997 when we started writing what became CMBO, has ever had vehicles automatically firing from short halts.

I must be misunderstanding what you're saying here. Were we all hallucinating tanks stopping to fire for the past 10 years?

What we've always done is allowed them to fire on the move with slightly better accuracy than they would have in order to compensate.

Allowing them to fire on the move is no problem. I think everyone's in agreement that firing on the move took place in the actual event, under the right circumstances (close range, firing to suppress, firing at soft targets, etc). The problem is that tanks in CMBN don't seem to ever stop to fire, unless they just happen to reach the end of their ordered waypoints. This is a big contrast to real life where tanks would prefer to stop before firing, so that they actually had the chance to hit something.

The complaints that are being lodged are less about tanks being accurate on the move and more about being moving in the first place. Having tanks that don't stop to fire dramatically changes the flow of how the game works compared to what we're used to in CMx1 and what we've all read about happening in real life. We expect tanks to stop, line up their shot, fire, then move along. The exceptions to this would be when something else is more important (ie: they've been ordered to move very quickly, so the destination is more important; they have the opportunity to fire but are also under imminent threat and are trying to save their own hides).

[Agua]

I must be misunderstanding what you're saying here. Were we all hallucinating tanks stopping to fire for the past 10 years?

Allowing them to fire on the move is no problem. I think everyone's in agreement that firing on the move took place in the actual event, under the right circumstances (close range, firing to suppress, firing at soft targets, etc). The problem is that tanks in CMBN don't seem to ever stop to fire, unless they just happen to reach the end of their ordered waypoints. This is a big contrast to real life where tanks would prefer to stop before firing, so that they actually had the chance to hit something.

The complaints that are being lodged are less about tanks being accurate on the move and more about being moving in the first place. Having tanks that don't stop to fire dramatically changes the flow of how the game works compared to what we're used to in CMx1 and what we've all read about happening in real life. We expect tanks to stop, line up their shot, fire, then move along. The exceptions to this would be when something else is more important (ie: they've been ordered to move very quickly, so the destination is more important; they have the opportunity to fire but are also under imminent threat and are trying to save their own hides).

No, he was right. See my post up thread. The old "hunt" *allowed* stop & fire, but it didn't preclude firing while moving.

[ClarkWGriswold]

No, he was right. See my post up thread. The old "hunt" *allowed* stop & fire, but it didn't preclude firing while moving.

Right. Which is what I think most everyone is advocating. Shooting on the move when appropriate (very close shots, tank in imminent danger, shooting low priority targets) and stopping to fire when appropriate (virtually all the rest of the time).

Tanks in CMBN seem to always move while firing. I don't recall ever seeing any of my AFVs stop to take a well aimed shot unless they were on Hunt. And then, of course, they stop but don't start moving again until you've given them fresh orders. So, even if the rate of hits is abstracted for this, it still throws off the game because armored vehicles don't stop as they should. I can't run my panzerfaust over to take out a sherman if the sherman never stops to fire. My AT gun can't get off a good shot from his covered position because the enemy tank is constantly on the move. Stuff like that. It changes the dynamics of the game and it just plain doesn't match reality, which is what most people playing a game like CMBN are looking for.

[Guest]

Thanks for being as polite as you have been. This type of discussion can get heated in a hurry.

Sure thing. Let's just say I had a similar thought process before I spent serious time in the problem space. My thought processes have had to adapt a bit.

When there's time - post-patch, maybe? - I *would* like to discuss your observations and results with the various available tech. Never hurts to have more data! Feel free to drop me a PM or email if you'd like to - or start a forum thread.

But now you have me interested in the challenges of multi-core game engines....

It certainly is interesting. The problems are... entertaining.

[ASL Veteran]

Right. Which is what I think most everyone is advocating. Shooting on the move when appropriate (very close shots, tank in imminent danger, shooting low priority targets) and stopping to fire when appropriate (virtually all the rest of the time).

Tanks in CMBN seem to always move while firing. I don't recall ever seeing any of my AFVs stop to take a well aimed shot unless they were on Hunt. And then, of course, they stop but don't start moving again until you've given them fresh orders. So, even if the rate of hits is abstracted for this, it still throws off the game because armored vehicles don't stop as they should. I can't run my panzerfaust over to take out a sherman if the sherman never stops to fire. My AT gun can't get off a good shot from his covered position because the enemy tank is constantly on the move. Stuff like that. It changes the dynamics of the game and it just plain doesn't match reality, which is what most people playing a game like CMBN are looking for.

There was always a command where a tank could spot an enemy unit and stop to fire. The balance of the move order was always cancelled at that point though. In WW2 there should probably be no firing on the move since SOP for tanks at the time would be to halt, fire, then move again - ie, firing at the short halt which Steve mentioned. Apparently the part that is tricky is getting the tank to start again after firing from the halt without the intervention of the player through the plotting of additional orders. Think of firing from the short halt as a 'compound' order I guess because the move order would need to be cancelled for the tank to fire, and then reinstated once the tank resumed it's move. Until the issue of firing from the short halt is resolved tank gunnery while on the move will always be an imperfect representation of 'reality'.

[stoex]

[snipped] Apparently the part that is tricky is getting the tank to start again after firing from the halt without the intervention of the player through the plotting of additional orders. Think of firing from the short halt as a 'compound' order I guess because the move order would need to be cancelled for the tank to fire, and then reinstated once the tank resumed it's move. [snipped]

I guess that probably is the tricky part...although infantry do this just fine all the time - you know, stop to fire while moving, then continue on along their path. Regardless of the speed at which they are moving (except FAST). Seems it's possible, but obviously there is a difference between infantry and vehicles in this regard. Dunno, just 0.02 from central Europe in the middle of the night .