Complete.Org: Mailing Lists: Archives: freeciv-ai: May 2002:
[freeciv-ai] Re: Generalised improvements AI support

[freeciv-ai] Re: Generalised improvements AI support

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: Freeciv-ai <freeciv-ai@xxxxxxxxxxx>
Subject: [freeciv-ai] Re: Generalised improvements AI support
From: Ben Webb <ben@xxxxxxxxxxxxxxxxxxxxxx>
Date: Mon, 6 May 2002 21:23:36 +0100

On Mon, May 06, 2002 at 09:19:45PM +0200, Per I. Mathisen wrote:
> 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

From doc/README.impr-gen:-

 - Not all effects are currently implemented:
   - Enemy_Peaceful, Improve_Rep and May_Declare_War involve diplomacy,
     which is not yet fully supported by Freeciv.
   - Barb_Attack, Barb_Defend, Slow_Nuke_Winter, Slow_Global_Warm and
     Trade_Route_Pct are not yet coded for, but are not used in standard
     Freeciv rulesets anyway.
   - I'm not sure what Capital_Exists was intended to do...

        Some of the effects currently in Freeciv CVS don't work either,
but that's because I removed them while writing the code. I think the
only one I got rid of was Reduce_Waste (but Freeciv doesn't currently
do Waste anyway).

        Island- and World-range effects behave a little oddly from the
client's point of view in some circumstances, but that's only a symptom
of an existing problem (client and server acting on different information).
Basically, World-range effects from non-Wonders can be confusing, because
other players can't see what's causing the effect, while Island-range
effects can influence what to the client appears to be two different
islands, while the server knows them to actually be one, connected by
a piece of land that the client hasn't explored yet. It's only because
neither scenario pops up in the standard rules that this hasn't become
a problem to date.

        I haven't tested all combinations of effects and ranges, so I'm
sure some bugs may pop up there. Some of the effects I've fixed at
ranges that seemed sensible to me, which may perhaps make them less
flexible than they should be. (For example, Any_Government and
No_Anarchy are fixed at Player range. I suppose they should also work
at World range, but City- or Island-range doesn't make any sense to me.)

> and what remains to be done to make them work?

        Well, the first three require the AI to understand diplomacy. The
next group should be trivial; I just haven't got round to them yet, since
they're not used anywhere. I think Capital_Exists should be removed.

> Some of the effects also need better documentation.

        This is true. In particular the buildings.ruleset currently in
CVS is rather confusing about which bonuses are additive, and which are
multiplicative. My patches have addressed this to some degree, but there
are still oddities that I need to clean up.

> /* 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);

        I was just thinking of something similar for the former - cloning
the city is a nice way to be able to use the functions in common/, but am
not quite sure what you're driving at with the latter. impr-gen doesn't
distinguish between buildings and wonders at all, so it's entirely
possible that an ordinary building can affect multiple cities. This
_should_ make Civ3-style mini-Wonders trivial to implement. Ideally,
the AI should be able to treat Wonders and buildings in a very similar
fashion, just with some extra code to deal with Caravans and the like
for Wonders.

        It'd be fairly straightforward to clone a list of cities which
would be affected by a building being constructed in a given city.

> 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);

        These are trivial to code (but useful to have, of course) as
impr-gen stores all of these bonuses in the pcity structure already.

> int compare_cities_defense_barb(pcity, acity);
> int compare_cities_defense_diplo(pcity, acity);

        impr-gen currently has no support for defense against diplomats,
and I haven't coded the DEFEND_BARB effects either. I'm thinking of
replacing the current unit_class_id with something a bit more general,
that encompases all of the unit flags rather than just the current
F_MISSILE and F_NUCLEAR. That'll enable you to tweak defence modifiers
against any kind of unit (which, as Raahul mentioned to me earlier,
would be handy for extending the impr-gen effects to units, so that
the whole Aegis/Pikemen/Horse/etc/etc stuff can be taken out into the

> /* 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.

Yes, I think that could work. I will have to think some more about it though.

> (We should also "reverse amortize" want value for buildings that become
> obsolete by calculated time to obsoletion.

        Indeed, or choose research priorities to delay the obsoletion if
the building/Wonder already exists (I don't know if the AI does this

> This should be merged into my ai_eval_wall|sdi|sam|costal patch.

Can you remind me of the URL for this?

> Currently the AI just gives these buildings a lame constant value

Yes, I noticed that. ;)

> which it does many strange multiplications of later depending on danger.

Ah, so it's not just me. I thought I was going mad.

> > - 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
> 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.

        Well, I imagined that the AI would send damaged units to cities
with Barracks or Ports, or not bother quite so much if it had United Nations,
and build Barracks and Ports in front-line cities. This would require
evaluation of (potential) Unit_Repair and Unit_Recover effects.

"640K ought to be enough for anybody."
        - Bill Gates, 1981

[Prev in Thread] Current Thread [Next in Thread]