Complete.Org: Mailing Lists: Archives: freeciv-ai: May 2002:
[freeciv-ai] Re: Settler fixes [Was: A better AI Eval buildings 1.1]

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

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: <freeciv-ai@xxxxxxxxxxx>
Subject: [freeciv-ai] Re: Settler fixes [Was: A better AI Eval buildings 1.1]
From: "Per I. Mathisen" <Per.Inge.Mathisen@xxxxxxxxxxx>
Date: Tue, 14 May 2002 17:30:06 +0200 (MEST)

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

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

/* if positive, stores a value to cache (what kind of value, eg city
desirability or tile desirability, is implementation defined); or, a
city/unit id, if negative. goes without saying that want values cannot be
negative then */
static int citymap[mapx][mapy];

/**** public interface ****/

void citymap_init(); /* call memset */
void citymap_done();

int citymap_cache_read(x,y);

#define citymap_is_reserved(x,y) (citymap_cache_read(x,y) < 0)

int citymap_cache_write(x,y,value);
/* assert(value > 0 && !citymap_is_reserved(x,y)); */

int citymap_reserve_city_spot(x,y,settler_unit_id);
/* assert(!citymap_is_reserved(x,y)); this function reserves
an area equal to city_min_dist radius around the spot with
settler's unit_id; if a tile is already reserved, in which
case it is not touched */

int citymap_free_city_spot(x,y,settler_unit_id);
/* assert(-citymap[x][y] == settler_unit_id); reverse the above */

void citymap_reserve_tile(x,y,settler_unit_id);
/* assert(!citymap_is_reserved(x,y)); reserve additional tiles if
desired (eg I would reserve best available food tile in addition, and
server-side likes to reserve everything in city radii) */

void citymap_unreserve_tile(x,y,settler_unit_id);
/* assert(-citymap[x][y] == settler_unit_id); reverse the above */

/**** common/ only interface ****/

void citymap_place_city(x,y,city_id);
/* assert(!citymap_is_reserved(x,y)); as reserve_city_spot */

void citymap_remove_city(x,y,city_id);
/* assert(-citymap[x][y] == city_id); reverse the above */

void citymap_work_tile(x,y,city_id);
/* if tile we assign workers to is _not_ reserved by anyone, reserve it
now so nobody thinks it is available for city building. called
automatically by worker assignment code */

void citymap_unwork_tile(x,y,city_id);
/* free tile only if we actually reserved it. called automatically by
worker assignment code */

/***** interface end ****/

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

> 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. Also, how do you solve island-hopping (settling new continents)?

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

> So it isn't easy to calculate this and in the current version the SMA
> will split these actions.


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

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


"As Israeli forces pursued militants, civilians
continued getting in the way and dying as a
result." -- New York Times, April 21

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