Complete.Org: Mailing Lists: Archives: freeciv-ai: February 2003:
[freeciv-ai] Advisors cleanup (Was: Patch Army)
Home

[freeciv-ai] Advisors cleanup (Was: Patch Army)

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: Jordi Negrevernis i Font <jorneg@xxxxxxxxxxx>
Cc: freeciv ai <freeciv-ai@xxxxxxxxxxx>
Subject: [freeciv-ai] Advisors cleanup (Was: Patch Army)
From: Gregory Berkolaiko <Gregory.Berkolaiko@xxxxxxxxxxxx>
Date: Sat, 22 Feb 2003 14:12:54 +0000

Hi Jordi,

Quoting Jordi Negrevernis i Font <jorneg@xxxxxxxxxxx>:

> >Design could be much better.  Cycling through all army units every time you
> need
> >to know the number of units in the army is, to put it mildly, wasteful.  And
> the
> >patch is full of it.
> >
>     Yes, maybe is not a good design but it ins't a waste of time and 
> resources.Look at the time to process the AI handling code for units and 
> the time in the army patch.

I admit I didn'tlook at the time.  But I am sure it can be made faster too.

> >1.  There was no path to the selected target, so the army would march out
> of
> >it's base and then march back in, ad infinitum.  This can be fixed rather
> easily 
> >by clever use of path-finding.
> >
>     The flip-flop of the army can be because i use the real_map_distance 
> instead of warmap and because every ten turns the ai reevaluates the 
> objectives and, maybe,  does choose a far away one.

The real_map_distance is to blame.  Note that using proper warmap as it is now
wouldn't help in the case I saw.

> >2.  There were not enough units willing to join the army.  However, there
> were
> >many units on the continent doing brave solitary attacks.  Also the units
> who
> >did join the armies, were split between two armies with the same target,
> base
> >and everything.
> >
> >The second is the more fundamental problem.  
> >
>     Yes are right. This is a problem. I did not want to mess the ai unit 
> handling code, so there are units attacking on it way.

I am afraid we will have to do that.  Otherwise there are not enough units in
the army and not enough units in the "random" attacks.

> >Hopefully this will increase modularity of the AI.  Please comment on this
> >general design and on how it could be split into "projects".  Then we can
> put
> >tenders on the projects ;)
> >
>     So, which is your idea? You want to modify the patch and have a new 
> c file or just modify the general ai code?

Both.  We definitely need a new file but we want to strap it more tightly into
the existing framework.

This is the idea I have:
in ai_manage_cities we currently call different advisors who often overwrite
each other's choice.  I want to change each advisor so it writes it's choice
into a separate structure and then there is a function which does comparison
between the requests (national tendencies can go here) and chooses the best one.
It is better for debugging, for putting it new advisors, for changing existing 
ones.

We should discuss initial division into advisors.  I think we should split
military into defence and attack (to be later substituted by army_advisor), but
what else? new_cities, terrain improvements, attitude, trade?  Please give your
suggestions.

G. 





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