This an overall design for auto-settlers. This considers only worker actions (actions that may be taken by the server on behalf of human players), not AI settler actions (although the term "settler" may be used to mean worker unit).
The ultimate design should:
- Achieve minimal latency. Not only should we bring the worker to the tile ASAP (to have low latency on tile upgrades, particularly pollution cleanup), but we should find the closest tile for the worker (to have short client-side worker animation times).
- Provide ultimately optimal results. It's not as important to optimize micromanaged actions as it is to avoid regression. The human who activates autosettlers is willing to sacrifice some performance, so long as (s)he sees steady achievement by the autosettler. Basically this means the autosettler should only work along an optimal upgrade path. There may be more than one such "optimal" path but there should never be flip-flopping between results (terrains) or moving toward an unoptimal result.
- Not be limited by the current city status. This could be the hardest requirement to fulfill. Example 1 - tiles that are not in use should also be upgraded. Example 2 - tiles of a city without a supermarket should have farmland built even though this won't get any immediate result. Example 3 - forest and hill tiles should still have roads built, even though this gives no benefit until railroad is discovered. In all these cases these types of work may get a reduced priority, but they should all be done rather than have the worker sit idle.
For the AI, it should be sufficient to consider the above plus a few 'extra' AI actions (like connecting cities by roads, founding new cities, and building fortresses). So the AI can probably reuse the human autosettler code, and just requires additional checks to look for behavior that would not normally be automated.
