AI : Army Movement

[calvitix]

Hi,

As I don't have any network skills, I began to work on AI understanding, specially the unit movement.

There's some playtest commands (ie with a DEBUG executable) that are very useful to understand the units' movement.
(to activate them, use the 'Command enter alternate (playtest)' Bind and then write the code)


armytext : to see the unit's Goal on the screen. I enhanced the command to see the target's coords (X,Y)
(see thread altered sources)

god : to take on or off the 'fog of war'. useful to see what the other Civs are doing. Problem, when the fog of war is Off, the AI is able to 'see' all the map too and its behavior changes. So I usually toogle it Off at the end of each turn to see what's going on, and then toogle it On before pressing Enter.

celltext : to see a value of each mappoint (used by the Settlers to find a city place).



Here's a list of my observations :

- Chokepoint : On map with islands, a lot of units are affected to Goal Chokepoint (to protect a particular point on the map, with strategic interest). The problem is that some 'chokepoints' are bad chosen

- Squad problem : the AI don't seems to group the units that have the same goal: Each unit is considered as a single squad. the only case where the group seemes to work is when a settler needs protection. I'm working on an additional algorithm to group the unit with the same goal.

- Sea transport : the algorithm seems good : when a unit has to go on another continent, it get the nearest available transport and a rally point is automatically defined. sea assault with only one or two units is the consequence of the squad problem.
It would be good to implement an escort algorithm for the sea transport units (as it exists for settlers).

- threat calculation : problem with threat calculation : too many units are affected to the goal_defend, due to a very high threat value. that's why AI sometime has got a lot of units around its city (all are affected to the city defense).
I'll make a try with a 12-units limitation for one goal. For the moment, I didn't find the origin of the problem.


I don't know if anyone else is looking for the same improvements, any experience or help w'd be appreciated...
(for people that don't have the possibility to compile the source code and want to use the playtest commands,
it is possible to give them the compiled CivCTP_dbg.exe)

[Ekmek]

I dont think anyone else has gotten into the AI except for mods. If you could fix these that would be sweet.

One question on chokepoint. Is it feasible for the computer to identify a tile with a GOOD and defend it because it has a good? This would be needed for implementing strategic resources...

[Martin Gühmann]

Re: AI : Army Movement

Originally posted by calvitix
- Squad problem : the AI don't seems to group the units that have the same goal: Each unit is considered as a single squad. the only case where the group seemes to work is when a settler needs protection. I'm working on an additional algorithm to group the unit with the same goal.

I think this is the most important problem, a part of my BetterAi slic code is about grouping units. I saw an improvement afterwards I grouped them with slic. Looks like if I add the NeedsEscord flag to the attack goal I would make the AI to group the units for attack. And removing this flag would keep the AI from binding troops to settlers. However I think there should be a different algorithm for attack grouping, maybe it could be bind to the RalleyFirst flag. However grouping units for defence in cities might be a problem, because if you have 12 units there and the city is building a new unit you don't have space. So one unit should leave the city before the build event, or if the city is full the unit should be created outside of the city, but with less move points.

Originally posted by calvitix - Sea transport : the algorithm seems good : when a unit has to go on another continent, it get the nearest available transport and a rally point is automatically defined. sea assault with only one or two units is the consequence of the squad problem.
It would be good to implement an escort algorithm for the sea transport units (as it exists for settlers).

Maybe there is also an problem if the squads are to huge for the transport. Afterwards I grouped my units via slic I didn'd saw full transports, and even loading these transports by slic was tricky. If there is enough room on the transport for the stack no problem, but the stack is too big then I had to ungroup the units myself and give every unit the transport order and I think there was another problem.

Originally posted by calvitix
- threat calculation : problem with threat calculation : too many units are affected to the goal_defend, due to a very high threat value. that's why AI sometime has got a lot of units around its city (all are affected to the city defense).
I'll make a try with a 12-units limitation for one goal. For the moment, I didn't find the origin of the problem.

So setting all this to zero should help, but then I fear I break something else:

 
    // priority for fear motivations
    FearInvasion        1000
    FearCityDefense     1100
    FearPiracy           900
    FearScienceRank      800
    FearMilitaryRank     800
    FearTradeRank        800
    FearPollution        900

Actual I don't like the 12 units limitation, well you can experiment with it, but I would feel better if the problem is solved at the root.

Originally posted by calvitix
I don't know if anyone else is looking for the same improvements, any experience or help w'd be appreciated...

Well I assumed that Peter was looking into this, he talked about that he looked at the transport thing and about modification on the startegies.txt, but he never posted anything about it. Therefore I decided to give up on hesitating and exposed the startegies to personalities.txt. And I thing you shouldn't hesitate either.

-Martin

[calvitix]

Originally posted by E
One question on chokepoint. Is it feasible for the computer to identify a tile with a GOOD and defend it because it has a good? This would be needed for implementing strategic resources...

It wouldn't be a problem, it is possible to add tiles with good as chokepoint.

[Ekmek]

calvitix

