[freeciv-ai] Re: New settler code

[Ross Wetmore <rwetmore@xxxxxxxxxxxx>]

Gregory Berkolaiko wrote:
> 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.
I'm with you in principle, but reserve the right to quibble over the details.

> 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!
There is no reason why there cannot be server functions to do all these
things that any AI or client could call. Don't necessarily get hung up
on where the implementation is really done.

But in general, the server should not maintain data structures that the
AI accesses directly. And the client should in principle have the same
ability to access gated by server control parameters. This doesn't mean
any client will always be able to access these APIs, but with appropriate
server permission would have the possibility of doing so.

> 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!!
I have no problem with this. This is just a practical implementation of
AI diplomacy in action :-).

It might be nice to have control variables that govern access to a common
map vs each AI-client maintaining their own.

> > 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.
There is nothing wrong with the server maintaining data structures and
passing them (or some partial/mutated form of them) back to any AI or
client that asks. This may be a very good efficiency technique.

Cloning data is a lot faster then producing it.

> 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.
If autosettlers works for clients, then there is no reason it should not
be usable by server AI as well. Whether it is or not is a matter of choice.

> 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.
I think this is sort of along the right path. Whether one is at the lower end
providing random values, or the upper end providing more or less accurate
ones is only a matter of degree. The degree is commonly called the handicap
level :-).

> Best wishes,
> G.
Cheers,
RossW
=====