Complete.Org: Mailing Lists: Archives: freeciv-ai: June 2003:
[freeciv-ai] Re: Hi, I'm back. aiclient
Home

[freeciv-ai] Re: Hi, I'm back. aiclient

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: Raimar Falke <mi1CENJ*n6zfTpT$bj~OP@xxxxxxxxxxxxx>
Cc: freeciv-ai@xxxxxxxxxxx
Subject: [freeciv-ai] Re: Hi, I'm back. aiclient
From: Manuel Gutierrez Algaba <stemanolo@xxxxxxxx>
Date: Mon, 30 Jun 2003 00:20:36 +0200

El Dom 29 Jun 2003 21:48, escribió:
> [ IMHO this is of general interest and we should move to freeciv-ai ]

Sorry, mostly a fault of my mail program and the user of my mail program, 
that's me. :)

>
> On Sun, Jun 29, 2003 at 08:34:59PM +0200, Manuel Gutierrez Algaba wrote:
> > El Dom 29 Jun 2003 20:04, escribió:
> > > On Sun, Jun 29, 2003 at 07:51:37PM +0200, Manuel Gutierrez Algaba wrote:
> > > > El Dom 29 Jun 2003 18:44, escribió:
> > > > > > One advantage of extracting little by little info from civclient
> > > > > > and put it into rules is that it offers an opportunity to tidy up
> > > > > > all the "logic" of rules, facts,...
> > > > >
> > > > > I'm not sure what you mean here. IMHO should rules ("what can a
> > > > > unit attack", "how much trade will this route give", "what attack
> > > > > bonus will this unit get", ...) be done in the C code (both client
> > > > > and server need it -> common/).
> > > >
> > > > Yes, but currently, for knowing the attack points of a unit, for
> > > > example, you have to read a lot of C code, using that info in a
> > > > aiclient is another opportunity to put it in another form and make
> > > > it more understable.
> > >
> > > But IMHO without this info you can't really create a good client. You
> > > need this info at least in the long term.
> >
> > Yes, that info will be "duplicated" both in civserver (ruleset +
> > normal C code) and in aiclient (in the way the rules are constructed
> > ). What I'm saying is that by replicating little by little all the
> > current info in civserver, we have a chance of creating a more clear
> > and unified program , so people can understand better the inner
> > rules of freeciv.
>
> Lets take an example and define some terms.
>
> There are the "irrigation_result" and "irrigation_food_incr" fields in
> the terrain.ruleset file. Each of these values are mapped 1:1 to some
> fields in the some info packet. I would call these information
> low-level.

Ok, all ruleset-info should be read from the very same files by aiclient. I 
don't know if civclient ever knows that irrigation_food_incr is 2 or 3, well, 
I think it must know since it must draw it. Truly, you can either:
- Read it from ruleset
- Read from civclient , which has received from civserver what's in ruleset 
files.

I don't know if all the info in ruleset is transmitted to civclient. I guess, 
it's not compulsory to do so. So aiclient should read those files. On the 
other hand. It's "cleaner" and "more beautiful" if aiclient has a single 
point of getting  info: the socket with civclient. It's more independent. 

The values of those constants would be important for calculation for AI 
decisions. As I see, many people may code their aiclient's and some may code 
their rules with the "default" values, thus producing hardwired aiclients. 
Really, we can't control people, just suggest what's better. 

Anyway, this discussion is "advanced" and we (I) would be happy just by having 
the simpler form of an aiclient. Whether aiclients become hardwired or not is 
another problem , and if it's a problem it'd mean that aiclients have 
developed a lot, so it's a kind of a problem caused by success. 

>
> Other information can be calculated from these low-level information
> and some auxiliary information. So you take the terrain information,
> the player government, the tile status and the city status and you can
> answer the question "how much food creates this tile". The last
> information is high-level. With this information you can answer the
> question you are interested in "how will the food production of city
> foobar change if I irritate this tile".

As I say, it depends of the coder of aiclients (which first they'd be a kind 
of warclients ) , for example, Iuz' patch is a kind of aiclient but of course 
melted into civclient and subject to changes in civclient and not very 
understable for others who are not familiar with freeciv internals.

>
> Most of the code to calculate high-level info from low-level
> information is in common/. So it is accessible to the client.
>
> So if I understood you right you want to replicate this code in the
> external aiclient program. This is IMHO a bad idea. Reason: you have
> to duplicate the code (I guess this would be at least 25% of
> common/). You would have to update it every time the code changes (a
> lot will change if gen-effects are implmented for example). Also you
> have to code something to interface with the C code.

Well, if my idea is good (and followed by others) , we can't really control if 
the code is duplicated, because people code as they like not as they should. 
What I meant is that aiclient will explain "better" the internal rules of 
freeciv ( or at least it's another opportunity for such internal rules to be 
explained). If you understand freeciv rules, you can code an AI better.
Now for programming freeciv AI, you have to:
1- know C (easy)
2- know the structure and use of variables and functions of freeciv (hard)
3- follow the trace and collateral effects of some variables over others 
(hard)
4- know some conventions of freeciv C, as iterators (easy)

Having aiclient we can digest the hard problems 2,3 , little by little , 
without affecting the C code, but "restructuring it " and meditating about it 
in aiclient. Specially 3 would be improved by aiclient, because, obviously, C 
is not the right language to code rules.  

But till now, all this is a dream, as I see, it's the simpler way of getting 
ai's, warclients, inimaginable playability ( for example you could let your 
ai to handle half of your empire ). It really depends on you all. 

---
mga


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