Map editing for AI path-finding problems.

[alpaca]

Haha keep up the good work (and if possible throw a few good links into the round so I can suss them in)

[nikolai1962]

Haha keep up the good work (and if possible throw a few good links into the round so I can suss them in)

These were my starting points

http://www-cs-students.stanford.edu/...rog.html#paths

http://www.gameai.com/pathfinding.html

trying to delve into specifics now.

~~~

Thought collection

opinion.

The strategic AI can never be a challenge without either much better pathing or giving the AI very large amounts of money. If you don't like fighting the same battle over and over with multi-stacks of AI armies then you need better pathing. Hence my problem.


observations from AI-watching and map-editing with rtw and mtw2

1. moving region boundaries can change the pathing

2. moving region boundaries, even if the changes are completly within a block of impassable terrain, can effect the pathing.

3. areas of a region that are unreachable from the rest of the region can effect pathing.

4. sometimes the game doesn't seem recognize an adjacent region as adjacent (clue is when the AI will land an army by ship from an adjacent region)

5. the AI seems to move across long distances fine but has problems when it gets close but still further than one turn away.

6. sometimes an AI stack will move to a region and stall on the edge of, or the first tile of the final region.

7. changing something on the map in one area can effect the pathing in a completely different area.

8. On a complex map the AI will often (but not always) stall when moving from region A to region B if the path clips across a region C that is mutually adjacent to both A and B via passable terrain. Doesn't seem to happen at all on my simplified map.

9. the AI has a preference for attacking cities from the south-west.

10. changing movement potential effects the pathing, either via adding movement points or by effectively decreasing movement by adding more difficult terrain to the map.

11. orthogonality matters somehow

12. In rtw an AI would often have problems when they were close to their target in a straight line but an obstacle made their actual path take them further away. seems very rare in mtw2

13. Pathing problems seem to only happen to stacks with a city target. (Possibly i don't notice other times.)

14. AI supporting armies often seem to be happy to get within (roughly) two tiles from the city itself.

15. sometimes a stack will be given a target and not move at all. this is most noticeable at game start.

16. an AI army will often stall after a battle, especially after a retreat from a siege assault. this happens a lot less on a simplified map. it seems to only effect stacks that have a city target. it seems at least partially related to pathing.

17. an AI army will sometimes move only one tile. happened a lot in rtw, especially over fords. can happen at other times. haven't noticed it so much in mtw2

18. There are potentially many hundreds of AIs that need to have their path calculated in the AI turn.

19. Most importantly, the pathfinding code itself works perfectly. When a player selects a unit to move and right clicks on the map the game displays the movement arrow of least movement cost and that's where the stack goes. It never goes wrong in any circumstances. When you select a unit the green overlay shows all the movement paths. It never goes wrong.

~~~

AI pathfinding stuff from Google.

1. There are algorithms that will always return a best path on a map like MTW2 or RTW.

2. These algorithms are computationally expensive.

3. Games have to use multiple pathfinding mechanisms to tweak the computational cost.

4. One tweak is to weaken what is called the heuristic of the algorithm so it doesn't look for the best path, just a close path.

5. Another is to artifially tweak the movement costs of tiles so the algorithm spends less time looking for the best path.

6. A third tweak involves how you treat diagonal moves. calculating the square root of the dx,dy squared being the most expensive and therefore least used for mass AI moves.

6. A common technique (apparently) is to use regions as a kind of macro-tile. With a table of regions, region centre points and their adjacency, an AI can navigate long distances without having to search the whole map for their goal. they first use the regions table to get a path of regions A->C->F then use the expensive tile pathfinding algorithm to find the (much shorter distance) path between the hub points of those regions. Switching back to the tile algorithm when they reach the goal region for the final move to the target.

7. The pages mentioning this technique imply the standard method for doing this involves breaking the regions into convex polygons.

~~~

Current conclusions.

1. When it is the player's move the game knows there is only one stack/agent being moved at a time so it can use the full strength pathing which won't fail.

2. Observations 1-7 (and maybe 8) lead me to think the game is using regions somehow as a macro pathfinder. If it does then that may be part of what it is doing when it generates the map.rwn. However, there's no way TW regions are ever going to be all convex ploygons except on the most simplified maps. There may be a cleverer algorithm i haven't come across that would generate a distance table for regions such as those in a TW game. That algorithm will still have rules though and figuring them out and editing the map accordingly will improve the AI pathing. Alternatively they may just use the full-strength pathing algorithm to generate a region table. Currently tweaking my much-edited vanilla map along the lines of making the region boundaries convex in the directions of travel until i get a better idea.

This system requires each region to have a centre point for the AI to aim at. If the game uses the regions as a macro pathfinder how does it calculate the centre? If it a simple average of the x,y co-ords of the tiles in the region then could it be glitched by some coastline shapes and those little islands that are part of the land regions? The "goal" setting on these long range moves may be weaker i.e not reaching the "centre" tile of a midway region but getting within 2-3 tiles maybe as i think this would be cheaper to compute.

3. Pathing algorithms have a start tile and a "goal" tile. Observation 9 makes me think the goal tile for a city is maybe not the city itself but the sentry spot for a city (usually the bottom left of the tiles around the city depending on terrain). Making sure there is a clear path to this tile for each city may help.

4. Observations 10-12 all look like the kind of things that could happen with "weakening" tweaks to the pathing algorithm. So basically certain combinations of terrain might cause the algorithm to not return a valid path under certain combinations of movement cost and movement points.

5. Observations 13-14 make me think stacks with a city target have a stricter "goal" setting which in combination with the algorithm weakening tweaks makes them more prone to getting stuck.

6. When building the regions distance table (if they do) and using the terrain tiles to calculate it, if they used the full strength algorthm to generate the table but used the weakened algorithm when actually moving the AIs that might be behind some of the glitches. this might relate to observation 15.

7. the retreat/post-battle stall could (and probably is imo) be caused by more than one thing. in some cases it is simply the AI retreating to a tile with a pathing problem.

8. observation 17. dunno. more googling

9. observation 18.

a)The meaning of convex in the context of a TW map. With all fertile tiles and no obstacles the best region shape may be a convex polygon but is that the correct shape when the varying movement costs of tiles is taken into account.
b)If the AI is using tile based pathing from A to B why should it care if it finds itself in C for part of the route?
c)Why doesn't the AI care about crossing a mutually adjacent region when the regions are convex polygons on a simplified map (or is it the movement cost/terrain)

