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

[Raimar Falke <i-freeciv-lists@xxxxxxxxxxxxx>]

On Mon, Jun 30, 2003 at 12:20:36AM +0200, Manuel Gutierrez Algaba wrote:
> El Dom 29 Jun 2003 21:48, escribió:
> > 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.

The client doesn't read the ruleset files. All the data is transmitted
by the server. The reasons are obvious.

> 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.

It should be very strongly discouraged to use hardwired
values. Especially since it isn't hard to get those values out of the
client C code. So the programmer of the interface (you ;) ) has to
provide an easy way to get all the information. This will reduce the
need for ward-wired values.

> > 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.

If the interface provide all the necessary information no sane people
will duplicate the code because it provides no advantage.

> 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).

Can you please cite some of the internal rules which you don't
understand?

> If you understand freeciv rules, you can code an AI better.

I agree when you replace better with faster. Example: suppose you want
to increase the science output of a city. A "smart" client will build
a library. The "dumb" client will try all buildings and see if each
building changes the science output. The first one is faster but the
result will be same.

> 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.

"obviously not the right language to code rules"? I disagree. How
would you recode the example below in another language?

int base_get_attack_power(Unit_Type_id type, bool veteran, int moves_left)
{
  int power;

  power = get_unit_type(type)->attack_strength * POWER_FACTOR;
  if (veteran) {
    /* Veterans get +50% bonus. */
    power = (power * 3) / 2;
  }

  if (!unit_type_flag(type, F_IGTIRED) && moves_left < SINGLE_MOVE) {
    power = (power * moves_left) / SINGLE_MOVE;
  }
  return power;
}

If this function isn't what you speak about please clarify.

> 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.

        Raimar

-- 
 email: rf13@xxxxxxxxxxxxxxxxx
  reality.sys corrupt. Reboot Universe? (y,n,q)