Complete.Org: Mailing Lists: Archives: freeciv-ai: April 2002:
[freeciv-ai] Re: README.AI

[freeciv-ai] Re: README.AI

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: Gregory Berkolaiko <Gregory.Berkolaiko@xxxxxxxxxxxx>, Raimar Falke <rf13@xxxxxxxxxxxxxxxxxxxxxx>
Cc: freeciv-ai@xxxxxxxxxxx
Subject: [freeciv-ai] Re: README.AI
From: Raahul Kumar <raahul_da_man@xxxxxxxxx>
Date: Mon, 29 Apr 2002 21:58:24 -0700 (PDT)

--- Gregory Berkolaiko <Gregory.Berkolaiko@xxxxxxxxxxxx> wrote:
> I really like French spacing but I don't think it's good to edit other 
> people's typing in this case.  Besides it's not that important.

Greg, go ahead and edit other people's typing. I don't care.
year" is the same for me.
> "now" is in fact "5 years from now".  Or did you mean something else?
> Added "in":
> What is better, to receive 10$ annually starting in 5 years from now or
> 5$ annually starting from this year? 

Slightly confusing. If all of your investments will pay off in 10 yrs, 
what do you have in the shorterm? You could go bankrupt waiting for your
fortune to arrive.
> > > years time 10$ will buy as much as 10*(100/(100+x))^5 $ will buy
> > > today.  Denoting 100/(100+x) by q we get the general formula, N$ in Y
> > > years time will be equivalent to N*q^Y in todays money.  If we will
> > > receive N$ every year starting Y years from now, the total amount
> > > receivable (in todays money) is 
> > 
> > Please drop the $. They make it hard to read.
> ok

Greg, can you do a prettier version using MathML. This calculation looks butt
ugly. Just post a link to a pretty version.

> > ==============
> ==============
> ========
> Introduction
> The AI crew
> Want calculations
> Amortize
> Estimation of profit from a military operation
> Diplomacy
> Difficulty levels
> Things that needs to be fixed
> Idea space
> ============ 
> The Freeciv AI is widely recognized as being as good as or better
> militarywise as the AI of certain other games it is natural to compare
> it with. It does, however, lack diplomacy and can only do war. It is
> also too hard on novice players and too easy for experienced players.

Not sure this is really applicable anymore. Per's diplomacy patches makes it
a lot easier for easy players and a lot harder for experienced players.
> The code base is not in a good state. It has a number of problems,
> from very messy and not very readable codebase, to many missing
> features to some bugs, which aren't easy to fix due to unreadable
> code. The problem is, that most the code was written by someone who
> didn't care about code readibility a lot. After he left the project,
> various people have contributed their own mostly unfinished hacks
> without really fixing the main issues in the AI code, resulting in
> even more mess.

Is this a dig at us? The code was in a far uglier state before the crew
got here.

>   Another problem is that not all code is residing in ai/ (which is
> currently still linked to a server, but there're plans to separate
> this completely to some kind of client, working name is "civbot"),
> but it is also dissolved in little chunks in the whole server/.
> Aside that, server/settlers.c is only AI stuff - the problem is,
> that most of it is used also for the autosettlers, so we can't
> separate it from the server.
>   This file aims to describe all such problems, in addition to various
> not entirely self-describing constants and equations used in the code
> commonly.

All constants? 
> ===========
> If you wish to get in touch with the Crew about AI problems and have
> save games and a method for reproducing the problem in hand, here are
> the email addresses:
>   Petr Baudis          <pasky@xxxxxxxxxxx>
>   Gregory Berkolaiko   <gregory.berkolaiko@xxxxxxxxxxxx>
>   Per I. Mathisen      <per.inge.mathisen@xxxxxxxxxxx>
>   Raahul Kumar         <raahul_da_man@xxxxxxxxx>
> =================
> Build calculations are expressed through a structure called ai_choice. 
> This has a variable called "want", which determines how much the AI 
> wants whatever item is pointed to by choice->type. choice->want is
>    -199   get_a_boat
>    < 0    an error
>    == 0   no want, nothing to do
>    <= 100 normal want
>     > 100 critical want, used to requisition emergency needs
>     > ??? probably an error (1024 is a reasonable upper bound)
> These are ideal numbers, your mileage while travelling through the 
> code may vary considerably. Technology and diplomats, in particular, 
> seem to violate these standards.

