Infantry pathfinding - still a problem

[Guest Guest]

deleted per user request

[Scipio]

Of cause it is very difficult for us 'outsiders' to comprehend the natur of the problem. What, of course, doesn't keep me away to search a solution . Unfortunatly I have to catch a train in an hour, so I can't write out my brilliant theory...

Huntarr, I have no idea why you can't recreate the problem on your machine. Obviously I'm not alone with my experiences. Maybe it has even something to do with the CPU and small differences in a floating point-calculation caused by this. (I have an AMD dual core CPU)

Anyway, something I always wanted to ask and that is related to infantry movement: we spend some time in my military service (German Bundeswehr, early 1990') to train formations, such basic things like 'line' and 'column'. It doesn't looks to me like we have something like this in CMSF. Isn't this 'up to date' anymore - and would it have a positiv influence on the movement question?

[Dirtweasle]

Originally posted by Adam1:

I can see that. It would still be neat to have a preview of where they will end up while I'm spinning the "Face" command around, so at least I'll have some warning if the spots look crappy.

Yup.

I'll also add that if when you drop a waypoint and the process under the hood is going to move it over to the action point the user should get some feedback.

How you correct the milling about at waypoints, and/or when a team or part of a squad or whatever do the "jump the tracks" deals... beats me.

All I know as a user is it's a huge problem to carefully work through a game and all of a sudden WHAM-O!! even though you've done everything right the squad is tore all up.

It's one thing to have that happen when you make a mistake yourself or your opponent just does a better job, but having the game machine hose you just takes the wind right out of your sails.

I really hope you guys can figure out how to get this working better as soon as possible, it's really about the only "deal-breaker" issue left that I keep banging into.

[Battlefront.com]

Adam1,

I can see that. It would still be neat to have a preview of where they will end up while I'm spinning the "Face" command around, so at least I'll have some warning if the spots look crappy.

The problem with that is that the positioning is fully context sensitive. The guys may get there and adopt completely different positions because of some other factor coming into play, such as incoming enemy fire. Even if they do adopt those exact positions, they can change them based on conditions. Therefore, I don't see much value in coding up something that really isn't all that relevant.

Scipio,

Anyway, something I always wanted to ask and that is related to infantry movement: we spend some time in my military service (German Bundeswehr, early 1990') to train formations, such basic things like 'line' and 'column'. It doesn't looks to me like we have something like this in CMSF. Isn't this 'up to date' anymore - and would it have a positiv influence on the movement question?

Correct, you can not choose formation. That was a deliberate design decision based on how much micromanagement it requires the player to perform. We also are well aware of how frustrating the systems can be in terms of them being too ridged or too lax with carrying out the player's instructions. Therefore, we purposefully decided to not waste a huge amount of development time making something that probably few people would be happy with. We recently reviewed this as a possible change to the game system and we are still firmly of the opinion that it should not be.

Dirtweasel,

I really hope you guys can figure out how to get this working better as soon as possible, it's really about the only "deal-breaker" issue left that I keep banging into.

We are looking into how to round off some of the rough edges that are still there. I'm sure there are improvements and bug fixes that are quite possible to do that haven't been done yet.

However, nothing we ever do will be perfect. That includes implementing a very costly and cumbersome way for the player to set these parameters himself. Then we get complaints about the controls and the outcome instead of just the outcome

Steve

[Dirtweasle]

How about an elegant and efficient way for the player to be warned his waypoint plotting is going to change? :cool:

This would be especially helpful when the new path crosses terrain types. What I am saying is in the event the "new" path will cross or the waypoint will cause the squad / teams / team members to cross different terrain the player gts some feed back maybe?

Example - Let's say I order a unit to go SLOW (aka crawl) along a wall and then go QUICK between a gap or though a opening and HUNT into a building or somefink. *IF* the game engine adjusts the path *AND* the path now crosses new terrain (the wall for instance) or the outline of unit footprint will cross into new terrain *THEN* warn the player. The warning could be a brief blinking of the pathline indicator.

[Battlefront.com]

The only time a Waypoint is ignored, that I can think of, is when a vehicle is moving too fast. Direct pathing between Waypoints, however, are dependent on the terrain they cross. As the unit goes to execute its moves it must recalculate based on need. This was true for CMx1 as well.

The only way to display that information is to pre-compute the results and display a correction. This is something we've discussed internally and Charles feels the lag from this would be noticeable and therefore not good. CMx1 didn't have this either for the same reason.

Also note that the system never changes the Action Spot a Waypoint is in to an adjacent one. If you put a waypoint anywhere in 8x8 tile 32,45 that is where the unit will go (unless prevented to by enemy action, HUNT, or something like that, of course).

The problem that sometimes crops up is the player put the Waypoint on the edge, or corner, of an Action Spot and the soldiers spread out differently than anticipated. There are two ways to fix this:

1. Show the grid

2. Snap to grid when plotting Movement like when doing Area Fire.

We feel that neither are good ways to go because they kill immersion pretty badly. In fact, we are probably going to remove the snap to grid Area Fire behavior based on popular demand.

Steve

[Dirtweasle]

The problem that sometimes crops up is the player put the Waypoint on the edge, or corner, of an Action Spot and the soldiers spread out differently than anticipated.

This matches what I see going on. Thank you.

There are two ways to fix this:

1. Show the grid

2. Snap to grid when plotting Movement like when doing Area Fire.

We feel that neither are good ways to go because they kill immersion pretty badly.

Ah... probably so. Makes sense. What about not using the grid at all, or a much more granular grid, a plane where a single point might exist at I guess pixel level you might say?

Too computer intensive for RT? ...or maybe even WEGO?

[Dirtweasle]

...I know you hate to go back to comparisons to CMx1 Steve, but why was this not such a problem for that that series of games even when it used a larger coarser grid?

[Battlefront.com]

Dirtweasle,

...I know you hate to go back to comparisons to CMx1 Steve, but why was this not such a problem for that that series of games even when it used a larger coarser grid?

Actually, I LIKE to compare the two game systems together. It's the best way to get to understand the new one. What I don't like is when people point to something in CMx1 and completely disregard the context. Worse, when they point to something in CMx1 and it in fact it didn't do it. That makes things MORE difficult to understand, which isn't productive

The whole reason for Action Spots is because the terrain is extremely complex. CMx1's terrain was cut up into 20x20 tiles of homogenous (for the most part) terrain. The pieces that were not homogenous had only one modification present, such as a road or a wall. On top of that the underlying game mechanics of CMx1 are a lot "cruder" (in coding terms, that is) than CMx2's. This is even more true now with Enhanced LOS.

The problem with this system is that the more we allow soldiers to be spread out from a single Action Spot the more computing resources are required. When a Squad of 9 men moves it can occupy many Action Spots at once (in theory 9, though that probably can't happen), however by default it occupies 2 or perhaps 3. That means most of the time the number of Action Spots used is directly proportional to how many Teams/Vehicles are represented. That allows some room for expansion, such as some units being spread out while moving or firing at targets in different Action Spots.

If, on the other hand, the default was usually several times larger by default, then the system would get into more and more problems as units spread out during the course of movement and combat. Thus undermining the "cost" savings that the Action Spot system produces.

WeGo is not a work around for this. First, it would dramatically increase file size because the more Action Spots that are in use require more data to be saved. This could also run into RAM problems because in RT the information is pulled in and out dynamically whereas in WeGo it has to be saved in RAM (cumulatively) and then spat out to a file. PBEM would most likely be dead because of this, which would be a real blow to WeGo.

...I know you hate to go back to comparisons to CMx1 Steve, but why was this not such a problem for that that series of games even when it used a larger coarser grid?

Easy... because everything was so abstract. In CMx2 what you're seeing mentioned in this thread matters because the details exist and therefore the details matter. In CMx1 the details didn't exist therefore there was much less to be considered by either the player or the system.

To use a beer analogy... you don't see beer fanatics arguing over the details of a beer like Bud, Coors, or Miller. These beers are functional and that's about it. But when you start talking about extremely complex, beers there is a lot of debate there amongst people who really enjoy beer. Surely no beer connoisseur would argue that Bud is better than Duvel because Bud is easier to take for granted

So yeah... it's an apples to oranges thing. There's less going on in CMx1 so there is less to go wrong. There's a lot more going on in CMx2 so, by definition there is more that can go wrong. The trick is to not get too distracted by perceived shortcomings and instead appreciate the upsides because ALL games have shortcomings. A lot of people did not like CMBB, for example, because of the change to MG behavior or because it didn't have Shermans in it or now people didn't want to play them because they wanted to play QBs with Rarity on full. Did these improvements make CMBB a better or worse game? Depends on who you ask.

That's not to say that the CMx2 engine is perfect "as is". Nothing we ever do, or did, will ever be perfect. So by definition there is room for improvement. The pathing is something that we feel generally works great, especially given the extremely complex environment. Can it work better? Yes. Will it? I am sure it will.

Steve

[YankeeDog]

Originally posted by Battlefront.com:

[snip]

The problem that sometimes crops up is the player put the Waypoint on the edge, or corner, of an Action Spot and the soldiers spread out differently than anticipated. There are two ways to fix this:

1. Show the grid

2. Snap to grid when plotting Movement like when doing Area Fire.

We feel that neither are good ways to go because they kill immersion pretty badly. In fact, we are probably going to remove the snap to grid Area Fire behavior based on popular demand.

Steve

I agree that showing the entire action grid would be ugly and obtrusive. Having your waypoint plots snapping to the center of the nearest action spot would be functional, but also wierd.

But it doesn't need to be something this obtrusive. Why not do something like highlight the "action square" a final waypoint is in, not unlike the way setup zones and terrain objectives are currently highlighted? This would effectively tell the player, "With waypoint here, team will deploy over this terrain."

So a final waypoint would be a white circle, sitting in a little 8m x 8m subtlely "painted box" on the ground.

This way, players could see if the waypoint was right on the edge of an "action square", and therefore in danger of causing unexpected results, and adjust accordingly.

I don't think this would damage immersion much, if at all; it's not really more obtrusive than the current colored path rays and white waypoints. And of course, you could also make make it so that the "waypoint boxes" only show for the active unit and make it togglable with the "hide play aids" function.

You could use a similar logic for Area Fire; when you select a point on the ground to Area Fire, the Action Spot could be highlighted in red. This would give the player an idea of how the Area Fire will be distributed.

Cheers,

YD

[Dirtweasle]

A "show footprint" kind of thing YD? Interesting.

[YankeeDog]

Exactly. You could call it an "Endpoint Footprint" er sumfink like that.

I could be wrong, but I don't think this would take much of Charles' precious time away from other projects, since it's using something the game already does (highlight terrain to convey certain information), and it's not dependent on any subjective variables.

Should be a very simple subroutine. All the game has to do is determine which "Action Square" the final waypoint of the currently active unit is sitting in (something it presumably needs to know anyway, so the data is already stored somewhere), and then use the already-written highlight routine to highlight said square.

Cheers,

YD

[Battlefront.com]

YD,

It is a bit clunky because you don't know it's there until you plot, then if you delete the waypoint you lose the visual reference to it. But it is definitely better than showing the whole grid or having the snap-to concept. I've made a note of it

Personally, this has never bugged me. The problems I see most people having also won't be fixed by this either. But it does address one issue and perhaps it's one that needs to be addressed.

Steve

[Thomm]

This thread motivated me to make some quick tests.

Conclusion:

Individual teams perform more or less flawlessly in MOUT settings. That is a great foundation.

As soon as whole squads are moved, the likelihood of moves going terribly wrong increases to an extent that is alarming (see first post in this thread, I was able to create a similar situation without even trying to).

I hope that changes will be made to the current logic. The fact that teams perform so well makes me confident that the same can be achieved for squads.

The problem of squads splitting into teams which take individual, potentially non-optimal paths to the objective can perhaps be overcome by letting the second and third team follow the path of the first team with a time delay (like the assault order).

The problem of squads splitting up into teams at waypoints, thereby occupying more than one action spot, is another source of trouble in MOUT. What to do about this is a difficult question. Personally, I would keep them packed into one action spot, but I can see the problems with that. Assuming that the squad is ordered to move along a covered road, perhaps following teams should be allowed to use only action spots that were touched by the first team.

A last point for improvement would be the treatment of building edges and the ends of walls. I do not see behavior specific for this entities yet, such as peeking around corners, or wall ends. This would be another point that could lead to more realistic behavior. If you think about it, the corners of buildings are the most important entities regarding fighting in a built-up area, because the provide both cover and concealment. They sure deserve special treatment, akin to the special treatment that doors received, e.g.

Best regards,

Thomm

[Pandur]

In fact, we are probably going to remove the snap to grid Area Fire behavior based on popular demand.

i find it a good thing that area fire snaps to the grid.

area fire is powerfull enough already.

[Thomm]

Originally posted by YankeeDog:

Should be a very simple subroutine. All the game has to do is determine which "Action Square" the final waypoint of the currently active unit is sitting in (something it presumably needs to know anyway, so the data is already stored somewhere), and then use the already-written highlight routine to highlight said square.

That sure would be great, but would make sense only if all action spots that will be occupied by the squad at the final waypoint will be highlighted. Because many problems stem from the fact that large squads do not want to stay on just one action spot.

Best regards,

Thomm

[YankeeDog]

Thanks Steve,

As a postcript, you could make it an active feature, and actually have the "Endpoint Footprint" show as you move your cursor around the map whenever a movement order is selected. But I'm guessing this would be much more complex to program and get to look right, so I didn't include it in my original suggestion.

In any event, this would work best when combined with Adjustable Waypoints, which I believe you hinted are already on the schedule. Then, if the Endpoint is close to an Action Square edge, the player can simply adjust it a few meters one way or the other on the fly without re-plotting the whole thing.

This is on the level of "occasionally annoying" for me. Now that I've played the game for a while, I've figured out that the trick is to never plot an endpoint really close to a sudden change from "good cover," to "bad cover" -- you need to leave yourself a couple of meters margin of error.

A good example is a ridge crest -- if you plot your waypoint right on top of the crest (which is often the easiest point to click upon, especially if you're down in 2 or 3 view), sometimes part of the squad ends up hanging its @ss out completely over the crest, on the forward slope. This is obviously a bad thing.

I assume this is because the border between Action Square is right on the top of the crest, and the waypoint is sitting in the Action Square that is "Over the Crest," so the AI tries to fit the team into this terrain, rather than keeping to the fighting crest and defilade, as it should.

Now that I've adjusted my plotting behavior, it usually works fine. But sometimes it's hard to tell, or I just miss the detail in my rush to get on with the action. . .

Cheers,

YD

[Zwollo2003]

Originally posted by Battlefront.com:

The problem that sometimes crops up is the player put the Waypoint on the edge, or corner, of an Action Spot and the soldiers spread out differently than anticipated. There are two ways to fix this:

1. Show the grid

2. Snap to grid when plotting Movement like when doing Area Fire.

We feel that neither are good ways to go because they kill immersion pretty badly. .

Steve

I would strongly disagree. The awareness that placing a movement order on an invisible boundary between action spots might cause soldiers to behave strangely and be killed for no other reason kills immersion pretty much stone cold dead. Much more so than showing the grid to the players so that they can take it into account when plotting moves (in fact, some positively want to see gridded terrain and use mods to that effect).

I agree that movement snapping to grid is a bad idea, not due to immersion issues but because it restricts gameplay options far too much. However, if the only thing which will reliably kill the pathing bugs related to plotting moves on action spots' grid is showing that grid to players, I am all for it.

Zwolo

[Childress]

Grids are fugly.

[slug88]

I like the idea of snapping to grid.

(I seriously do.)

But YankeeDog's suggestion of dynmically painting the action spot is a really really really good one imho.

[ April 22, 2008, 03:45 PM: Message edited by: slug88 ]

[Battlefront.com]

Showing the grid or not showing it won't solve any problem other than accidentally plotting into an Action Spot you rather not move to. Those situations aren't very common IMHO, so the grid display itself may be a nice feature for reassuring people, but I don't think it will have much of an impact beyond that.

YD came up with a good tip:

This is on the level of "occasionally annoying" for me. Now that I've played the game for a while, I've figured out that the trick is to never plot an endpoint really close to a sudden change from "good cover," to "bad cover" -- you need to leave yourself a couple of meters margin of error.

This is quite useful and it's the way I've always played, which is perhaps why I don't seem to have much problem with my guys winding up in unexpected places. The more sparse the cover is the easier it is to make sure you get into it or move behind it or whatever. The more dense the terrain is the less you have to worry about getting things exactly right anyway.

Rollstoy,

Building edges and wall ends are already simulated in terms of the TacAI using them. Several improvements were made along the way, but I forget which patches. I'm sure it's still not perfect, but I wanted to say that the TacAI is aware of them and does try to utilize them correctly.

Steve

[slug88]

Yes, I've noticed that most of the time my men are pretty good at hugging walls and corners. I was pleasantly surprised to discover this a few patches ago.

Back to YD's suggestion, I think the ultimate system would be to dynamically highlight the action spot as one is setting the waypoint, and for squads that occupy several action spots, one would choose the connected action spots occupied by each team. I imagine something like holding down (rather than clicking) the LMB to set the 'primary' point for team 1, and then moving the mouse around to set the spot for team 2, with the order being applied upon letting go of the LMB. For squads with three teams, one would 'draw' a line starting from the primary point through three different action spots. I think this would help immensely to avoid a lot of the problems people face with infantry, without resorting to splitting teams. One-click ordering would still be available, by simply clicking to assign waypoints, rather than holding the button down.

[Battlefront.com]

We thought long and hard about allowing the Squad's Teams to be individually plotted. We decided not to go that route because it adds somewhere around 20-30% more "units" to manage. That doesn't seem to be good.

When a gamer sits down to play and finds shortcomings his first thought is "I need more control". Well, on a case by case basis this might be good. The problem is that cumulatively too much control kills the gameplay. We've all seen games like that.

The tricky part, for us, is to figure out where to allow the control and where to withhold it. It's an imperfect process and there are more opinions about how to do it "right" than there probably are gamers playing So we always keep an open mind, but generally we turn down suggestions to increase player control whenever possible.

I personally think that CMx2 is maxed out in terms of how much the player is being asked to do. This means I'm reluctant to give more control to people unless something else can be simplified. However, the optimal solution is not control at all but to have the TacAI, pathing, or other core game functions do the grunt work. So that's where we always look first for a solution.

NOTE - UI feedback is a form of "control" in that when it works right it gives the player the ability to have a better handle on what he's doing. That isn't the sort of thing I was just talking about, however. The above post is about more direct control, such as clicking on something that currently isn't clickable, or adding a new something or other that needs to be manipulated.

Steve

[YankeeDog]

Originally posted by Battlefront.com:

...

The tricky part, for us, is to figure out where to allow the control and where to withhold it. It's an imperfect process and there are more opinions about how to do it "right" than there probably are gamers playing So we always keep an open mind, but generally we turn down suggestions to increase player control whenever possible.

I personally think that CMx2 is maxed out in terms of how much the player is being asked to do. This means I'm reluctant to give more control to people unless something else can be simplified. However, the optimal solution is not control at all but to have the TacAI, pathing, or other core game functions do the grunt work. So that's where we always look first for a solution.

...

Steve

FWiW, I agree with this; if anything, I would prefer to need to issue less orders in CM, not more.

One thing I do think it might be worthwhile to explore is whether adding certain types of "stance" or "SOP" orders, similar to the TacOps stuff that lets you set what a unit will do upon contact, would actually lead to less burden on the player in the long run. For example, if I could set standing orders that a foward unit to pop smoke and retreat on contact, then I wouldn't have to micromanage it so much on contact.

IOW, I'm more than happy to trade having to issue a few extra orders during setup, and perhaps every 10-15 minutes or so during play, in exchange for not having to micromanage stuff so much in the minute-to-minute scale. The game already has some orders that do this very well; cover arcs are a good example. I think it could do with a few more.

Just something to think about.

Cheers,

YD

[Battlefront.com]

The problem with setting SOPs is that you can easily forget about them. So there you are with your assault force, getting in close with the enemy, then all of a sudden your lead attack element pops smoke and retreats. DOH! You forgot to change the SOP... BLAST! Now you're hosed

I do agree with you that we can possibly make some of the existing Commands "do more" intrinsically. This is also tricky, but I'd rather figure out how to work that stuff into existing stuff instead of creating new UI, new TacAI, new things for the player to remember.

CMBB introduce some improvements like this. Target Arc (Cover Arc), for example, was introduced to combine what people were already doing (issuing targets) with automated behavior. We could have gone and created a separate SOP system instead, but as now way back then we saw that as having more pitfall potential than likely benefit.

Steve