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

["Per I. Mathisen" <Per.Inge.Mathisen@xxxxxxxxxxx>]

On Tue, 14 May 2002, Raimar Falke wrote:
> > 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.

No. The idea is that each AI has its own implementation of the citymap
(minimap). They do not communicate their citymaps with anyone else. You
should not put caches in savegames. When you load a game, you can just
recalculate the citymap. So no new packets.

(Of course, that means all server-side AIs will share one citymap since
they have one instance of common/ in common. But it also means this new
minimap is a mere plugin replacement for the existing minimap.)

(Yes, this will lead to autogame differences pre and post saving and
loading a game, but I see this as unavoidable for more advanced AIs,
unless we save complete state in the savegame, which to me sounds like
total and unfeasible overkill. We also already have this problem. Eg
existing minimap is not saved to savegame. Remember, these caches can be
very big.)

> And attributes are invented for this kind of stuff.

The server does not have attributes. I also want to fix server-side AI.

> There are two attributes are attached to each tile:

I'm only talking about a minimap for cities now. I think we can and should
keep the two separate.

Can you please comment on the interface I posted, and tell me if you can
use such a minimap for CMA?

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

Of course. But what is the algorithm you suggest for amortizing the value
of more distant city spots? This is impossible to do comprehensively
(since you must calculate what you do in future turns to know how much a
delay early in the game will hurt you).

Let me suggest an approximation: Take the loss of prod/tax/science from
the city you could have settled closer, multiply it by (the extra number
of moves to get to the more distant spot + 10), if this is > than the
prod/tax/science from the more distant city multiplied by 10, then
travelling further is beneficial. 10 (or whatever number is sensible, 10
is just a guess) is an arbitrary number, but without any arbitrary and
hardcoded numbers, you will create hell for the CPU and totally Syela
code.

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

Yes, it is nice, easy, and wrong :-)

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

Ok. You intend to do this on a higher level, I suppose.

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

The mail archive keeps giving me 404s on everything I try to read from
that time period, including the SMA and map decoration patches.

Raimar, can you resend both to the list, please?

Yours,
Per

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