Jump to content

Dissapointed by CMBN


Recommended Posts

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

As has been stated already, they stopped but not to fire a couple of shots and then continue moving. If you remember your tanks doing that in CMx1 then you definitely are hallucinating :D

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.

Incorrect. Like CMx1 if you use HUNT the tank will stop and engage.

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.

Correct, except that it didn't happen in CMx1 as you're imagining it did.

The primary problem with the version you guys are playing is the accuracy is too good. That was easily fixed a few weeks ago. You will see it in v1.01 soon.

Stoex,

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.

Yes, there's a huge difference. Infantry move in a way that some guys are naturally stationary while others move. This is especially true when using Squads where large numbers can be stationary at any given time. Therefore, the TacAI and AI Player don't need to "think" about when to stop the unit so it can fire. Which, if you think about it, is a problem sometimes.

Think about when an infantry unit engages something while on the move. Do these situations significantly alter its movement behavior if it isn't Suppressed? No, the unit keeps on task. This is, in a sense, equal to a vehicle's firing on the move behavior. The difference is there is only one component of a vehicle (i.e. the crew always move and stop as a whole unit) and that means it either stops to engage OR it keeps on moving. It has no ability to stop and engage then continue moving.

We've looked into hacking "firing at short halts" into CM:BN and the results were not good. It's going to require new Commands and significant TacAI programming. Even more time consuming is programming the AI Player to know how to use the behavior.

Steve

Link to comment
Share on other sites

  • Replies 303
  • Created
  • Last Reply

Top Posters In This Topic

Interesting enough thread - there is deffinitely room for improvement on commands. maybe there could be an alternate menu that sets up certain behaviors like the infantry shooting at tanks - maybe you could turn this off. i know in one of the other BF games, and I can't remember which one off hand (it's late), but you could set engagement ranges and behaviors when certain situations were encountered. As it stands CMBN is really cool - i love the cherry picking and hope to see this in CMSF at some point. As far as the way tanks behave without any altering to the code, maybe plotting multiple short paths with pause commands might help mitage this>?

Link to comment
Share on other sites

Yeah, there's probably another 50 years worth of stuff to put into CM. Kinda nice to have job security like that, though on the other hand it is depressing when even we want about 50 years worth of stuff right now. Just not going to happen.

There are manual ways to approximate firing at short halts in the game now, but it's rote (i.e. not context sensitive) and involves a lot of micromanagement. We definitely need, and intend to implement, a better solution with the next major release. This is too big a feature change for a free patch.

Steve

Link to comment
Share on other sites

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

Yes, you have the issue of a huge investment in legacy code. It is rare when that is not the case.

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.

Sounds good. I will contact you on what I've learned about multi-core engines after the new patch comes out. You guys are probably memory-mapping data files already, since you are so performance focused. If not, I can send you my crude but reasonably documented Win32 memory-mapping wrapper classes for file memory mapping and inter-process memory sharing.

You can find something similar in the boost interprocess library, but the boost interface offers a limited exposure of the API.

http://www.boost.org/doc/libs/1_35_0/doc/html/boost/interprocess/shared_memory_object.html

Link to comment
Share on other sites

We've looked into hacking "firing at short halts" into CM:BN and the results were not good.

I think you should persist. If problems arise from your initial hack, then you do more hacks to fix those problems, and so on. Eventually the 'problem-hack-problem' cycle will either settle into a steady state or spin wildly out of control and compromise your entire codebase. No doubt it has something to do with Chaos Theory.

I reckon its worth a shot to fix the problem ;)

Link to comment
Share on other sites

As has been stated already, they stopped but not to fire a couple of shots and then continue moving. If you remember your tanks doing that in CMx1 then you definitely are hallucinating :D
Perhaps it's been too long since you played CMx1, Steve. Tanks most definitely do stop, take a shot or two, then keep moving.

