Complete.Org: Mailing Lists: Archives: freeciv-ai: May 2004:
[freeciv-ai] Re: [RFC] (PR#8805) Cleaning up build system
Home

[freeciv-ai] Re: [RFC] (PR#8805) Cleaning up build system

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: undisclosed-recipients: ;
Subject: [freeciv-ai] Re: [RFC] (PR#8805) Cleaning up build system
From: "Gregory Berkolaiko" <Gregory.Berkolaiko@xxxxxxxxxxxxx>
Date: Mon, 24 May 2004 11:28:25 -0700
Reply-to: rt@xxxxxxxxxxx

<URL: http://rt.freeciv.org/Ticket/Display.html?id=8805 >

On Sun, 23 May 2004, Jason Short wrote:

> <URL: http://rt.freeciv.org/Ticket/Display.html?id=8805 >
> 
> > Data structure:
> > ==============
> > 
> > struct ai_choice {
> >   int want;     /* Numerical value, scale not fixed */
> 
> But the scale has to be the same for all choices, right?

Roughly the same, although it's hard to compare plums with oranges.  What 
I meant here is more "there are no special values or upper bounds (apart 
from obvious MAX_INT)".

> >   int choice;   /* Unit_Type_id or Impr_Type_id of the choice */
> 
> Should be a union.

Please elaborate.

> > For each item on each level there should be a function which fills the
> > choice struct.  These choices are compared, on each level, against it's
> > peers using copy_if_better_choice function to improve logging and ease
> > introduction of priorities.
> 
> The fundamental challenge for an algorithm like this is how to think 
> globally.  It's easy to say "I need an ironclad more than I need a 

This is what I mentioned in the comments before.  My proposal is really a 
rearrangement of present code, to make it more readable and debuggable.  
The next stage is to take out and globalize productions of certain classes 
of things: ferries, wonders, attackers etc.  Eventually, a city will only 
handle city improvements, defence units (with some help from global 
system) and terrain improvers maybe.

Now I am merely levelling the ground.

> > All function should start with ai_chooseN_ where N is the depth in the
> > hierarchy.  Examples:
> >         ai_choose1_civil_build,
> >         ai_choose2_settlers,
> >         ai_choose3_diplomat
> 
> Why are settlers at depth 2 while diplomat is at depth 3?

Oh, it just so happened.  Settlers are a division of EXPANSION and 
diplomats are a subdivision of Attackers which is a division of MILITARY.
It's a tree structure with no comparison relation across the branches.

On Sun, 23 May 2004, Per Inge Mathisen wrote:

> <URL: http://rt.freeciv.org/Ticket/Display.html?id=8805 >
> 
> On Sun, 23 May 2004, Gregory Berkolaiko wrote:
> > /* And maybe */
> > int x, y;       /* Coordinates of the target we have in mind */
> 
> If you store x,y then maybe also store the unit role?

Yes, we can do.  It's mostly for logging value now though.

> I think military should go first, and if we have an emergency, abort
> there. If we are building a military unit, did not finish building one
> this turn, and want a military unit with some high value, then continue
> building a military unit.

Yes, I listed it in no particular order.  The chief purpose of the Choice 
Classes in my mind is to provide an easy way of comparison among choices.  
MIL_EMERGENCY overrides everything.  CIVIL_EMERGENCY overrides everything 
apart from MIL_EM.  Other classes have some weight associated with them.
All comparisons logic is contained in copy_if_better_choice.  We can also 
add is_choice_final to abort the search if we have an EMERGENCY choice 
already (this will have to assume that the builds are searched in the 
right order).

> In general it looks very good.

Thanks.

G.





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