Complete.Org: Mailing Lists: Archives: freeciv-ai: May 2002:
[freeciv-ai] Re: ai bug when splitting up settlers

[freeciv-ai] Re: ai bug when splitting up settlers

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: "Per I. Mathisen" <Per.Inge.Mathisen@xxxxxxxxxxx>
Cc: freeciv-ai@xxxxxxxxxxx
Subject: [freeciv-ai] Re: ai bug when splitting up settlers
From: Raimar Falke <hawk@xxxxxxxxxxxxxxxxxxxxxxx>
Date: Tue, 14 May 2002 11:13:01 +0200
Reply-to: rf13@xxxxxxxxxxxxxxxxxxxxxx

On Mon, May 13, 2002 at 02:35:36PM +0200, Per I. Mathisen wrote:
> On Mon, 13 May 2002, Raahul Kumar wrote:

> Syela's general idea is correct - we should calculate the benefit a
> new city can give us.

> > We could build workers based on the minimap idea you had. The workers we 
> > need
> > is based on no of umimproved tiles in city radiuses, the amount of time it
> > would take the workers we currently have to improve them, aargh it gets hard
> > already.
> Yes, it becomes hard. The above is about the same approach as Syela chose.

I also think that this is the correct approach. You have to calculate
how much you would gain from an extra worker. A fast approximation
would to virtually allocate the not yet produced worker to the city
tile which will improve the most and compare the costs (shields, time
to produce, time to improve) with the benefit (extra production of the
tile, an extra worker (in the worst case it is still worth half the
production shield)). If this turns out negative and also the same
checks for all the near cities you shouldn't build the worker. This is
an approximation because the best tile may be allocated and so
improved before the unit is produced. You can now make a more detailed
calculation which tiles can be improved in n turns (where n is the
number to build the unit) but this may be hard.


 email: rf13@xxxxxxxxxxxxxxxxx
 "Python is executable pseudocode. Perl is executable line noise"
    -- Bruce Eckel

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