Incorrect. Like CMx1 if you use HUNT the tank will stop and engage.
When using the Hunt command in CMBB tanks will stop, engage the threat, then continue moving once the threat is neutralized. When using the Hunt command in CMBN tanks will stop, engage the threat, then do nothing until the next orders phase. VERY different behavior.

Correct, except that it didn't happen in CMx1 as you're imagining it did.
Again, perhaps it's been a while since you played CMx1. It's a bit strange to have to explain how the game works to one of the people who designed it, but you are incorrect, Steve. Here's a screenshot from a test I *JUST* ran in CMBB 1.03:

CMBB_Hunt.jpg

I had Shermans positioned behind each clump of trees and one Tiger. The Tiger started at the far South end of the map and I gave exactly ONE order. On the very first turn I ordered the Tiger to Hunt directly North. The Tiger would proceed north until a Sherman came into view, stop (yellow circles) and fire once or twice to kill the enemy unit, then continue. Generally only one shot was needed, at which point it would continue on its way. Sometimes the first shot was a miss or didn't kill the target, so a second shot was necessary. But in either case the Tiger most definitely DID stop, take 1 or 2 shots, then continue with the orders it had been given!

Doing this exact same thing in CMBN would require either a fresh Hunt order each and every turn (and probably several more turns to go the same distance, since half of each turn would be spent sitting there doing nothing) or a Slow/Normal/Quick order, in which case the Tiger won't stop and aim his shots. So, you basically have the choice of moving and having poor shooting ability (and a drastic change to how the game worked from before) or stopping to get better shots, but constantly having to issue new orders and moving much more slowly because the vehicle doesn't continue on once the threat is neutralized.

I'm struggling to see how you can possibly think these two behaviors are the same.

Link to comment
Share on other sites

Agreed, the old HUNT command was more useful. It is annoying in CMBN to constantly have to go round checking all units that were using hunt, got a brief LOS to an enemy unit and then stopped, especially in WEGO where they may be wasting almost an entire turn with no new orders.

Link to comment
Share on other sites

Yes, you have the issue of a huge investment in legacy code. It is rare when that is not the case.

True, but that's not what I meant - that *is* a big consideration, but honestly the interplay of moving parts in a 3D game is... different. The OS, video card drivers, and hardware all have their own ideas. It gets worse when you're looking at it practically, with potentially thousands of different hardware / software combinations interacting, but even leaving that aside it gets thorny, especially when you are trying to support systems that are more than a few years old.

This isn't a straight code problem in any way. It's... something entirely other. It's a bit like herding cats as opposed to herding friendly dogs that have been trained to follow you around. The latter is... sane. :)

Sounds good. I will contact you on what I've learned about multi-core engines after the new patch comes out. You guys are probably memory-mapping data files already, since you are so performance focused. If not, I can send you my crude but reasonably documented Win32 memory-mapping wrapper classes for file memory mapping and inter-process memory sharing.

You can find something similar in the boost interprocess library, but the boost interface offers a limited exposure of the API.

http://www.boost.org/doc/libs/1_35_0/doc/html/boost/interprocess/shared_memory_object.html

Thanks. I've been using boost for a long time. I haven't looked at interprocess, though.

I can't comment on what precisely we use and don't use, but I can say if there are fast ways of doing things we're probably doing them that way. :)

Link to comment
Share on other sites

I'm struggling to see how you can possibly think these two behaviors are the same.

Clark, you do not understand what Steve was trying to explain.

In CMx1 "Hunt" a AFV will stop when it spots an enemy target and will engage that target until it is dead and will then move on. That behavior is not necessarily optimal if your AFV decides to stop in the kill zone of enemy AT assets.

The behavior Steve is referring to is similar to the behavior of infantry with a "Quick" order. If your infantry spots an enemy unit, it will stop, take a quick shot and move on to complete it's movement order.

Similarly, a AFV which is given a "fast", "quick" and/or "move" order should stop when it spots an enemy target, take a quick shot to suppress it and move on to complete its movement order. That is what is a "short halt". Right now, in both CMx1 and CMx2, the AFV will fire while it continues moving.

