Better City Sites AI

I'm not sure if this is better off in the mapscript thread or the city placement thread. I have written the new start plot selection code for arrakis.py using my description above. I have not tested it very much; there isn't any convenient way to run dozens or hundreds of maps and store the results.

If you are interested, please download the attachment and unzip it over your previous version of dune wars/public maps/arrakis.py. I'd be interested in any feedback. Note: since this code is entirely inside the mapscript, (a) it doesn't affect the archipelago mapscript, (b) it doesn't affect placement of the second and later cities of any civ, (c) it doesn't change where the settler "blue circles" or BBAI debug "colored circles" go.

After some testing and feedback, if it seems OK, then I will try to rewrite it inside the sdk in C code instead of python, and replace AI_foundValue. But I need to investigate more about how the rest of the sdk handles overlapping of suggested sites.

Dumb question: will this affect just starting locations for civs, or also AI city placement of 2nd, 3rd, etc. cities?
Just to know what to look for when testing.

Ahriman said:

will this affect just starting locations for civs, or also AI city placement of 2nd, 3rd, etc. cities?

Click to expand...

davidlallen said:

(b) it doesn't affect placement of the second and later cities of any civ

Click to expand...

tencharsneeded

Comments on the revised Arrakis initial city placement. Overall looks pretty good.

1. Bonus plots should not be starting plots - one of my number one gripes at the moment is the number of times the AI founds cities on top of resources negating the bonus they could get from them. Capitol cities on bonuses still happens in your revised Arrakis. Hopefully that is an easy fix to make.

2.

30 if mesa
...
50 if it has a groundwater resource
30 if it has a water plant resource (sword grass, etc)

Click to expand...

I feel that groundwater might be weighted too high relative to the other water producing tiles (mesa/dew collector resources). I think that, since we reworked the early game, the yield from groundwater is not higher than the other two sources in the early stages. Aquabores give +5 water, but when you get Water Discipline, Dew Collectors provide +3 water and Wind Traps +4 water, so even if you are weighting proportionately then mesa should be higher. However, I'd probably advocate giving them all more equal weights since getting a capitol city that performs well in the early stages is probably more important than having one that performs well later. So maybe, groundwater = 45, mesa = 40 and water plants = 35.

So maybe, groundwater = 45, mesa = 40 and water plants = 35.

Click to expand...

I did a quick test with these values and the results look pretty good. The starting plots usually seem to have 3-5 good water producing tiles. If we could just eliminate the starting plots that are on top of bonuses then we'd have a big improvement on the current code.

Deliverator said:

I did a quick test with these values and the results look pretty good.

Click to expand...

Thanks for the feedback! The reason mesa has a lower value is due to the windtrap separation requirement. This is the discussion we had a few posts back about weighting mesa by 1/2 or 1/4. I think 1/2 is the right value; *on average*, if you have 6 mesa plots in your BFC, you can probably build three windtraps. However, if you have three groundwater resources, you can build three wells.

I will try leaving groundwater and mesa the same but bump up water plants to 40. Then each *usable* mesa is worth 60, groundwater 50, and water plant 40.

If we could just eliminate the starting plots that are on top of bonuses then we'd have a big improvement on the current code.

Click to expand...

This is really annoying. The mapscript specifically excludes any plot with a resource from being a starting plot. At the end of the mapscript I added a print statement which verifies this. But then in the game start python, I added the same print statement, and it shows that *somebody* has added resources into my start plots after the start plots were chosen. There are routines normalizeAdd* which are called after the start plots; but in arrakis.py these routines are stubbed out. So I am having a hard time finding who is adding these, and why.

Since these are added after the fact, they do not affect the starting site location; therefore, I have added a few lines in the game start python which removes them. This works but it is a "hack" fix. I will dig further to see if I can find out who is putting in these resources.

So I am having a hard time finding who is adding these, and why.

Click to expand...

I think I know exactly why this is. This hack was put into CvEventManager.py (by me) to resolve the Insect bonuses not being placed on the Arrakis.py map.


This is not really the best solution. If we make sure Arrakis.py uses the default game bonus placement (i.e. placement according to Civ4BonusInfos.xml rules) then the hack won't be needed.

Ack! Your code is erasing all the bonuses that were used to choose where to put the city sites! Then any good result we are seeing from the new placement algorithm is totally coincidence.

Let us both remove your code, and then re-evaluate the results from scratch. At least now I understand where the bonuses are coming from.

I removed that code from cveventmanager and ran a couple of tests. I see spice honey, etching resin and baradye present on the map. I am not quite sure why you needed to add that code. Is it possible the order of events was:

1. Previous bonus placement values in bonusinfos.xml in 1.4.x
2. Players observed no spice honey, etc
3. Added code into cveventmanager
4. New bonus placement values in bonusinfos.xml in 1.5.x

And then #4 made #3 un-needed? Otherwise I am confused.

As long as it is working now it doesn't really matter.

Bumping this thread because I have news.

In the last couple of days I have studied the infamous AI_foundValue code, and come to mostly understand what it does. So, using the design from this post, I have implemented a new version. This totally changes the rules for the AI founding colonies. It does not change initial map positions on arrakis; this is still controlled by the arrakis mapscript. But both of them use the same algorithm.

I have added a scaling term for distance from the capital city: a site less than 10 plots from the capital has its score doubled, a site more than 20 plots away has its score halved, and sites more than 30 plots away are discarded.

I did two autoplays on the same map to test it out, one with the old colony selector and one with the new. I am surprised, and a little disappointed, that the total population, total commerce and scores with the new selector are *worse* than the old selector. We had been expecting that the poor placement of AI colonies before was a major cause for the gap between AI stats and human player stats, but that may not be the case.

