[freeciv-ai] Re: Settler fixes [Was: A better AI Eval buildings 1.1]

[Raimar Falke <hawk@xxxxxxxxxxxxxxxxxxxxxxx>]

On Tue, May 14, 2002 at 05:30:06PM +0200, Per I. Mathisen wrote:
> On Tue, 14 May 2002, Raimar Falke wrote:
> > > I hope you use something akin to the minimap to ensure that two settlers
> > > don't go for the same city spot.
> >
> > Of course. Implemented via the attributes.
> 
> I don't think that is a good idea. I'd rather make a minimap
> implementation in common code. That way the server-side AI can use it,
> too. I gave this a few thoughts while cleaning up settlers.c

But this would need a lot of extra work (packets, savegame, ...) with
no benefit. And attributes are invented for this kind of stuff.

> Here is suggestion for implementation (I can probably code it and put it
> in common/ai/citymap.c in a few hours coding time if desired):
> 
> /**** internal data ****/

There are two attributes are attached to each tile:

+enum settler_action_type {
+  ACTION_BUILD_CITY, ACTION_ADD_TO_CITY, ACTION_ROAD, ACTION_RAILROAD,
+  ACTION_MINE, ACTION_IRRIGATE, ACTION_FARMLAND, ACTION_TRANSFORM,
+  ACTION_FORTRESS, ACTION_AIRBASE, ACTION_POLLUTION, ACTION_FALLOUT
+};
+
+#define MAX_ACTIONS_PER_TILE 10
+
+struct tile_actions {
+  short int entries_used;
+  struct tile_action {
+    short int unit_id;
+    enum settler_action_type action_type;
+  } entries[MAX_ACTIONS_PER_TILE];
+};

and

+struct tile_reservation_for_city_building {
+  short int unit_id, as_center;
+};

> > > But I think you can, if the area explored is just big enough. And "big
> > > enough" is not very much, just an area of, say, 6x6 (less so in the
> > > beginning). Because the cost of travelling across a larger distance than
> > > that to settle in a slight better spot is much higher than the benefit.
> >
> > You can't guarantee this for every possible ruleset.
> 
> Why not? Take a desert world. We find our two starting positions, but
> nothing more, for a long while. Then we find a crap place. We evaluate it
> and store the want value, finding it wanting (pun). Then even later we
> find a good place, evaluate it, store and send out a settler.

I was refereeing to "Because the cost of travelling across a larger
distance than that to settle in a slight better spot is much higher
than the benefit.". The problem here is "a larger distance" and
"slight better spot". You just can't hardcode these values (as the
current AI does) because they depend on the ruleset.

> > However in the
> > current SMA code (which uses a linear amortization) you can abort the
> > path finding if you take more than MORT turns to reach the tile.
> 
> But why would we want to do that. The settler code should be able to
> function even in a desert world where the next city is, say, 30 tiles
> away.

Linear amortization is on the list of things which have to
reconsidered. However it is a very nice and easy model.

> Also, how do you solve island-hopping (settling new continents)?

I don't. One agent for one purpose. It is the same reason that the CMA
don't do multi city optimization.

> > > The ideal settler will find good spot nearby, and make roads on any
> > > grassland/plain tiles used on the way there. This is because roads are
> > > both extremely important to get science and
> >
> > > they are cheap to make.
> >
> > What if the best tile (the one which is used in addition to the
> > center) is not on the path?
> 
> Too bad. This bonus feature does not kick in.

> > Then you would have to wait till the city
> > grows to size 2 to get the benefit from this road. What if the tiles
> > in the path are used if the city grows to size n?
> 
> Only do this for _used_ tiles. We don't want to waste valuable settler
> time on unused tiles. Rule is "if you are a settler on your way somewhere
> and pass through a grassland or plain which is being used by one of your
> cities and it does not have a road, build one". When we can afford it, we
> can build settlers with express intent of improving terrain more
> generally.
> 
> > So it isn't easy to calculate this and in the current version the SMA
> > will split these actions.
> 
> Good.

You are free to combine this.

> > The latest SMA version is from last Sep. It is complete but contains
> > some approximation (very easy city model for city founding, linear
> > amortize) which may need to improved. Missing is the GUI. And this GUI
> > will be more complex then the CMA one.
> 
> Ouch! CMA is already very complex. (BTW, while I remember it, 

> CMA should have the possibility to set "default" CMA for new
> cities.)

Ack.

> > The GUI will also need the map
> > decorations patch so that you can visualize the actions and paths.
> 
> Where is this patch? Or do you mean the map markers patch?

It was posted 20 Oct 2001 under the subject "[Patch] Map
decoration". You see this patch also needs an update.

        Raimar

-- 
 email: rf13@xxxxxxxxxxxxxxxxx
 "The BeOS takes the best features from the major operating systems. 
  It's got the power and flexibility of Unix, the interface and ease 
  of use of the MacOS, and Minesweeper from Windows."