Complete.Org: Mailing Lists: Archives: freeciv-ai: November 2003:
[freeciv-ai] Re: (PR#6595) Optimize/reimplement CM

[freeciv-ai] Re: (PR#6595) Optimize/reimplement CM

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: undisclosed-recipients: ;
Subject: [freeciv-ai] Re: (PR#6595) Optimize/reimplement CM
From: "Raimar Falke" <i-freeciv-lists@xxxxxxxxxxxxx>
Date: Tue, 11 Nov 2003 13:46:47 -0800
Reply-to: rt@xxxxxxxxxxx

<URL: >

On Tue, Nov 11, 2003 at 12:43:35PM -0800, Guest wrote:
> <URL: >
> > I don't favor such a way. Maybe this produce better results in the
> > long run the maintainability is reduced by such huge amount of
> > interconnected code which also will have to hold state. IMHO one
> > reason why the adaption of the CMA/CM to the server was rather quick
> > and painless that it doesn't hold state and has a simple
> > you-ask-I-answer interface.
> > 
> > So build another module on top of CM which adjusts the weights in a
> > smart way to use the foodbox as buffer.
> > 
> >     Raimar
> If we can assume (or if we choose to ignore other possibilities) that
> the optimal solution is a combination of only two sets of tile usages,
> one of which has negative food growth, then we can get away with a
> simple trick. We simply use the set with negative food growth as long as
> this will not result in starvation. At this point we switch to the
> other, and then switch back. If we feel this is risky (what if the
> available tiles suddenly changes and we don't have those food producing
> tiles available when we need to change?), we can to it the other way
> round. Use the set with positive food growth as long as it doesn't make
> the city grown, at that point switch the the other, and then switch back.
> For example, in the above example, use 3f/3t + 0f/5t as long as the city
> doesn't starve, then switch to 3f/3t + 5f/0t, and then switch back. Or
> the other way round.

This is reasonable and I agree.

> I would prefer to remember the "other" set of tiles to use rather than
> recalculate them whenever we want to switch, but this is not a big deal.
> Maybe we need to recalculate anyway because some tiles have changed.
> If such an approach can work with more than two sets of tiles for
> optimal usage, I'm not sure. I would have to think about that a bit, if
> we feel it is worth considering.

There are a lot of factors which change a city. An incomplete list:
 - tax rate change
 - city size change
 - tile available status changes:
   * other city grabs the tile
   * enemy unit grabs the tile
 - terrain changes
 - improvement changes in city
 - improvement changes in other city (building a wonder)
 - changing the amount or kind of the supported units
 - position of the supporting units
 - change in a city you have a traderoute with
 - change of the player government

All of these and probably some other events invalidate the plan you
may have remembered. So I think it isn't a good idea to rely on the
fact that you can switch to the other set of tiles in 3 turns.

I would rather teach the code to recognize that a certain result (of
the CM calculation) gives a _lot_ of shields but has -1 food
problem. Then the code may switch to it. At a certain safety limit (n
turns till size decrease) it would abandon this plan. If the cities
are near it is possible at this time that the other cities grabbed all
good food tiles and the city can't do much. Here you would have to
rehome settlers or something.


 email: rf13@xxxxxxxxxxxxxxxxx
 "I was dead ... but I'm better now."
    -- Capitain Sheridan in Babylon 5

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