davidlallen
Deity
Awesome. Thanks!
Better City Sites AI
- Thread starter koma13
- Start date
Awesome. Thanks!
davidlallen
Deity
It is in the 1.7.0.4 local patch, including the sources. (See also post #841 for a fix to the patch in case your c:\\ directory is not writeable.)
It is probably obvious, but the changed file is CvPlayerAI.cpp, function AI_foundValue. No changes were needed anywhere else. At some point soon, I will write up what I have learned into this thread.
davidlallen
Deity
Thanks! What I did was:
1. Succeed at understanding the calling sequence around AI_foundValue
2. Fail at understanding the actual details of the 1000 line uncommented function
3. Throw away the existing function and write a new one of about 80 lines.
Since feedback so far seems positive, it seems that the other 900 lines of code were checking a number of things which are not really so important. I will write more about #1 soon in the thread I linked.
1. Succeed at understanding the calling sequence around AI_foundValue
2. Fail at understanding the actual details of the 1000 line uncommented function
3. Throw away the existing function and write a new one of about 80 lines.
Since feedback so far seems positive, it seems that the other 900 lines of code were checking a number of things which are not really so important. I will write more about #1 soon in the thread I linked.
Ahriman
Tyrant
Not quite.... I would guess that the 1000 line code was probably supposed to work more generally. It probably looks at tile yields and improvements and increases from techs and such to decide which things are more valuable, and it cares about river access and coastal access and all sorts of other things that don't matter for Dunewars.
Whereas your code *only* works at Dunewars (and does so very well). If you suddenly massively increased the tile yield of rock and removed the yields from mesa, the code wouldn't work well anymore.
The original code is probably designed to be much more robust.
davidlallen
Deity
That is probably true. But I was not able to really understand the original code.
Ahriman
Tyrant
I had one more thought on this issue; maybe we should consider allowing cities to be built on saltpan. Often the AI does a pretty poor job around saltpans, where a city site on the pan would have been far superior.
davidlallen
Deity
Salt is a terrain. The game disallows founding cities on salt. The AI colony value code assigns it a value of 0 when it is in the BFC. The AI does not check to see if you can desalinate or if you will be able to do so soon.
Should it assign a constant nonzero value, say half of graben? Or, perhaps it should stay zero unless you can desalinate and then it should be same as graben?
Should it assign a constant nonzero value, say half of graben? Or, perhaps it should stay zero unless you can desalinate and then it should be same as graben?
Ahriman
Tyrant
This is what I am suggesting changing. Surely this is just a parameter somewhere.
I think that giving salt 0 value in the placement algorithm is fine, or you could give it 1, I don't think it will matter much. But sometimes as an AI or a human player (particularly on larger maps with big saltpans) the optimum city cites (in order to capture groundwater/plants/mesa) is a salt tile. A human player can desalinate that first (if its within culture) and then build (or delay settling until that happens), but the AI can't.
It is the bonuses and mesa that drive optimal city placement (where the water is), and so its unfortunate if the actual good city site that combines good accses to bonuses within the BFC is inaccessible to the AI because you can't build cities on saltpan.
davidlallen
Deity
1. Should the game allow founding cities on salt? This is pretty crummy terrain, and if anybody (human or AI) founded there, the city would not grow very well. I would say leave it at "no".
2. The AI may or may not see the benefit of desalination, period. I have not tested this. The actual terrain conversion is in python, so invisible to the AI, but I made desalination "look like" it was improving the terrain itself. Do you ever see AI workers desalinating?
3. You point out a human planning thing, converting a site which is "good, except lousy due to salt" and then building a city there. The planning could start from early game, the conversion could start once you achieve desalination.
4. Even if #2 works, the AI cannot plan ahead like a human for #3. You are suggesting a worker action to "desalinate to *create* a good city site", and leaving a gap in the established cities to allow that later. This kind of planning seems beyond the AI. Maybe, somehow, establishing a weight on performing desalination at certain sites, to prefer desalinating those? Then the city planner would notice later that these sites became good, and build there? The problem would be leaving a big enough gap in the city placement beforehand.
2. The AI may or may not see the benefit of desalination, period. I have not tested this. The actual terrain conversion is in python, so invisible to the AI, but I made desalination "look like" it was improving the terrain itself. Do you ever see AI workers desalinating?
3. You point out a human planning thing, converting a site which is "good, except lousy due to salt" and then building a city there. The planning could start from early game, the conversion could start once you achieve desalination.
4. Even if #2 works, the AI cannot plan ahead like a human for #3. You are suggesting a worker action to "desalinate to *create* a good city site", and leaving a gap in the established cities to allow that later. This kind of planning seems beyond the AI. Maybe, somehow, establishing a weight on performing desalination at certain sites, to prefer desalinating those? Then the city planner would notice later that these sites became good, and build there? The problem would be leaving a big enough gap in the city placement beforehand.
Ahriman
Tyrant
This is not necessarily true. Very often, there is a thin band of salt, maybe only 3-4 tiles in total. A salt tile might have only 2-3 other salt tiles in its BFC, and might be otherwise a great city site.
This is exactly my point: a city founded on a salt tile may well grow much better than a city on an adjacent graben tile, because the former site might have more bonus resources within its BFC.
Your city placement algorithm might correctly identify that a particular salt tile would be a great city site, but because you can't found there the AI founds an inferior city in an adjacent tile instead.
The releveant comparison from vanilla is; jungle is a bad tile with low yields and unhealth, that is eventually convertible to good yields. But vanilla still lets you build a city on a jungle tile, partly to avoid having the AI make really bad city placement because it can't place on jungle.
If needed, I will use Worldbuilder to demonstrate an example tonight.
As an extreme case, imagine a situation where there is a single salt tile, surrounded by 4 groundwater tiles at 1n1w, 1n1e, 1s1w and 1s1e. Buidling on that salt tile would allow all 4 groundwaters inside the BFC. But being unable to build on that salt tile means that you can at best capture 2 of the groundwaters. So any other tile is far inferior.
I agree that this is beyond the AI, this is not what I am suggesting.
What I am literally suggesting is that you just remove the block that prevents a city being founded on salt terrain type.
That way, the normal AI placement algorithm you have developed will be allowed to develop optimally.
No need for any kind of forward planning or anythnig, just better AI city placement with higher growth cities.
davidlallen
Deity
No need to make an example, I see what you mean. I have no objection to this change. It just has nothing to do with the AI. The AI would continue to value these tiles at zero. Both the human and the AI could build cities there if they wanted.
Does anybody else have an opinion about allowing cities on salt?
Does anybody else have an opinion about allowing cities on salt?
Deliverator
Graphical Hackificator
I don't mind us enabling cities on salt. It would be very rare to see good city sites in the middle of big salt pans anyway since no bonus resources are placed on salt. This would mostly be for the salt pans that only cover a small handful of tiles as Ahriman says.
AnotherPacifist
Deity
- Joined
- Sep 21, 2007
- Messages
- 4,878
I don't mind able to build on salt at all. Often I regenerate a start because I have 2-3 salts on my starting point and if I didn't build on site I would have to lose a turn. Some sites (see our current Fremen SG with former Harkonnen cities) are just plain bad, missing groundwater by 1 tile because of salt.
davidlallen
Deity
In the current SG, the initial city placement should be "good" but the colony city placement may be "bad". I added the new code for colony city placement in 1.7.0.4. Are you playing locally with 1.7.0.4 (not in the SG)? I think all city placement should be good in that. If you find bad starts, please send a screenshot. If you are using 1.7.0.4 or later and you see bad colony placement, please send a screenshot along with some thoughts on what you think a better nearby site would have been. This will be helpful feedback to improve the placement algorithm.
Deliverator
Graphical Hackificator
This logic will need to be updated to take account on the new Peak features I added 1.7.0.5. They should have zero plot value. This shouldn't affect placement by the current 1.7.0.4 logic too much since the Peak tiles are infrequent, but it should be coded in at some point.