Link to comment
Share on other sites

Clark, you do not understand what Steve was trying to explain.

........ AFV which is given a "fast", "quick" and/or "move" order should stop when it spots an enemy target, take a quick shot to suppress it and move on to complete its movement order. That is what is a "short halt". Right now, in both CMx1 and CMx2, the AFV will fire while it continues moving.

Bold = mine: EDIT: Apologies, post deleted as Sgt Joch beat me to it in clarifying what Steve said, as that is how I understood it too, as explained by the Sarge.

I personally would love the old HUNT order (for AFV's versus AFV's) to be implemented again for the CMx2 engine in a WWII setting, if possible. BFC is on record that they will look at HUNT, as a movement order we're all familiar with due to the CMx1 trilogy, together with a major UI overhaul at the next family of releases.

Link to comment
Share on other sites

So if my Sherman is trying to cross a narrow gap in the LOS of a Panther and I give it a FAST order, it shouldn't just move at maximum speed across the gap, but instead stop in the gap, take a shot at the Panther, and then move on?

Like infantry, they type of movement order should affect their willingness to stop.

Link to comment
Share on other sites

In CMx1 "Hunt" a AFV will stop when it spots an enemy target and will engage that target until it is dead and will then move on. That behavior is not necessarily optimal if your AFV decides to stop in the kill zone of enemy AT assets.
Thankfully, CMx1 gave you the Move and Fast Move commands, if you want to keep your armor moving and prevent it from stopping. Also, since Hunt (in CMx1) engages when it sees a target, the only way you're going to stop in a kill zone is if your unit doesn't see the enemy units that are targeting it (if it did see them, it would have stopped and engaged before it got surrounded) or if your opponent is able to converge multiple units against your single unit simultaneously (in which case you're probably screwed no matter what).

In CMx2 this problem is made worse, because your only options are 1) keep moving, possibly going deeper into the enemy's trap, firing while moving (giving you poor chances of hitting), or 2) stop as soon as you encounter the first unit, then sit there for the rest of the turn, making yourself a sitting duck.

Similarly, a AFV which is given a "fast", "quick" and/or "move" order should stop when it spots an enemy target, take a quick shot to suppress it and move on to complete its movement order. That is what is a "short halt". Right now, in both CMx1 and CMx2, the AFV will fire while it continues moving.

In CMx1 you had the option of a "short halt" with the Hunt command. In CMx2 you do not have the option at all. The Hunt command in CMx2 isn't a "short halt", it's "stop and don't move again until you receive new orders".

Link to comment
Share on other sites

Hunt in CMBN seems more akin to the old "move to contact" command (a great command, btw). I don't think the unit necessarily has to spot an enemy unit to halt as it seems it will halt when it perceives a threat such as being fired upon, regardless of contact.

Link to comment
Share on other sites

In CMx2 this problem is made worse, because your only options are 1) keep moving, possibly going deeper into the enemy's trap, firing while moving (giving you poor chances of hitting), or 2) stop as soon as you encounter the first unit, then sit there for the rest of the turn, making yourself a sitting duck.

Not necessarily, however BFC would have to comment on the details of this as I have only observed the behavior- The TAC AI will also react regardless of your orders so on it's own initiative it may retreat from a threat. It isn't the same as issuing a specific order and expecting a planned response, however it can be considered as an option in planning your movement to some degree. I realize that isn't what you are looking for from an orders perspective, but at the same time it isn't quite true the unit will simply sit there and do nothing if it is facing a significant threat.

Link to comment
Share on other sites

Wouldn't it be nice if behaviour and movement could be controlled separatly?

Move: Slow, Normal, Fast, Run

Behaviour: disengage on contact, engage&stop on contact, shoot&move, just get there

I think that would cover all current options plus some more.

Disadvantage: 1 or 2 clicks instead of always 1 click.

Link to comment
Share on other sites