10. Game may give AI stacks with a city target a first sweep with the full strength algorithm for up to one turn of movement. If it finds the goal it moves, if it doesn't it cuts off and uses the weakened algorithm. This would explain the one turn move effect.

11. "might" not be possible to get perfect pathing on a large realistic map

12. "might" not be possible to get perfect pathing on a large realistic map without very long end turns

13. definitely possible to get perfect pathing on a small simplistic map (apart from retreat stalls)

14. "might" be a cut-off point where you can get perfect pathing on a quite large, quite realistic map.


~~~

another pointer to the game using a region distance/adjaceny table is the low number of regions they have in the vanilla game. these tables require the region number squared records of however many bytes. so 60 regions require 3600 times x bytes and 200 regions require 40000 times x bytes.

AI end turn slows down a lot as you add more regions. mods with large maps might want to consider agent limits and more expensive units to cut down on the total number of moving AIs.

[SigniferOne]

Nikolai, top notch post.

A general question: how would you reconcile the fact of perfect pathing (surprising but true, you were right) with the foibles that AI gets into? You say that during player's turn only one stack is being moved so the full-strength can be used. But the same must be true for AI, who can only move one stack at any one time; so they could apply the full-strength algorithm first to the one stack, then to another, etc.

Finally, some minor questions: would you recommend that inaccessible islands that sometimes share region borders with mainland regions, should be separated into their own properly colored region, so that pathing to mainland regions won't be affected?

What's the conclusion on convex requirement. Is there one?

Does opinion 10 say that there should be lots of moves for use, or that there should be few? Seems like the former, based on your other conclusions.

re: opinion 18: yes in total, but not at the same time; the AI turns aren't calculated all together, but one by one, and by each stack within each faction's turn.

re: opinion 13: really? That would be a heartening conclusion overall, if true.

re: opnion 11: how :-P

re: opinion 1: very important one, also how :)

That's that for now. It's all very provocative (in a good way). Very good post.

[alpaca]

Do you realize that each AI turn would take minutes if the game used perfect pathing for every freaking unit it moves (and it generally moves almost every unit once per turn at the least)?

nikolai: It could be possible that the game uses a kind of large-scale pathfinding via road join points (where roads go over the region border). This way, the AI stacks would usually travel reasonably fast because travelling on roads is faster than through wild terrain and it could be pre-calculated quite easily.
If that's true, you should be able to stall the AI by putting a large stack between their target and them onto a road join.
Keep up the good research

[Re Berengario I]

I don't know if Nikolai has already kept it in account but some stack stalling is due to AI settings.