thats great news I hope that means that tiles with goods anywhere could be a defendable point and later a place to put a colony or something (like civ3) or even a goal to capture those tiles.

thanks!

[Peter Triggs]

Hi, guys

I'm essentially computerless (posting from wherever I can at the moment) but have just bought a new one and hope to get back into things early in September.

Peter

[calvitix]

AI Movement update beta1

Hi,

it's time to report and release a first version of my work on Army movement and grouping.
(source code is in thread 'altered source')

the changes I made are quite heavy, and some unwanted effects on AI movement can appear.
That's why I release now that version as beta, I alone can't test if all the unwanted consequences of my modifications.
(I do test it for 2 weeks now, and it seems to work well for the moment).
I'll soon post an executable that can be used with latest playtest package for people that don't compile the sources...


Here's a list of observation and changes :

1. original AI grouping worked good for settler escort, the princip has to work for armies too...
So why isn't it working ?

1.1 There is not enough units to affect to goals (too many are defending or for garrison)

AI cities are always filled with units. 3 reasons :
- Garrison : as described in strategies.txt, a minimum of units are affected to garrison.
- Defend : units with goal Defend. not the same units as those for garrison.
- Retreat/no Goal : when a unit isn't affected to a goal, it will be affected to goal RETREAT,
so the unit goes back to the nearest city.

first problem : too many units defending : units for garrison aren't included in goal matches but are blocked in the city (and they aren't affected by the deleteobsoleteunits action, that's why we can find phalanx or catapult in AI cities during all the game).
in addition to those garrison units, some armies are affected to goal DEFENSE (depends of threat). So I give only the minimum values for garrison in 'strategies.txt'.

