Change to the Interface

[Sergei]

Originally posted by Battlefront.com:

It is imperfect, that is true, but adding 2 waypoints to your example would add a couple of seconds, tops, to your command delay.

Obviously, you have NEVER played Combat Mission: Barbarossa to Berlin with early war Russian conscripts...

[aka_tom_w]

Originally posted by BDW:

What I would love to see is, during the plotting phase, a "suggested" path, which the AI suggests when I choose a unit and a destination, then I can tweak, delete and move the waypoints. So, it is still totally player controlled movement, but it would be really handy for certain situations, when you don't want to plot a bunch of waypoints (e.g. moving a vehicle down a curvy road).

Good idea

I thought the current way it works in CMAK was somewhat like that.

I have given ONE way point for a move order from one side of the map ALL the way across the OTHER side of the map (down the road around the bend across the bridge and through the woods) and then just let it go.

Then in the Next Move phase one minute later you get a WHOLE bunch of AI generated way points you can tweak without any command delay.

so

in turn one I set ONE way point, (one straight line across whatever terrritory I want) VERY little command delay

Turn two I then tweak the AI generated way points a bit and IIRC there is no further command delay, BUT you can't tweak the way points very far away from where they are.

This system works FINE for me

and it is somewhat akin to what BDW is suggesting, its just that his idea, saves you the first one minute crunch and turn to get to the AI generated path.

Sounds good to me

-tom w

[Battlefront.com]

Obviously, you have NEVER played Combat Mission: Barbarossa to Berlin with early war Russian conscripts...

Which probably still underestimates the amount of time it takes to get a unit to cross an open field with an obstacle in the way. so you're still probably getting that unit to move faster even with the extra two waypoints. So there

Actually, I would be curious to know how much time two waypoints would add using Dorosh's example. Anybody care to figure it out for the different experienced units?

Steve

[Sergei]

I did tests in CMBB and CMAK. In CMBB I used the dreaded early war Soviet conscripts, in CMAK I used British regulars. Both in and out of command.

The resulting extra delay for two waypoints:

Conscripts (BB) - in C. 18 secs. out of C. 45 secs.

Regulars (AK) - in C. 9 secs. out of C. 15 secs.

I would agree with Dorosh that it wouldn't really take 45 seconds from a bunch of men to figure out how to navigate around a simple obstacle. The delay for regulars is much more

[Michael Dorosh]

The initial orders would likely be "take your fireteam behind mine, 200 metres across the field; bear left around that swampy part and stay tight."

If the unit moved right at the end of the movement across the field, I can see a rationale for a command delay, something like (once they crossed the field)

"Is this where we bear right?"

"Is everyone across?"

"Should we move off now....?"

"Okay, we're all here, follow me..."

[yuvuphys]

I think we're (I'm) starting to confuse two different parts of tthe system. First, how do I tell the squad to move, and second, how does the squad execute that order?

I'm happy with how you tell a squad to move. No complaints about that. But how the squad executes that order presents a whole new set of questions when there's a 1:1 representation. What does it mean for that squad to "follow" that computed path? In CMX1 this was abstracted. There was really some dispersion of the men around the squad marker, inside a 10m radius or so. So, it becomes important to tell the "bulk" of the squad to go through this depression in the open field for a little more cover. However, with a 1:1 rep, each of the guys in my squad can devaite 8m from the movement path to take advantage of the depression in the ground, but still be within the abstracted squad of CMX1, all wihtout me explicitly telling them to use that depression in the ground.

That's the thrust of my concern. If I tell a squad to move across an open field using a single waypoint, is the entire squad in the 1:1 rep going to have the freedom and be intelligence enough to take advantage of a small depression in the ground several meters off the line I plotted?

It's still within the radius of the "abstracted" squad of CMX1, but it appears they are off the movement path plotted sinced they all took advantage of this depression slightly off the given movement order...they've in effect followed the spirit of my command, if not the letter.

