Complete.Org: Mailing Lists: Archives: freeciv-dev: January 2002:
[Freeciv-Dev] Re: CSS was: Re: auto settlers rework
Home

[Freeciv-Dev] Re: CSS was: Re: auto settlers rework

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: Christian Knoke <ChrisK@xxxxxxxx>
Cc: freeciv-dev@xxxxxxxxxxx
Subject: [Freeciv-Dev] Re: CSS was: Re: auto settlers rework
From: Raimar Falke <hawk@xxxxxxxxxxxxxxxxxxxxxxx>
Date: Tue, 22 Jan 2002 20:36:09 +0100
Reply-to: rf13@xxxxxxxxxxxxxxxxxxxxxx

On Tue, Jan 22, 2002 at 07:04:38PM +0100, Christian Knoke wrote:
> 
> [On strategies for Settler Management Agents]
> 
> When you are taking these considerations, you get a strong impression 
> that things are in fact even more complicated than this.
> 
> Examples:
> 
> On Tue, Jan 22, 2002 at 01:14:33PM +0100, Raimar Falke wrote:
> > On Tue, Jan 22, 2002 at 04:06:20AM -0500, Jason Short wrote:
> > > Raimar Falke wrote:
> > > 
> > > > On Mon, Jan 21, 2002 at 01:05:10PM -0500, Ashley Penney wrote:
> > > > 
> [...]
> > > > The only way AFAIK is to increase the time horizon of the
> > > > calculation. The current server auto-settler code is based on 24 turns
> > > > (the famous MORT constant). This means that the action which would
> > > > yield the most benefit in the next 24 turns is considered.
> 

> The time horizon is not linear. Things I can achieve (points I can get)
> earlier in the game are more valueable than things I get later.

 - benefit isn't always linear: a founded city may grow in the time
 horizon and so create non-linear benefit. This is a known problem of
 the SMA. It is just a difficult problem: you have to simulate a
 virtual city. You may use the CMA for this but the SMA won't know the
 CMA parameters and the CMA and almost all of the other functions work
 only on real cities and not on virtual ones.

 - the actions are compared against each other and not against a
 certain limit so I don't see a problem of changing value. You may
 want to change the weights for the attributes (food,...,tax) during
 the time. But this isn't part of the SMA.

> > > > Example:
> [...]
> > > > So the total benefit of the second will increase with a larger time
> > > > horizon.
> 
> Maybe you don't live long enough to encounter this. (e.g. you are under
> attack)

Yes.

> [...]
> > > It also doesn't account for the goodness of building a 
> > > city (although it could try, if we can somehow assign a "benefit" value 
> > > to the city).
> > 
> > The current SMA code has this. It will build cities like mad. It is
> > just the best choice if you have the tiles available. Even if you
> > account the shields you loss if you disband the settler.
> 
> Important point. Whether it's a good thing to build cities depends a lot,
> e.g. on you overall strategy (ICS or not), the ability to defend your
> territory, the distance of your cities a.s.o.

The SMA currently supports a min_distance, max_distance,
minimal_defense_bonus and minimal surplus for all 6 attributes for
city building actions. Adding extra constrains isn't the problem.

> > > Finally, it doesn't account for different resources having different
> > > values; everything is heaped into one "benefit" value (although this
> > > could be changed).
> > 
> > The user of the the current SMA has to provide weights for this.
> 
> Well, which weights? What kind of ressources are important can change,
> e.g. when your cities grow, or when you're getting more/less settlers,
> or whether you concentrate on research or production.

Weights for FOOD, SHIELD and TRADE (maybe I should add
POLLUTION).

> > > It is also extraordinarily difficult to account for dependencies among 
> > > improvements.  For instance, you have to do primary irrigation before 
> [...]
> > Managing the settlers as a whole may get better results. But I see an
> > drastic increase in CPU time.
> 
> Some cities may want food, others shields. So 2 settlers are doing the work,
> instead of the (neighbouring) cities just exchange a (used) grass tile with 
> a (used) mined hill tile? >:->  Interaction with the CMA is requiered here.

As little interaction as possible. I would prefer to add another
layer/agent on top of these which changed the weights according to
some algo. But I agree it should be possible to add extra city
depending weights.

> Conclusions:
> 
> Agents will change the gameplay. This is not bad. But maybe they reduce
> the number of strategies/ways to play a game, because they are based
> on strategic implications (which may or may not be true).

IMHO there should be no policy in the agents. This means for example
that all numbers which may vary should be supplied by the user.

> They need to interact with each other. 

See above.

> The agents do the work, but the user does the politics.

Yes.

> What I want to suggest is to embed the agents into some sort of 
> client side scripting (CSS). 
> 
> CSS could give the above goals.
> 
> CSS can move the agent developement from the shoulders of few to the
> shoulders of many (users!)
> 
> CSS can be a way to achieve client side AI. 
> 
> CSS is a step forward to client side translation, which is a good thing,
> too.

Agents won't have to be written in C. But the basic agents we discuss
now (CMA, SMA, goto agent, exploring agent,...) have to be written in
C or would else need a 10GHz CPU.

        Raimar

-- 
 email: rf13@xxxxxxxxxxxxxxxxx
 "This is Linux Country. On a quiet night, you can hear Windows reboot."


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