There is one obvious difference between the old selector and the new selector. In the old selector, it was very clear that the AI would rush to place colonies on the polar cap. In the new placement, the AI never places a colony there, ever. I do not quite understand the reason. Perhaps there is a bug, but it is certainly not obvious.

In the design linked above, each polar plot is worth 5 points, and if there is ice there, it is worth 100 points plus 10 per ice resource. These seem like high values. I have tried doubling the point value of polar plots to 10 each, but that did not change anything. I will try 10x the value, which is silly, to make sure it is at least possible.

If I can get a version where the scores at least match the previous, I will put up a patch release like 1.7.0.3.

sweet david, looking forward to test it.

I think that the distance modifier might be too drastic. That may explain the rejection of the polar terrain.

EDIT: for example, you don't want every tile within 10 to be more valueable than every tile more than 10.

EDIT2: You might have more luck with a distance modifier 'formula' rather than discrete step values. For example say every unit of distance decreases the value by 1.5 percent or something.

Glad you're learning more and have an alternative implemented, but unfortunate that it doesn't seem to be working well yet.

In terms of parameter values, I would say:
i) Do not count the tile that the city would be built on.
ii) Desert waste should probably be worse than rugged.
iii) I would drop the value of mesa a little, maybe to 25.
iv) Can you put in a minimum found, where the AI never founds a city with value below say 85?
v) The distance thing seems problematic; the AI will *never* found a city more than 30 tiles away from its capital?
Maybe you can change this to an algorithm that looks at tiles away from existing culture, rather than from the capital?

The emphasis on crystal and nitrate might be too high. I would lower them from 100 -> 20 or 25.
It is not important that those resources be in the BFC, all you really need is to have them in your cultural borders as a strategic resource.
It is much better to have them one tile outside your BFC (but still claimed by culture fairly easily), but have the city get good water income, than to have them in the city BFC but with worse water income.

A very useful test would be if you can take a given map, and then run the AI's on it with the default BTS city placement and then again with your script, noting when cities are founded where, by each player. Maybe post some screenshots.
And then maybe compare to a human's dotmap.
If you can make it easy to switch between the old/new versions, I may be able to do some testing.

Looknig at that data (and posting some screenshots) coudl be a big help in diagnosing any weaknesses in your new script. Are AI cities still too close together? Do they not found enough cities? Do they no longer use scout thopters and suspensor transports to settle other islands? Do they found junk cities close to the capital rather than good cities a bit further away? etc.

I think my previous data collection was wrong. The results seem pretty good actually. I ran two of the games from the PYL thread and the results show about a 30% improvement in total population. I attached a spreadsheet which shows a comparison.

Right now there is no good way to switch between the new and old. A long time ago, in DW terms, koma13 added a hack so that we could easily adjust the point value threshold, below which the AI won't found any colonies. Because DW terrain ranks poorly by the default system, we had to lower the threshold a lot or else the AI would never found colonies. That is good, but my new system has a much different threshold from the old system, and it is controlled by the single XML variable which koma13 added. So, to switch from one to the other, you need to copy a different dll and also adjust this XML variable. (I think I got them out of sync before, leading to incorrect data collection.)

Probably what I should do is remove the hack variable and make two cvgamecoredll.dll files, one for the new site selector and one for the old. That way, by copying the proper dll file, you could switch between them. Or, it may be there is no real value in keeping the old one.

If I post the new and old ones, would anybody actually do a side by side comparison? Or should I just post the new one?

Looks very promising. I say just upload the new one if you are confidence that it's an improvement. We know the old version is pretty hopeless, so it should be fairly obvious to see if the new one is an improvement just by looking at where the AI is placing cities and saying "Would I have put that city there?". From the spreadsheet it looks like there is an improvement across the board in Tiles, Commerce, Cities, Population and Score. I would be very keen to try out a game since this could make the AI much more challenging.

Keeping the threshold value in the XML seems like a good idea in case we need to tweak it for some reason.

If I post the new and old ones, would anybody actually do a side by side comparison? Or should I just post the new one?

Click to expand...

I could run a brief test if you can make it easy to switch between (let me know which files to backup), and post in the next few hours.

But if you're confident the new one is superior, then just go ahead and post that.

Honestly though, looking at the Excel sheet, the difference is just so amazingly vast that it doesn't look like it needs further testing. That difference is *huge*, it looks like you have solved the problem.
This will probably massively boost AI performance.

We might want to do some minor further tweaking (with some of the points from posts 53 and 54) if needed.

Great work David.

The AI works seems to be really paying off. From initial autoplaying the Fremen seem to be performing quite strongly in the latest patch. In fact, they may even need some nerfing.

Edit: there still seems to be a fair amount of BFC overlap in the AI city placement. Can we do something about that?

Deliverator said:

Edit: there still seems to be a fair amount of BFC overlap in the AI city placement. Can we do something about that?

Click to expand...

Ahriman has complained about that for the vanilla placement. The fact is, the vanilla placement does account for it although I am a little unclear on the exact details. The new placement specifically counts all terrain and resource inside another city BFC as worth *zero*. Still, for both vanilla and new placement, sometimes the best available site is one which overlaps another BFC slightly.

If you can find an example where there is a new non-overlapping site which is really better than an overlapped site chosen by the new routine, that is great feedback. Please post a screenshot with your suggested different location and why. We can each go through the pseudocode I wrote in the post I linked, to see why it has chosen that site over another. Then we can work out better pseudocode.

The AI is doing much better at city placement IMO.

Here, the AI is spacing its cities much further apart, and much more like what a human player will (optimally) do.
The vanilla AI I really think tends to double count bonus resources. This AI does much much better here. The degree of overlap is very small.

And the pole still gets colonized.

Take a look at some screenshots:



Honestly, those are pretty close to the city sites I would have chosen.

I am impressed.