For example some conditions that pushed the AI to attack a region could be changed in the meanwhile. I witnessed it a lot during my AI experiments.


I also had the impression that attack/defend decisions are splitted in two consecutive turns (first turn attack evaluations, second turn defensive evaluations). This also could lead to a stall which isn't caused by the map.

[nikolai1962]

hehehe - major progress today :)

responses first...

I don't know if Nikolai has already kept it in account but some stack stalling is due to AI settings.

For example some conditions that pushed the AI to attack a region could be changed in the meanwhile. I witnessed it a lot during my AI experiments.


I also had the impression that attack/defend decisions are splitted in two consecutive turns (first turn attack evaluations, second turn defensive evaluations). This also could lead to a stall which isn't caused by the map.

Yup. One of the difficulties with this is knowing when they're stuck and when there is something else at play. One example is when they're outside a city in the sentry spot and adding more units to the army. Hard to be sure if they're stuck or on invade_buildup or something. The way you can *generally* tell is if you move the army to a nearby rebel region and see if it attacks on the next end turn. If it attacks the city then it was definitely stuck. Sometimes it will move to attack *another* rebel city that it can path to from the new position, sometimes it will head back to where it was before i moved it. They only attack the settlement they were stuck on.

They also seem slower on medium difficulty, at least on my test map. They often take a city and wait for a while instead of moving straight off to the next city like they do on VH. Mission frequency?

With the default AI profiles I'm restricting myself to only looking at the early game where factions are attacking rebel regions which makes it simpler. When wars break out between the factions all sorts of other factors come into play. Also most of my testing is with an AI profile that is attack rebel only (with invade_immediate) and invade_none/force_invade=false for all the other factions so i think that will cut out a lot of other possibile reasons for the AI not to be moving.

~~~

A general question: how would you reconcile the fact of perfect pathing (surprising but true, you were right) with the foibles that AI gets into?

Had a good bit of progress on precisely why it gets stuck today. Explained below.

You say that during player's turn only one stack is being moved so the full-strength can be used. But the same must be true for AI, who can only move one stack at any one time; so they could apply the full-strength algorithm first to the one stack, then to another, etc.

Ditto on alpaca's reply, that is precisely the problem--it can't. From what i've been reading each full strength path-find takes x amount of memory/puter cycles etc. If it moved all the hundreds of AIs using the full strength during the AI turn it would slow to a grind. (I don't know this personally, just what i read.) So games have to reduce the overhead by weakening the AI pathing except in a few special cases.

Finally, some minor questions: would you recommend that inaccessible islands that sometimes share region borders with mainland regions, should be separated into their own properly colored region, so that pathing to mainland regions won't be affected?

Good question. It is all about the region centre point and so it depends on how they calculate that. Basically depends on how they calculate the region centre. Could be:

1) averaging the x, y co-ords of the tiles in the region.
2) averaging the x, y co-ords of the *walkable* tiles in the region.
3) some kind of bounding rectangle incorporating the tiles in the region.
4) Something else.

If my current theory is correct and they calculate the centre point by 1) or 3) then those islands matter and can distort the pathing (sometimes in a good way). If it's 2) and they are all covered in mountains then they won't. Explained more below.

What's the conclusion on convex requirement. Is there one?

Definitely not a requirement on the tile-based pathing bit. It did do something though so i went back to look at it again and now i think it had an indirect beneficial effect on many regions but not because it was used mathematically. Will explain below. It *may* be relevant earlier, at the point where they generate the rwn file and (i think) generate some kind of table of which regions are adjacent. Games set in dungeons etc divide the space into convex polygons to create these region tables but given the nature of TW maps it is hard to see how the region-to-region pathing could work at all if it was a requirement.

It does however make a certain thing much easier (explained below) so i am sticking with my new "convexed" map for the time being.

There is still the possibility (tending to likelihood now) that the meaning of convex in Jerome's post was more to do with unreachable bits of regions.

Does opinion 10 say that there should be lots of moves for use, or that there should be few? Seems like the former, based on your other conclusions.

Larger amounts of movement points over-ride most pathing problems on a vanilla scale map because most of the pathing stalls happen between one and two turns of vanilla movement away from the target settlement. Increasing the movement points while keeping the map the same will increase the one-turn move effect which over-rides most stalls. It will depend on the scale of the map though. If the distance between cities was doubled and movement doubled you won't be gaining much (apart from a longer AI turn). I keep meaning to test the effect of increased movement on retreat problems but i never get around to it as i just don't like really long moves--feels too much like Rommel to me. Personal preference. No doubt though that increased movement points works. Doesn't fix the pathing problems but it does over-ride many of them (not all).