[dalem]

Question:

Maybe this has already been answered, but I'm wondering if some of our flavor text issues might be solved by the 1:1 aspect?

What I mean is that currently we see a single "stand" of 3 guys humping along and they take off as one unit and arrive instantaneously.

ASSUMPTION ALERT

Maybe if we see 10 guys get up and move out after we give the order, the graphic of them getting into formation, moving, then deploying when they reach their endpoint will make it look more realistic and less perfect, even if under the hood the same exact thing is happening as we currently have it.

Maybe this could be one of the intangible benefits Steve is talking about when he slaps old gamer fogies like me around as regards 1:1 graphical representation.

-dale

[Battlefront.com]

I would agree with Dorosh that it wouldn't really take 45 seconds from a bunch of men to figure out how to navigate around a simple obstacle.

ARGH... it is as if people aren't listening!

I don't know how many times I have to say this before you guys will grasp the simple concept. We KNOW the current system is not perfect, but nobody has yet come up with an alternative. Currently the delay is based on the quality of the unit, its ties to higher authorities, and how complex the path is (weighted unevenly the more waypoints that are added). This is intended to simulate the difficulty of coordination for particular units to do things. Because we, and nobody else, can come up with a better idea these concepts are tied to waypoints.

So no, I don't think it is realistic for a bunch of conscripts to take 45 seconds ahead of time to figure out how to get around an obstacle. I find it unrealistic that it they can get moving at all in 45 seconds, not to mention where they go and what they avoid in the process. If CMx1 were simulated like the real world it might take a good 5 minutes to get that unit to move at all. Period. Could be 20 minutes. Maybe an hour and a half. The problem is we can't really tell which because the über commander, the Human Player, has minute control over everything. Including being able to plot an exact plotted path in terrain that should be unknown with far too much situational awareness of friendly and enemy dispositions.

That means the player is all things all the time and therefore we can't determine which moves are "tactical" and which ones are "operational". We also have to keep in mind that even the hardestcore Grognards here wouldn't like it if we simulated the real pace of a battle. There is a reason most firefights lasted a half hour and didn't result in much of anything happening.

I will say again... for those of you who are asking that waypoints not be used for command delays, what would you put in instead? Nothing is not an option since it would make the game far less realistic than it is now. We've had this discussion dozens of times and the complainers have YET to come up with a better solution. We haven't either. Well, not one that is simple to implement (see earlier comments about CMx2 designs that will eventually come to be).

Steve

[dalem]

Originally posted by Battlefront.com:

If CMx1 were simulated like the real world it might take a good 5 minutes to get that unit to move at all. Period. Could be 20 minutes. Maybe an hour and a half.

Mmmm, you've just described "Combat Mission: Only Dale Wants to Play It"

-dale

[Wicky]

This thread reminds me off this piece whipped from a review of a new book 'The Utility of Force', by General Sir Rupert Smith:

Legend has it that the master tactician, Sun Tzu, once demonstrated his powers of military brilliance by training a group of concubines in the arts of war, His aim was to impress a king who doupted his skill, But the concubines fell about laughing.

"If words of command are not clear and distinct," said Sun Tzu to the king, "if orders are not thoroughly understood, then the general is to blame." When he began drilling them again, and the the girls laughed again, Sun Tzu said: "If words of command are not clear and distinct, if orders are not thoroughly understood, the general is to blame. But if his orders are clear, and the soldiers neverless disobey, then it is the fault of the officers." Whereupon he had the two leading concubines beheaded and won the generalship of the kingdoms armies.

[Sergei]

Oh sheesh, Steve, sometimes I feel like you're not even reading what I post.

Originally posted by Battlefront.com:

I find it unrealistic that it they can get moving at all in 45 seconds

But they don't. The first move takes 65 minutes; three moves together take 110 seconds, just 10 seconds short of 2 minutes.

[Philippe]