ketonur, take a break from this fanboy forum and new CM series - try the Achtung Panzer, especially the russian Achtung Panzer Operation Star with newest patches (if you manage to obtain it) - it's a CM killer!

Billy Goat Gruff better watch out.

Link to comment
Share on other sites

ketonur, take a break from this fanboy forum and new CM series - try the Achtung Panzer, especially the russian Achtung Panzer Operation Star with newest patches (if you manage to obtain it) - it's a CM killer!

And if you believe that I have some shares in a bridge that made a recent starring apprearance in a Peng thread for ya! You can see how much of an impression it has made on this guy as he is still wandering around aimlessly in the CM forums trying to pitch it.

Link to comment
Share on other sites

ketonur, take a break from this fanboy forum and new CM series - try the Achtung Panzer, especially the russian Achtung Panzer Operation Star with newest patches (if you manage to obtain it) - it's a CM killer!
We wish all other war genre games well, and financial success too. Alas, I also have heard over the years a lot about punted products purporting to be iPhone & iPad killers. And I have a BlackBerry phone. ;)
Link to comment
Share on other sites

True, but that's not what I meant - that *is* a big consideration, but honestly the interplay of moving parts in a 3D game is... different. The OS, video card drivers, and hardware all have their own ideas. It gets worse when you're looking at it practically, with potentially thousands of different hardware / software combinations interacting, but even leaving that aside it gets thorny, especially when you are trying to support systems that are more than a few years old.

This isn't a straight code problem in any way. It's... something entirely other. It's a bit like herding cats as opposed to herding friendly dogs that have been trained to follow you around. The latter is... sane. :)

Yes, but hopefully all your platform-specific stuff is wrapped in an application layer? Shouldn't it be abstracted away by the time you get to the game logic?

Thanks. I've been using boost for a long time. I haven't looked at interprocess, though.

I can't comment on what precisely we use and don't use, but I can say if there are fast ways of doing things we're probably doing them that way. :)

For multi-core processing, the critical difference (in my mind, anyway) between multi-thread and multi-process is how data is shared. In multi-thread, everything is shared unless you specifically put it in thread-local-storage (TLS) or on the thread's stack. In multi-process, nothing is shared, not even code, unless you specifically create shared memory between your processes.

Although the multi-thread community claims the "share-everything" approach is a feature, some (including myself) see it as highly error-prone, unnecessarily complex, and inefficient for real-world applications.

Multi-process is more object-oriented: each process(core) can be designed as an object with well defined interfaces to the other processes. Because data sharing is very controlled, there is much less need for critical sections, semaphores, and other synchronization overhead. In the neural network engine I described earlier, I used a shared block with an empty/full flag as the base primitive of each inter-process interface. Synchronization doesn't get much simpler than that.

With any multi-core application, you sometimes need to pay attention to coordinating local cache with main memory. The Intel cache intrinsics are handy for this.

Link to comment
Share on other sites

Wouldn't it be nice if behaviour and movement could be controlled separatly?

Move: Slow, Normal, Fast, Run

Behaviour: disengage on contact, engage&stop on contact, shoot&move, just get there

I think that would cover all current options plus some more.

Disadvantage: 1 or 2 clicks instead of always 1 click.

It would be nice, but I personally think it's unnecessary. We don't really need extra-fine control of speeds of AFVs, since you're basically only going three speeds (slow to stay with infantry, "normal" speed to get where you're going, and "get there NOW!"). If you're moving quickly, you probably aren't expecting there to be enemies in the vicinity or there are enemies in the vicinity and you want to get away from them. So, you probably only need to stop and engage when you're already moving fairly slowly. I think most people would be happy with tanks stopping to engage at one or two speeds (say, Hunt and Normal) and firing on the move at other speeds. Assuming this sort of change could be done to the guts of CMBN it would probably make most people happy, would allow much finer control of units, would alleviate the "fire on the move" issues, and wouldn't require any UI changes.
Link to comment
Share on other sites

Guest
This topic is now closed to further replies.

×
×
  • Create New...