[freeciv-ai] Re: New settler code

[Gregory Berkolaiko <Gregory.Berkolaiko@xxxxxxxxxxxx>]

Here are some thoughts:

1. While I think that client AI is not something great, I am completely 
against integration of the AI into the server.  In my opinion the 
structure should be

      judge--
        |    \
     server---AI
    /      
   IP      
   |      
 client    

where judge is the rule-interpreting code and the server deals with data 
storage and distribution.  My reason agianst client AI is that any AI 
needs access to the rules (see CMA for examples), so you either duplicate 
the judge in the client or overload IP-link with requests for judge 
rulings.

But enough of this day-dreaming.  Let's have a look at server_remove_unit.
It calls ai_unit_new_role to tidy up the minimap (settler map withfuture 
cities)!!  So the server is maintaining the AI data structures.  I feel 
this sort of thing is completely unacceptable!

I addition, in Per's code, when server is creating a city, it puts the 
city on the minimap (called settler map) for the AI.  Very bad!

2. Second bad thing is the coordination between different AI's of their 
city-building activities.  This is just not supposed to happen.  Make them 
race against each other!!

From here, if we don't want the server to maintain the data structures for
us (and we don't), AI should update it's settler map (aka minimap) itself.  
And the easiest thing then is to recompute the map every turn.  Yes, it
eats CPU, but not more than danger assessment code for example.

Since the map is recomputed each turn, you can allocate it for the 
duration of the turn for one AI.  Or have one static map and use it in 
turns for all AIs.  The memory issue is solved.

Who will remember the future city spot reservations?  The settlers do
remember them now, so when we compute the map we cycle through all the
cities and through all settlers with AIUNIT_BUILD_CITY roles.

For each tile, we should have 
 * one number saying how many neighbouring cities are making this tile
impossible (this way we just subtract one when a unit withdraws his
reservation of a spot).  Alternatively, we store just one bit but when 
constructing the map, we make sure only to put "confirmed" reservations on 
the map.
 * one number describing "crowdedness" of a tile
 * one bit saying whether this tile is within radius of one of _our_
cities, this will help explorers help the city management.

Side notes:

Management of the AI settlers should be done by AI itself and not 
through auto_settlers from srv_main:1483.  This way we won't have 
to compute the various settler-realted caches twice in one turn for each 
player.

As for the omniscience, I fully agree with Mike, you don't have to have it 
perfect.  Just put some stupid WAG for the unknown tile value guarded by 
an appopriate handicap check.  Then making it clever will involve 
someone writing a more sophisticated estimator basing on map gen 
parameters and the Y coordinate.  But at least we will have a placeholder 
for that.

Best wishes,
G.