What follows is probably not a good idea, and is only offered in the hope that it might suggest a more useful one to someone else.

Add a "navigate obstacle" toggle command.

You need to move down a road and cross a three hundred yard open field and to a specific point at the far end of it. In the middle of the field is a forty yard-long stretch of barbed wire perpendicular to your movement path.

You set the first waypoint directly in front of the wire. You click on the navigate obstacle command and click on an obstacle close to where your last waypoint was. Activating the command creates a small radius around a designated obstacle (and it has to be a real obstacle or the command won't kick in). Inside that small radius any waypoints you set won't cost you anything in terms of delay. The radius has to be small to prevent abuse. If the obstacle is big you have to issue several navigate obstacle commands.

This would probably get you around small barbed wire obstacles and through garden gates without burning up too much time from extra waypoints. It's probably a bear to program, and it doesn't solve the winding gully problem.

[Sergei]

Originally posted by Battlefront.com:

I will say again... for those of you who are asking that waypoints not be used for command delays, what would you put in instead? Nothing is not an option since it would make the game far less realistic than it is now. We've had this discussion dozens of times and the complainers have YET to come up with a better solution. We haven't either. Well, not one that is simple to implement (see earlier comments about CMx2 designs that will eventually come to be).

Steve

Well, for instance, if the order to move five meters to left and six meters forward wasn't treated with the same delays as orders to move five hundred meters to left and six hundred meters forward, I think it would be a start.

[Michael Dorosh]

Originally posted by Philippe:

What follows is probably not a good idea, and is only offered in the hope that it might suggest a more useful one to someone else.

Add a "navigate obstacle" toggle command.

Go back a page, Braniac.

http://www.battlefront.com/discuss/ultimatebb.php?ubb=get_topic;f=52;t=000247;p=4

There's even pictures.

[Philippe]

Mediocre minds think alike.

[Michael Dorosh]

Originally posted by Philippe:

Mediocre minds think alike.

Or plagiarize something someone less mediocre said the day before.

[Vanir Ausf B]

Originally posted by Battlefront.com:

That means the player is all things all the time and therefore we can't determine which moves are "tactical" and which ones are "operational".

This is really the crux of the issue. If we can't find a practical system that tailors the delay for what is most appropriate for each situation, the logical choice is to choose the system that is the most realistic the majority of the time.

When the current system of adding more delay for more waypoints was introduced in CMBB it was because it was thought there had to be a way of simulating the diffculty of using complex commands with early war Soviet conscripts. It succeeded in doing this. Unfortunately in making those situations more realistic it made others less realitic. Was it a net gain or net loss?

At the heart of the problem is the implied assumption that more waypoints = more complex orders. I think we all agree this is often not the case. As others have already alluded to, a complex order in CM would tend to be characterized by both many movement points AND long distance. Many movement points clustered into short movement orders would tend to be of the type Dorosh keeps talking about. Which is most often the case? In my personal experience it is the latter. It could just be my own play style, but longish movement orders become unusual after contact with the enemy is made and if large numbers of movement points are used they are bunched together around an obstacle.

In my opinion rolling back to the CMBO system would be more realistic most of the time. It's not ideal by any means, but I feel that adding delay to waypoints was a case of the cure being worse than the disease.

[Andreas]

Originally posted by Vanir Ausf B:

In my opinion rolling back to the CMBO system would be more realistic most of the time. It's not ideal by any means, but I feel that adding delay to waypoints was a case of the cure being worse than the disease.

I don't agree. I think Sergei is by and large right, i.e. overall movement distance should be valued higher than it is at the moment in terms of delay. Abandoning delays for complexity completely is the wrong direction (excuse the pun) to take.

I would however like to understand a bit more about how squads/platoons/companies move in various situations before I accept the reasoning that short movements in the presence of the enemy are less complex to execute than long movements in the absence of the enemy. I would e.g. think that moving around an obstacle is very easy in a safe situation, but if enemy presence is suspected, it is very complicated, because you have to assume the enemy has the obstacle covered somehow - check for mines, closely observe potential ambush locations, send a scout forward to see if a machine-gun is trained on the 'easy' path around the obstacle. All these things cost time, and we have to assume they are currently abstracted into the movement somewhat.

[Michael Dorosh]

I have no problem with the command delays, and understand no system will be perfect. I just don't want my guys walking along stupidly inside a hedge at a 5 degree angle to it or whatever. 1:1 will present some interesting problems; will be anxious to see the screenshots in that magazine.

Plotting movement orders for one unit is not a biggie; plotting for a company can get to be tedious, but then, why complain about controlling your own troops I guess. *shrugs*

But yeah, lose the delays associated with obstacle avoidance and I think you've got a perfectly fine system.

[aka_tom_w]

I like this part:

" The difference is that CMx2 solves some of the major reasons for the TacAI's plotting issues found in CMx1. Road behavior first and foremost. So with or without a runtime path calculation feature many of the CMx1 problems won't be found in CMx2."

-Steve

[ September 30, 2005, 03:01 PM: Message edited by: aka_tom_w ]

[Vanir Ausf B]

Originally posted by Andreas:

I would however like to understand a bit more about how squads/platoons/companies move in various situations before I accept the reasoning that short movements in the presence of the enemy are less complex to execute than long movements in the absence of the enemy.

In comparing complexity of long and short movement I did not specify whether it was in the presence of the enemy or not so I'm not sure where you got that. To keep it apples to apples both would be one or the other, and in that case I think we can agree short is generally less complex than long?

I would e.g. think that moving around an obstacle is very easy in a safe situation, but if enemy presence is suspected, it is very complicated, because you have to assume the enemy has the obstacle covered somehow - check for mines, closely observe potential ambush locations, send a scout forward to see if a machine-gun is trained on the 'easy' path around the obstacle. All these things cost time, and we have to assume they are currently abstracted into the movement somewhat.

Sure, but those actions are not specific to moving around something. I would suspect most if not all of that would be in order when moving during a battle regardless of whether you're going around, through, over or just moving in a straight line from one position to the next.

Does CMAK add delay for movement length? I don't recall CMBB doing that. If CMx2 could be made to do so, and if the number of way points were penalized proportionally less severely, that could work too. I'd be willing to try it.

[Andreas]

Originally posted by Vanir Ausf B:

In comparing complexity of long and short movement I did not specify whether it was in the presence of the enemy or not so I'm not sure where you got that.

Here:

Originally posted by Vanir Ausf B:

It could just be my own play style, but longish movement orders become unusual after contact with the enemy is made and if large numbers of movement points are used they are bunched together around an obstacle.

[Sergei]

I think I should repeat this entire post!

In particular, because I don't agree with the bit here:

"this entire post probably bears repeating!"

I don't think that the entire post needed to be repeated. We read it already. So, please, somebody - shoot me (and Tom)! :mad:

Originally posted by aka_tom_w:

this entire post probably bears repeating!

I like this part:

" The difference is that CMx2 solves some of the major reasons for the TacAI's plotting issues found in CMx1. Road behavior first and foremost. So with or without a runtime path calculation feature many of the CMx1 problems won't be found in CMx2."

-Steve

</font><blockquote>quote:</font><hr />Originally posted by Battlefront.com:

Bruce70, you have a good point. The system you are proposing, however, is still inherently one way or the other. The difference is your idea allows the player to "intercept" undesirable ramifications of the AI's thinking and, if so desired, spend time undoing them. This is something that we've thought of, however there is a practical problem with this, though not necessarily a terrible one.

Currently CMx1 is set up to follow a "player path" as its primary directive. That means the player's waypoints are followed unless there is a blockage (that is the only terrain based reason). Let us say we have a "runtime" calcualted best path. If we keep with this philosophy for CMx2 then the outcome will look identical to the way it is in CMx1. To use Dorosh's example of the barbed wire, the squad would show it's path going through the wire instead of around it. Therefore, Bruce70's suggestion has no effect.

If we instead change the system so that the player's orders are altered as the AI sees fit, then using a "runtime" system might produce radically different results. Using Dorosh's example, the unit would not have a plotted path through the wire but instead around it. If the player really wanted to go through it then he'd have to move and delete some waypoints.

The potential problem here is that the player might not like the AI's take on things frequently enough to cause frustration. He might find himself replotting more moves than he cares to, and instead long for the existing system where you plot and the TacAI doesn't get involved unless there is a blockage. It is tough to say if this would become a real problem, but having played some games like this in the past I think it is reasonably possible.

Now, I know some of you guys are going to tell me that they spend tons of time undoing TacAI plotted paths already and there for what's the difference? The difference is that CMx2 solves some of the major reasons for the TacAI's plotting issues found in CMx1. Road behavior first and foremost. So with or without a runtime path calculation feature many of the CMx1 problems won't be found in CMx2.

I don't think it would be too hard to put such a feature in for testing. So who knows. In fact, Charles might have already thought of this. I wouldn't know because we haven't talked about it

Steve

</font>

[Michael Dorosh]

I have to agree with Sergei that this post shouldn't have been repeated!

Originally posted by Sergei:

I think I should repeat this entire post!

In particular, because I don't agree with the bit here:

"this entire post probably bears repeating!"

I don't think that the entire post needed to be repeated. We read it already. So, please, somebody - shoot me (and Tom)! :mad:

</font><blockquote>quote:</font><hr />Originally posted by aka_tom_w:

this entire post probably bears repeating!

I like this part:

" The difference is that CMx2 solves some of the major reasons for the TacAI's plotting issues found in CMx1. Road behavior first and foremost. So with or without a runtime path calculation feature many of the CMx1 problems won't be found in CMx2."

-Steve

</font><blockquote>quote:</font><hr />Originally posted by Battlefront.com:

Bruce70, you have a good point. The system you are proposing, however, is still inherently one way or the other. The difference is your idea allows the player to "intercept" undesirable ramifications of the AI's thinking and, if so desired, spend time undoing them. This is something that we've thought of, however there is a practical problem with this, though not necessarily a terrible one.

Currently CMx1 is set up to follow a "player path" as its primary directive. That means the player's waypoints are followed unless there is a blockage (that is the only terrain based reason). Let us say we have a "runtime" calcualted best path. If we keep with this philosophy for CMx2 then the outcome will look identical to the way it is in CMx1. To use Dorosh's example of the barbed wire, the squad would show it's path going through the wire instead of around it. Therefore, Bruce70's suggestion has no effect.

If we instead change the system so that the player's orders are altered as the AI sees fit, then using a "runtime" system might produce radically different results. Using Dorosh's example, the unit would not have a plotted path through the wire but instead around it. If the player really wanted to go through it then he'd have to move and delete some waypoints.

The potential problem here is that the player might not like the AI's take on things frequently enough to cause frustration. He might find himself replotting more moves than he cares to, and instead long for the existing system where you plot and the TacAI doesn't get involved unless there is a blockage. It is tough to say if this would become a real problem, but having played some games like this in the past I think it is reasonably possible.

Now, I know some of you guys are going to tell me that they spend tons of time undoing TacAI plotted paths already and there for what's the difference? The difference is that CMx2 solves some of the major reasons for the TacAI's plotting issues found in CMx1. Road behavior first and foremost. So with or without a runtime path calculation feature many of the CMx1 problems won't be found in CMx2.

I don't think it would be too hard to put such a feature in for testing. So who knows. In fact, Charles might have already thought of this. I wouldn't know because we haven't talked about it

Steve

</font>

[flamingknives]

Step away from the quote tags or I will TASE you!