[freeciv-ai] Re: Generalised improvements AI support

["Per I. Mathisen" <Per.Inge.Mathisen@xxxxxxxxxxx>]

On Mon, 6 May 2002, Ben Webb wrote:
>       Most of the existing building types now "work" with the impr-gen
> code.

Which of the effects do _not_ work, and what remains to be done to make
them work?

I know about "Improve_Rep" - it should be removed. Some of the effects
also need better documentation.

> However, I haven't touched the AI yet, so presumably it'll still
> go merrily on its way with its own ideas of what each building does,
> no matter how you configure your buildings.ruleset. I'm also told, however,
> that a lot of the code is buggy, so I don't want to waste my time
> trying to convert it to use impr-gen if it doesn't do anything useful
> in the first place, or if you're planning to rewrite it soon.

We should rewrite it, not continue kludging it like Andi did. My immediate
thoughts about an interface would be something akin to this:

/** This goes in a Building Evaluation Agent or something **/

/* Create a virtual city out of pcity. If building has any effects that
   we can measure, then add effects of building, and reallocate specialists
   and workers in virtual city for optimal placement */
struct city *clone_city_with_building(pcity, building);

/* Clone a list of cities with given building, for wonders.
   Calls clone_city_with_building for each city. */
struct city_list *clone_city_list(citylist, building);

/* Utility functions (we ignore the possibility of wonders that improve
   enemy and allied cities also for now) */
struct city_list *clone_player_cities_on_continent(pplayer, continent);
struct city_list *clone_player_cities(pplayer);

/* Comparison functions. Don't compare happiness since that is a
   side-effect of the other variables and it doesn't really give
   us anything if we don't have a problem with it. */
int compare_cities_food(pcity, acity);
int compare_cities_luxury(pcity, acity);
int compare_cities_science(pcity, acity);
int compare_cities_tax(pcity, acity);
int compare_cities_shields(pcity, acity);
int compare_cities_defense_land(pcity, acity);
int compare_cities_defense_air(pcity, acity);
int compare_cities_defense_sea(pcity, acity);
int compare_cities_defense_barb(pcity, acity);
int compare_cities_defense_diplo(pcity, acity);

/** This is added to common/city.h **/

 struct ai_city {
   ...
   struct ai_choice choice; /* to spend gold in the right place only */
+  int choice_age;
+  bool choice_valid;
   ...
 }

/** This replaces function in ai/advdomestic.c **/

/* Clone cities under area of effect, then run compare_cities_* on them,
   and calculate want of all special cases. If ai_city->choice contains
   a valid value, then increase ai_city->choice_age, and return
   ai_city->choice instead of doing any calculations, as long as
   ai_city->choice_age is less than X and ai_city->choice_valid is TRUE.

   ai_city->choice_valid is set to FALSE whenever city grows, changes
   hands or builds an improvement. */
struct choice *ai_evaluate_building(pplayer, pcity, building);

I _think_ this is the best way of doing it, and the cacheing done above
should be sufficient to offset the heavy CPU usage.

(We should also "reverse amortize" want value for buildings that become
obsolete by calculated time to obsoletion. To get this value we need to
store a variable pplayer->time_to_invention, which is time it took to
reach last advance. Time to reach advance X is probably
advances_to_reach_X * time_to_invention, since while research cost
increases, so does our bulb production, and my impression from many games
is that time_to_invention remains roughly the same over a large span of
time because of this. This is kind of unrelated to gen. impr., but while
we are talking about doing things correctly, we might as well fix this.)

> More specifically:
>
> - A lot of the functions from common/city.c seem to be duplicated in the
>   AI code, e.g. pollution_benefit and ai_eval_buildings in ai/advdomestic.c.
>   Is there any work underway to unify this code? impr-gen already contains
>   replacements for the various functions in common/city.c, and I'd like
>   to avoid perpetuating this code duplication if possible.

Agreed.

> - I've heard that a lot of the danger code is a bit suspect. Is there
>   any work ongoing in this area? For impr-gen I obviously want to get rid
>   of any explicit checks for the B_CITY improvement. I want to replace
>   these with checks for the Unit_Defend effect, but as this is rather more
>   general (Unit_Defend encompasses City Walls, Great Wall, SDI, Coastal
>   Defense) the code would require generalising at the same time.

This should be merged into my ai_eval_wall|sdi|sam|costal patch. Currently
the AI just gives these buildings a lame constant value, which it does
many strange multiplications of later depending on danger. I think this
danger multiplication should be moved earlier, into the ai_eval_*
functions.

> - The current impr-gen code is largely concerned with the effects of
>   improvements that exist now. With the AI, I'd imagine that a lot of
>   the time you're wanting to look at the effects of improvements that
>   don't exist yet (so that you can decide what to build, whether a
>   unit will become vulnerable if you move to x,y, etc.). This can be
>   rather CPU intensive, as you have to check for prerequisites of each
>   effect. Can anybody point me towards specific chunks of AI code that
>   require this kind of lookahead, so that I can look into optimising
>   the impr-gen code for it? (I'm aware that the functions
>   in ai/advdomestic.c don't completely duplicate common/city.c because
>   they have to consider the effects of to-be-constructed buildings; I'm
>   thinking of other instances, e.g. in the combat code.)

I'm not sure what you are thinking about here. The combat code doesn't,
AFAIK, do much with buildings other than Barracks and Ports and
Magellan/Lighthouse.

The big problem with look-ahead (which I didn't attempt to solve in the
interface sketched above), is calculating want for techs depending on what
buildings you get. This might be so hard we should just add ai hints to
the buildings ruleset instead of doing any calculations with
not-yet-available buildings. I don't know.

> - What kinds of functions would be most useful to you? Ideally I'd like
>   to keep the amount of impr-gen code in the AI to a minimum, so would
>   be more interested in writing general-purpose utility functions for
>   use by the AI. I guess there must be a need for functions to find
>   repair facilities and/or good defensive cities for units, for a start.

Yes. The newly written code should useful both to client and server AIs.

> - I was meaning to extract the impr-gen-AI stuff from Andi's patch, and
>   update it to work with the more recent impr-gen patches, but wasn't
>   very happy with some of the code in there. (In particular, it seems
>   to strive too hard to reproduce the existing AI behaviour, rather
>   than applying impr-gen effects "properly".) In the end, I didn't get
>   round to doing this. If there's interest from the list, however,
>   I should be able to produce something usable.

I've also been looking at this, and I too found it wanting.

Yours,
Per

"There are 10 types of people in the world. Those who understand binary
and those who don't."