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 <i-freeciv-lists@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 19:09:07 +0200

El Lun 30 Jun 2003 12:19, Raimar Falke escribió:
> On Mon, Jun 30, 2003 at 11:37:31AM +0200, Manuel Gutierrez Algaba wrote:
> > El Lun 30 Jun 2003 10:31, escribió:
> > > 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) { ;
> > > I
> >
> > don't understand this rule very much, I'd have to read more about
> > unit_type_...
>
> unit_type_flag(type, F_IGTIRED) corresponds 1:1 to the
> ; "IgTired"   = ignore tired penalty when attacking
> flag in units.ruleset.
>
>  > >     power = (power * moves_left) / SINGLE_MOVE;
> > >
> > >   }
> > >   return power;
> > > }
> >
> > Well, If I remember correctly Clips, would be:
> >
> > Using Clips, an expert system language:
>
> [snip code which looks like lisp ]


In fact Clips is a mix of C and Lisp, or that's what they claim. 

>
> > Apparently is even more complex.
>
> It is harder to understand. This may not be because C is better/worse
> than clips but because I (and almost all other developers) have
> learned how to read C. So C has an advantage.

Ok, as I say an aiclient may be coded in Basic or Cobol or bash, provided the 
interface.

>
> > But let's see it integrated in the "whole":
> >
> > - When you call the C function you have to store the "power" value
> > and take a decision *promptly" somewhere. Somehow it provokes that
> > the decission must be taken soon, and in an "if" branch up in the
> > stack of calls.
> > - C is a model that has only the info to be used at the moment, and
> > to use some info (attack power) you have to request for it.
>
> There is confusion here. IMHO we have to seperate "rules" and
> "decisions". "Rules" are inherent freeciv rules like "Veterans get
> +50% attack bonus." They don't change much. They should be keep in
> only one form (in the C source code in common/).

Ok, if there's somewhere in the server a veteran-50-attack-bonus-"rule", then 
there must be a veteran-50-attack-bonus-"rule" somewhere in the aiclient. 
By "rule" I mean, piece of code that relates several facts and produces new 
facts. Not ruleset.

>
> There are "decisions" like "is it a good idea to irritate this
> tile?". Answering these questions has something to do with the term
> "AI". C may be not be the best language to code this.
>
> > Now Clips mode:
> > - Whenever anything changes in the game (a unit becomes veteran) ,
> > all the related facts about it , such base-get-attack-power,
> > defense... become updated at the moment. That provides a pool of
> > asserted facts ready to be included in some rules of high
> > order. Like the fact defense-power-of-city, attack-power-of-fleet...
> > I mean that in Clips model , you have all the info concurrently
> > ready to be used, you don't have to call any function to work out
> > values and then produce a single "isolated" value, that most likely
> > will be consumed within a "chain" of decision.
>
> I don't know the correct terms but I would call this "event driven":
> an event can update state and generate so more events. It is an
> bottom-up strategy. The other one is what I would call "demand
> driven": to answer a question you divide the problem and solve each
> sub problem. This is a top-down strategy. This is orthogonal of the
> clisp vs c and the "rules" vs "decisions" discussion. While I agree
> that C is better suited to the top-down strategy.
>
> > In Clips you'd have "tree" of decisions and "trees" of reactions. A
> > single change will recreate a tree of facts.
> >
> > Needless to say, this model is richer and thought-provoking. The
> > logic may seem the same , the difference is in the data: more and
> > more interrelated and usable.
>
> The question is how can this be transform into a real advantage: the
> AI is easier to program, the AI is faster, the AI is stronger. While
> it is another model I don't see that the advantages are an
> implication.
>

Well, expert systems are coded in Clips or Jess or Prolog not in C. Perhaps 
you could browse the web a bit. 

> > The difference (C-Clips) doesn't come in isolated rules, but in the
> > behaviour of sets of rules. In C they're line-chained, call-by-call,
> > in Clips are "explosion"-like , a single change trigger changes in
> > many variables (decissions to be taken). In C you focus on the
> > "function" the call, in Clips you focus on the state, the fact. C is
> > imperative, Clips "logic" or better "stative". With the same effort,
> > because the logic for producing a value/fact is the same in C or
> > Clips (you somehow must generate the value with if's or defrules),
> > in Clips you keep a "trace" of facts and a set of facts, that in C
> > would had remained as local variables or returned values, hard to
> > relate, once the "initial call" has ended.
> >
> > Prolog would be pretty much the same, and better, since Prolog can
> > "fill" the gaps and "search for" a solution, not simply fact-making.
>
> I would like to see a true aiclient (one that does only the
> "decisions" from above) in this model. Even a simple one (build
> settlers, build cities, explore the map).
>
>       Raimar

Well, my project is here:

http://members.tripod.es/Brasidas/proyecto/todo.tar

But it's in Spanish and it's a lot of code, 10000+ lines of code, anyway have 
fun. There's doc in .ps format. 

I just want the interface and go little by little. Don't be so fast. 
---
mga



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