second problem : the RETREAT goal don't works as expected (it should retreat units from ennemy territory).
I desactivated it for the moment, until a real non trespassing action is developped (I'll working on it after cargo problem...).


1.2 The army affectation to goals (the matches) doesn't promote grouping

the matches (a link goal <-> unit) are sorted by a value that depends on goal priority, distance to goal destination...

Problem : an Army will be affected to a low priority goal that is near (with high match value) rather than a high priority goal that is far (such as SEIGE or ATTACK). So a High priority goal but that needs a lot of units will never be satisfied, because all the available units would be all affected to single low priority goals (such as Pillage, pirate, chokepoint,...)

Changes : now the matches are sorted by goal priority, and the by matches.

Unwanted effects : if a Goal uses the NeverSatisfied && UseIncrementally options, it 'll get all the available units. those options are not used for the moment (I remove it from goal RETREAT)

1.3 The condition to declare a goals satisfied (ie with enough armies) isn't optimal

Each goal has a needed_strength. a goal is satisfied if the affected army is higher than the needed strength.

Problem : that needed_strength is satisfied if the army's attack OR defense is higher.

Changes : now the sum of all parameters as to be satisfied (not only attack or defense).

1.4 The force matching in 'strategies.txt' doesn't promote grouping

The force matching values are usually about 0.6. it means for example that in order to attack an unit with 200 in defense, an attack_strength of 120 will be enough. (quite suicidal, as it has less than 30% chance success).
Personly, I only attack when I have a real chance to win the combat. So I raise the ratio values...
To attack an unit, AI will now have to regroup an army with enough strength before attacking.

All those ratio value have to be adapted (different values for the different strategies...)

2. When an army is affected to a goal, it will be released only when the goal is accomplished or cancelled.

So I try to reevaluate all the goals affectations every turns



3. with those modifs, AI now groups units, but can't ungroup them
AI don't need only grouped armies, but also single units (to explore, ...)

So I added a token 'UnGroupFirst' for several goals in 'goals.txt', and ungroup methods associated...

4. Goal Explore : new goal are only created when all old one's are accomplished.

Now, it set new goal every turns. I Changed also the resolution (an explore goal every 2 tiles instead of every 5 - perhaps can be set as constant in 'const.txt' ?).


5. too many units in cities -> problem with transports
As there is a lot of units in the cities, transports have to get out of cities to allow armies to board in.

So I use a copy of the 'make room' algorithm to expulse the transports out of city. it leaves them quite undefended,
that's why I'm working on their protection (next point)


6. Transport protection (to be done)
transport units are vulnerable, they should be protected as the settlers.


7. Road and Tile Improvement

I discovered that the Road and Tile improvement construction is only every 5 turns. changed to do it every turns.




I'm now waiting for questions,comments or eventually bug reports.
I'll go on with tests and try to work on further points :

- the transports (protection, huge armies' cargo problem)
- treaty respect (non trespassing,...)
- retreat of wounded units to heal (in city or forts)

[Martin Gühmann]

Re: AI Movement update beta1

Originally posted by calvitix
5. too many units in cities -> problem with transports
As there is a lot of units in the cities, transports have to get out of cities to allow armies to board in.

Why have the transports to leave the city in order to to allow the army to board in? I would put the units into sleep mode and leave with the transport the city, the units are then put automaticly on the transport.

Originally posted by calvitix
7. Road and Tile Improvement

I discovered that the Road and Tile improvement construction is only every 5 turns. changed to do it every turns.

Is it really necessary to do it every turn, I mean this eats calculation time, and such a delay of 5 turns doesn't matter I think. In fact it helps the AI to save some PW for more expansive tile improvements.

-Martin

[calvitix]

Re: Re: AI Movement update beta1

Originally posted by Martin Gühmann


Why have the transports to leave the city in order to to allow the army to board in? I would put the units into sleep mode and leave with the transport the city, the units are then put automaticly on the transport.

The problem is when the transport is in the city with for example 8 units, a 5-units army cannot enter in the city to sleep. it occurs only when the join point is defined as the city tile (that appends when the transport is in a city at the moment we need it), but I encounter the problem several times during my test games.

Originally posted by Martin Gühmann

Is it really necessary to do it every turn, I mean this eats calculation time, and such a delay of 5 turns doesn't matter I think. In fact it helps the AI to save some PW for more expansive tile improvements.

-Martin

it has to be discuss when we'll work on tile improvement and road. (I don't really care for the moment on calculation time, and for some games it can gives advantages (specially for roads that have to be build after pillage or pollution). can rollback the change, not a problem for me...

[Martin Gühmann]

Re: Re: Re: AI Movement update beta1

Originally posted by calvitix
I don't really care for the moment on calculation time

I noticed this (and I am not happy about it ), 15 seconds on the first turn of the game just for all AIs, I mean these AIs just need to find nice places for their first cities. And then there is nothing to calculate until they get their first units. I mean I want to play this game on a PC with AMD Athlon with 1333Mhz and 256MB RAM and I don't plan to buy an Earth Simulator just to play the game with 10 civs on a world map of 64*128=8192 squares.

That's an early game tedium.

-Martin

[calvitix]

Re: Re: Re: Re: AI Movement update beta1

Originally posted by Martin Gühmann


I noticed this (and I am not happy about it ), 15 seconds on the first turn of the game just for all AIs, I mean these AIs just need to find nice places for their first cities. And then there is nothing to calculate until they get their first units. I mean I want to play this game on a PC with AMD Athlon with 1333Mhz and 256MB RAM and I don't plan to buy an Earth Simulator just to play the game with 10 civs on a world map of 64*128=8192 squares.

That's an early game tedium.

-Martin

I have an equivalent PC (1200Mhz and 512MB RAM), and I don't noticed so much time during my tests. Which Version did You try ? I usually works with Final version.
With the Debug Version, allmost all the time spended is for log file writing, specially with the k_dbg_scheduler(as I added some log infos to debug the Goal priority computing).

But you're right, I have to take care of calculation Time (It is one of the main reason for me not to play Civ3 anymore....).

By searching in logs file, I discovered that the much time consumer is the agent matching (not really a surprise),
specially with a high MAX_MATCH_LIST_CYCLES. I suspect the processmatches to do 10 times the same affectation mistakes...
I'll check it soon (I'm actually working on DistancetoHomebonus that isn't correct calculated - apparently rc2xy problem)

- Calvitix

[Martin Gühmann]

Re: Re: Re: Re: Re: AI Movement update beta1

Originally posted by calvitix
I have an equivalent PC (1200Mhz and 512MB RAM), and I don't noticed so much time during my tests. Which Version did You try ? I usually works with Final version.
With the Debug Version, allmost all the time spended is for log file writing, specially with the k_dbg_scheduler(as I added some log infos to debug the Goal priority computing).

I used the Final version as well, but I also use the Inductory Edition of MS Visual Studio C++ 6, and that version does not include the optimisation options. So the additional time used for the AI is in both versions the same. However CTP2 should still be a game for low end machines, so that I can give it to father to get to know the wonderfull world of Civ, unfortunatly he has to use my old computer a K6 with 233 Mhz and 64 MB RAM. So it should also run on such a machine. I think the main problem in my case is the exploration resolution.

To test and compare the two exploration resolutions I did a game with a resolution of 2 and a resolution of 5. Here is the Incian world map after 267 turns for a resolution of 2:

[Martin Gühmann]

And here is a the Incian map after 267 turns with a resolution of 5. What I see is that the Incas explored more in the resolution of 5 then with the resolution of 2. One possible explanation for that issure is that possible targets are further away from each other in the 5 res version then in the 2 res version. The disadvantage of the 5 res version is that there are some spots of darkness left in the middle of explored terrain. However I don't think this is an huge issure, because in the end everything will be explored and if such things are left then it doesn't hurt the AI either. Just for the human player might it be a problem if he gets maps with such black spots.

[Martin Gühmann]

Now I like to talk about exploration itsself, the Incians aborted exploration at one point. On the picture we have the Southern Incian continent, it is bigger then you see here, but for some reason the Incians stopped here.

[Martin Gühmann]

And the same situation in the 5 res game, well the Incians explored a little bit further then in the 2 res game, but I don't thing the differences are significant. Maybe this is a problem of the selected strategies for the Incians, in personalities.txt. However one thing I see is that the AI has units in the middle of nowhere. What do the units there.