I think there are three distinct sets of pathing problems. Depending on the terrain movement costs and how they have weakened the full-strength algorithm i think there may be a "sweet spot" value for movement which gets round one of these sets of problems. Don't have a clear enough understanding of this one yet to be clearer than that.

re: opinion 18: yes in total, but not at the same time; the AI turns aren't calculated all together, but one by one, and by each stack within each faction's turn.

Yup, but it is cumulative. 600 AIs times 1/2 second = 5 mins. (Prob not really 1/2 second but you get the idea.) I've never tried to count the total number of stacks/agents but on a big map there could be...dunno, lots.

re: opinion 13: really? That would be a heartening conclusion overall, if true.

On my simple mini-map the AI never stalls except after a retreat. Takes 14 regions in 30 turns (can be much longer, depending on the recruitment options.) (This is starting with a general, 4 levy spearmen units and a motte and bailey castle with no buildings.)

re: opnion 11: how :-P

Imagine the map as a piece of paper divided into squares. Draw a load of blue sea on it. Add various impassable terrain and draw region boundaries. Then imagine cutting an individual region out of the piece of paper. Then cutting away the impassable terrain. Any walkable squares that aren't joined orthogonally will drop off the region. For some reason i have a gut feeling that matters to the algorithm somehow. I think tiles like that count as unreachable.

Also... on a more scientific level. One of the aspects i read about on the pathfinding googlefest was how to deal with diagonals. Basically the algorithm (A* is apparently the most common) uses a guess of the cost of the straight line distance to the goal. The euclidian straight line distance uses expensive routines like square root so games often use an approximation. The simplest one is what is called the "Manhattan" distance, which just counts the number of x and y moves and ignores diagonals completely. A step up from this is an approximation of the diagonal move. Some combinations of move costs combined with the diagonal approximation might cause a weakened algorithm to not be able to find a path. Maybe. Not sure on this yet.

re: opinion 1: very important one, also how :)

Changing the region boundaries changes the region centre point :)

That's that for now. It's all very provocative (in a good way). Very good post.

Ty :)


~~~

nikolai: It could be possible that the game uses a kind of large-scale pathfinding via road join points (where roads go over the region border). This way, the AI stacks would usually travel reasonably fast because travelling on roads is faster than through wild terrain and it could be pre-calculated quite easily.
If that's true, you should be able to stall the AI by putting a large stack between their target and them onto a road join.

Yup, that was one of my "possibles". It sort of does in a way but indirectly by way of the road routes taking a "best path" which the AIs will often follow even before there is a road there.. Thing that got me was when they'd take a wildly eccentric route *away* from a direct road path. Think i know why now, explained more below.

Keep up the good research

Ty :)


~~~

Ok, need to upload some screenies and back in a bit to explain a good bit of progress on figuring this out.

Did you ever wonder why the Iberians in RTW always landed armies on Palma that never attacked? Find out soon (maybe) :)


~~~

New Theory

Gave up trying to "convex" the map i'd been working on as i'd already added dozens of regions, all neatly fitted to the terrain etc so convexing the map added too many new problems at once. My simple minimap though has three things different from a normal map--rectangular regions, no obstacles (mountains etc) and all fertile tiles so no variation in movement cost and it has zero movement problems so thought i ought to take a second look at the convex thing just to be sure.

Started again with the plain vanilla map as fewer regions to deal with. Convex the regions. Added a couple in spots where i couldn't fit a rectangle while still conforming to the impassable terrain. Made sure i didn't have any unreachable areas. On the simpler vanilla map the process didn't make the pathing worse as long as i made sure to look out for areas i'd made unreachable by the border changes. Didn't magically improve things in a big way but did have minor beneficial effects in certain areas. Had the same problems in spain i had with my previous historical boundaries version of the map which was i could never get both spain and the moors to move well at game start. It was either one or the other (this is with 6-7 new rebel regions added to spain.) Finally twigged what i think is happening.

The game navigates from region centre to region centre which i'll call the hub. So if a stack is ordered to attack a settlement in another region it gets a path of regions to follow. Assuming the stack starts in region A and has to pass through region B on its way to attack the city in region C the sequence is either:

1) start location -> hub A -> hub B -> hub C -> city C

or

2) start location -> hub B -> hub C -> city C

(hard to tell if it goes to the hub of the start region with my current small regions - will see when i get to the steppe regions.)

