Complete.Org: Mailing Lists: Archives: freeciv-dev: March 2002:
[Freeciv-Dev] Re: [Wishlist] Attitude manager (agent and AI)
Home

[Freeciv-Dev] Re: [Wishlist] Attitude manager (agent and AI)

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: Gregory Berkolaiko <Gregory.Berkolaiko@xxxxxxxxxxxx>
Cc: freeciv-dev@xxxxxxxxxxx
Subject: [Freeciv-Dev] Re: [Wishlist] Attitude manager (agent and AI)
From: Raimar Falke <hawk@xxxxxxxxxxxxxxxxxxxxxxx>
Date: Mon, 4 Mar 2002 19:41:00 +0100
Reply-to: rf13@xxxxxxxxxxxxxxxxxxxxxx

On Mon, Mar 04, 2002 at 05:42:25PM +0000, Gregory Berkolaiko wrote:
> On Mon, 4 Mar 2002, Raimar Falke wrote:
> 
> > On Mon, Mar 04, 2002 at 12:11:28PM +0000, Gregory Berkolaiko wrote:
> > > This is related to an earlier email by Raimar.  He was talking about
> > > displaying the effect a building like Marketplace would have.  Well,
> > > Marketplace is an easy one to estimate for anyone (incl. AI) who knows
> > > about the notion of "percent".  But the effect of, say, Cathedral, is more
> > > involved.
> > 
> > Maybe you have misunderstood me. I don't want to do something like
> 
> I didn't discuss the _way_ you would implement it, I merely said that 
> evaluating Marketplace (in the curresnt ruleset) is an easy problem for a 
> numerate user.  Admittedly, I did not think about generalised rulesets.
> 
> Speaking about _way_ of implementing it, the second way is much cleverer.  
> For some buildings, that is.  See below.

Ack. Interfaces are important. Implementation is second.

> >   gold_of_marketplace = gold_multiplicator * base_gold
> > I want to do something like
> >   memcpy(backup, pcity);
> >   pcity->improvements[i]=1;
> >   refresh_city(pcity);
> >   y = create_diff(backup, pcity);
> >   memcpy(pcity, backup);
> > 
> > The first will lead to code duplication. The second will also work if
> > the code doesn't know about the latest effect.
> > 
> > In general I would a function like:
> >   k = get_diff(pcity, B_MARKETPLACE, GOLD);
> > would be ok. It doesn't matter how it is implemented.
> > 
> > > So I would suggest the following extension to the CMA: once the
> > > target multipliers are set, you should be able to evaluate the
> > > effect of building a happiness-related improvement.  It would output
> > > (for user) the increase in surpluses you'd be able to get (maybe
> > > minus the cost of the upkeep).  And for AI you just need to combine
> > > the values of increases multiplied by their _WEIGHTINGs
> > 
> > I don't know how this relates to CMA and I don't know what target
> > multipliers you mean.

> Now let's consider evaluating impact of a Cathedral.  The algorithm number
> 2 above will not give us anything useful (unless the whole city changes
> it's happiness status).

I don't see a big problem in creating a happiness surplus value based
on the ppl_* arrays.

> Why?  Because the prime purpose of the Cathedral is to allow us to
> send Elvises to work in the field (Cultural Revolution sort of
> thing).  And that requires a bit more consideration than
> refresh_city.  How would the freed workers be put?  What are our
> production targets?  This is the knowledge that CMA possesses.  So
> instead of refresh_city above, you would call cma_refresh_city for
> happiness-related buildings.

I had similar problem in the SMA (settler management agent). If you
plan to build a city you have to estimate the output of it. For this
you have to have something like a CMA (but for virtual cities).

> As for "target multipliers", how do you call those coefficients that you 
> set in CMA?

Factors or weights.

        Raimar

-- 
 email: rf13@xxxxxxxxxxxxxxxxx
 "A common mistake that people make, when trying to design 
  something completely foolproof is to underestimate the 
  ingenuity of complete fools."
    -- Douglas Adams in Mostly Harmless


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