[Freeciv-Dev] Re: auto settlers rework

[Raimar Falke <hawk@xxxxxxxxxxxxxxxxxxxxxxx>]

On Mon, Jan 21, 2002 at 11:54:27AM -0500, pc-freeciv1@xxxxxxxxxxxxxx wrote:
> In playing Freeciv, I've run into one thing that I think really should be
> reworked: The auto-settler code.  Looking at the current code, each settler
> looks for work to do.  I think that it would make more sense to instead
> have each city create a list of work that needs to be done, and the
> settlers could seek a city that has work to be done.
> 
> So each city would have a map of what its terrain should look like, given
> unlimited settler time.  It could then assign a value to each change.  The
> overall value for the city would be largest such individual value.  This
> value would need to be recomputed anytime a settler begins work in the
> city.
> 
> Similarly, there would be a value for connecting a city to its neighbors
> with roads or railroads.
> 
> Once the initial change has been made, a new tab could be added to the city
> window showing the goals for the city.  This would be a view of the city
> with all worklist items completed, all settler activity completed, and the
> population maximized (up to a zero or negative one food value).  From here,
> the player could make changes to the goals.  For example, a plains could be
> changed to a grassland to stabilize the population (food value of zero at
> max population), avoid pollution from overproduction, or such.  If the
> worklist includes the construction of units, those units could be given
> orders to sentry, fortify, or auto-attack.
> 
> Eventually, default goals could be created, much like worklists today.  The
> default goals would include things like what to do with swamps (irrigate to
> grasslands or transform to ocean), taking into account specails, such as
> never transforming an oasis.
> 
> The goal should be to be able to create a city and never have to look at it
> again, provided that it is not involved in combat, and yet have the city do
> pretty much exactly what you want it to do.
> 
> Unfortunately, I don't have time to contribute to this, beyond suggesting
> the idea.

You aren't the only one with such ideas. From old emails:

> I finally managed to make a diff of my current tree against the
> current CVS version. The tree contains three agents and a lot of
> supporting code:
> 
>  - city management agent (CMA): this one manages the citizien of a
>  city so that the citizen work on tiles which are most useful to a
>  given goal. It also manages specialists.
> 
>  - goto agent (GA): it is like a normal goto but completely at the
>  client side. It is currently only used to estimate the number of
>  turns to go from one position to another and to actually send
>  settlers from one place to another.
> 
>  - settler management agent (SMA): like the current auto-settler but
>  it will also build new cities. However it is programmed more clearly
>  than the current code in server/ and ai/. So I hope it is (more)
>  understandable. The SMA needs some docu on how the agent works. Also
>  external requests (other parts of the code can suggest actions (like
>  build a road at (45,67) which would not necessary benefit a city)
>  are still open.

and

> The current version [of SMA] also allows the injection of external actions. 
> The
> action generation will never produce action which would yield nothing
> (a fortess for example) since it can't weight how much (food, trade,
> shield) a fortess is worth. However there may other parts (other
> agents like a defense agent of a city [or a human user]) of the code which 
> know how much
> terrain improvement can be sacrifice to build this fortess. So these
> agents can inject a fortress action. This action would have some
> artifical yields attached. These are considered if a settler have to
> choose which action to carry out next.

The CMA will be part of the next release. The other agents will
hopefully follow.

        Raimar

-- 
 email: rf13@xxxxxxxxxxxxxxxxx
 "I do feel kind of sorry for Microsoft. Their attornies and marketing
  force must have tons of ulcers trying to figure out how to beat (not
  just co-exist with) a product that has no clearly defined (read
  suable) human owner, and that changes on an hourly basis like the
  sea changes the layout of the sand on a beach. Severely tough to
  fight something like that."
    -- David D.W. Downey at linux-kernel