In parts of the code, if want exceeds 200 it is lowered below that value.

> Suppose we have a constant rate of inflation, x percent.  Then in five
> years time 10$ will buy as much as 10*(100/(100+x))^5 will buy
> today.  Denoting 100/(100+x) by q we get the general formula, N in Y
> years time will be equivalent to N*q^Y in todays money.  If we will
> receive N every year starting Y years from now, the total amount
> receivable (in todays money) is 
>            N*q^Y + N*q^{Y+1} + N*q^{Y+2} + ...  
>            = N*q^Y * (1 + q + q^2 + q^3 + ...)  
>            = N*q^Y / (1-q)

Unreadable. Please have a prettier version linked to on the Freeciv website.
> Here we used the formula for the sum of geometric series.  Note that
> the factor 1/(1-q) does not depend on the parameters N and Y and can
> be ignored.  In this setting, the current value of MORT = 24
> corresponds to the inflation rate (or rate of expansion of your civ)
> of 4.3%
> Most likely this explanation is not what the authors of amortize() had
> in mind, but the basic idea is correct: the value of the payoff decays
> exponentially with the delay.
> The version of amortize used in military code (military_amortize())
> remains a complete mystery.

Greg, a bit more detail on what you find inexplicable about military_amortise.

> ============================
> * The AI difficulty levels aren't fully implemented. Either add more
> handicaps to 'easy', or use easy diplomacy mode.
> * AI doesn't understand when to become DEMOCRACY. Actually it doesn't 
> evalute governments much at all.

Not just democracy. Fundamentalism is a great gov for the AI.

> * Cities don't realize units are on their way to defend it.

Not a bug!! We don't want cities to expect units that may never turn up.
The AI code for pathfinding/ finding stuff to kill is insane.

> * AI doesn't understand that some wonders are obsolete, that some 
> wonders become obsolete, and doesn't upgrade units.

All of this is easy to fix. Why are we lacking patches?

> * AI doesn't understand how to favor trade when it needs luxury.

This is just the caravan problem all over again.

> * AI builds cities without regard to danger at that location.

What do you mean by this?

> * City tile values are not cached; wastes CPU time.

Get rid of it. There's just no benefit in caching tiles. Raimar already
showed this.

> * Food tiles should be less wanted if city can't expand.
> * AI won't build cross-country roads outside of city radii.

Mention that there is a patch that does this.

> * Non-military units need to stop going where they will be killed.
> * Locally_zero_minimap is not implemented when wilderness tiles 
> change.
> * Settlers won't treat about-to-be-built ferryboats as ferryboats.
> * If no path to chosen victim is found, new victim should be chosen.
> * AI doesn't know how to make trade routes or when. It should try to 
> build trade routes for its best cities (most building bonuses and 
> least corruption) by moving caravans there and changing homecity.
> * Boats sometimes sail away from landlocked would-be passengers.
> * Ferryboats crossing at sea might lead to unwanted behavior.
> * Emergencies in two cities at once aren't handled properly.
> * AI sometimes will get locked into a zero science rate and stay 
> there.
> * Explorers will not use ferryboats to get to new lands to explore.
> * AI autoattack is never activated (probably a good thing too) (PR#1340)
> * AI sometimes believes that wasting a horde of weak military units to
> kill one enemy is profitable (PR#1340)

Just a better idea of combat odds is needed as well as not attacking with
defensive units.
> ==========
> * Friendly cities can be used as beachheads
> * Assess_danger should acknowledge positive feedback between multiple 
> attackers


> * Urgency and grave_danger should probably be ints showing magnitude 
> of danger
> * It would be nice for bodyguard and charge to meet en-route more 
> elegantly.
> * It may be correct to starve workers instead of allowing disorder to 
> continue.

No. In order of best to worst actions:

create specialist/increase luxury rate
build temple/happiness improv
buy/build happiness wonder
buy/build engineer/settler
finally allow city to starve

> * struct choice should have a priority indicator in it.  This will
> reduce the number of "special" want values, thus reducing confusion.

What the hell is this? If we are going to have priority indicators, what is the
use of want?????


"The hardest thing to understand in the world is the income tax." 
-Albert Einstein 

Do You Yahoo!?
Yahoo! Health - your guide to health and wellness

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