this fits 80%+ of my observations, depending on how they calculate the region centre point. assuming the centre point is calculated simply by the average of the x, y co-ords of all the tiles in the region then it is about 80%. Might fit a higher percentage if they calculate it differently.

I think pathing to the hub doesn't require the AI to actually reach the hub but to get within some distance of it (2-4 tiles?) which i'll call the beacon distance. So it paths to the intervening region, gets within the beacon distance of the centre tile and then switchs to pathing to the next waypoint. If at any point it can't get to within the beacon distance of the waypoint then it stalls.

>>>>>>>I don't think the pathing will go through a city ZOC.<<<<<<

The first screenie illustrates the theory. The moors would send a stack to attack valencia through Toledo which would stall at the point illustrated. I think the stack got stuck in it's sequence because it couldn't get a path to the toledo region centre point because with the ford in the old position, (marked in black), the path was blocked by the city's ZOC. (Currently assuming the centre is the averaged x,y co-ords). When i moved the ford to its new position one tile to the right the path to the centre was unobstructed by the ZOC and the moorish armies going to valencia didn't stall at that point.





Similar situation except this time it was the spanish who got close to Estramaduras and stalled. (They'd been there a while before the moors attacked the city.) Again, estimating the centre point of the region it looks like the path to is was blocked by the city ZOC. Tweaking the city position and fords i eventually got it so both spain and the moors had a clear path to the estimated region centre and both factions would move to and attack the city.





The theory explains why i had such problems getting both factions to move at once with all those horizontal rivers and my penchant for blocking fords with cities. Either the centre point was one side of the blocked river or the other and so only one of the factions could path to attack the city. Even if the city itself had a closer unblocked path than the region hub.

Editing the spanish bit of the map according to this theory i now have all three factions able to attack all 6 of the rebel regions in spain.

caveat: according to the theory (and if the region centre is calculated by averaging the x, y co-ords) i don't think zaragoza should be attackable from pamplona but it is. Though actually, now i think of it it might just be close enough for a one turn move. Will need to check.

Basically however editing the map according to this theory is working.

How does this apply to palma?

If you look at the screenie at the original position of palma you can see where my estimate of the region centre tile is (including the co-ords of the little island to the west in the average.) From almost every landing point the city ZOC blocks the path to the region centre so even though a landed army might be right next to its target city it doesn't get the order to attack because it can't clear the previous hurdle of getting a close path to the region hub. (Up to this point most of the AI landings on palma didn't lead to an attack on the city. Only occasionally would an attack happen. I didn't notice what tile the landing was on though.)




I changed the city position on Palma according to the theory as shown below. Now all but one of the possible landing tiles can path to the assumed region centre without crossing a ZOC tile.



One test run. Moors had landed in what i think is the invalid tile and never attacked the city even though they were right next to it. Spanish landed later on one of the assumed ok tiles and attacked.




So, new theory, seems to be working. Might be *the* cause of one set of problems or at least very close to it. Hard to be sure without knowing how the centre point is calculated. Some of the regions were behaving in a way that made it look like the centre was one or two tiles away from where i'd calculated it. Also the beacon distance seemed to vary a bit--maybe move cost rather than number of tiles?

So what convexing the regions was doing was shifting the centre point . The reason it had *some* beneficial effects was probably because a lot of the vanilla regions have such odd shapes, some of them would have centre points out to sea, inside other regions entirely, or just shifted to be inside more complicated terrain. So my convexing, (while trying to keep the rectangular regions conforming to obstacles), was on average making centre points more "central". It didn't fix everything cos the core isn't the convexity itself but the clear path to the centre point.

Also, if the city is directly on the centre point of the region then it's ok.


~~~

I think there are three sets of potential pathing problems.

1) The initial generation of the region table and the game knowing which regions are adjacent. Might not be an actual problem just it seems sometimes that regions don't always know an adjacent region is adjacent.

2) The pathing via waypoints being blocked. The new theory is fixing all of these so far (though i've only done spain so far).

3) The third set are those cases where i think the specific movement cost of a particular path doesn't work with the weakened pathing algorithm the AI uses in the AI turn. May eventually be able to figure out the specifics but basically complicated paths with lots of obstacles and high cost terrain can get these problems. Also cases where the AI has to move away from its target to get closer i.e move around an onstacle, though this seems more rare in mtw2 than rtw. Editing the ground types and moving fords can often get round these but it is a trial and error process. Sometimes it is fixed easily, sometimes it isn't.

Hope that was clear.

[alpaca]

Hmm looks like a very good working theory. How did you calculate the average position though? Arithmetic mean of all tiles x and y positions?