[freeciv-ai] Re: Hi, I'm back. aiclient
[Top] [All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
On Mon, Jun 30, 2003 at 07:09:07PM +0200, Manuel Gutierrez Algaba wrote:
> > > 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.
I disagree. A get_attack_power function would be enough. This function
will combine several attack power modifiers.
> > 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.
A related question is: in what languages are commercial computer game
AIs coded?
> > > 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
tar files in tar files in tar files. uhhh. And at least one of tar
files is named ".tex".
> 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.
If there is an english doc in PS please mail it to me.
> I just want the interface and go little by little. Don't be so fast.
Some people also have thought about the problem a lot and want to
share now some ideas.
Raimar
--
email: rf13@xxxxxxxxxxxxxxxxx
"- Amiga Y2K fixes (a bit late, wouldn't you say?)"
-- Linus Torvalds about linux 2.4.0 at 4 Jan 2001
- [freeciv-ai] Hi, I'm back. aiclient, Manuel Gutierrez Algaba, 2003/06/28
- Message not available
- Message not available
- [freeciv-ai] Re: Hi, I'm back. aiclient, Manuel Gutierrez Algaba, 2003/06/29
- [freeciv-ai] Re: Hi, I'm back. aiclient, Raimar Falke, 2003/06/30
- [freeciv-ai] Re: Hi, I'm back. aiclient, Manuel Gutierrez Algaba, 2003/06/30
- [freeciv-ai] Re: Hi, I'm back. aiclient, Raimar Falke, 2003/06/30
- [freeciv-ai] Re: Hi, I'm back. aiclient, Manuel Gutierrez Algaba, 2003/06/30
- [freeciv-ai] Re: Hi, I'm back. aiclient,
Raimar Falke <=
- [freeciv-ai] Re: Hi, I'm back. aiclient, Manuel Gutierrez Algaba, 2003/06/30
[freeciv-ai] Re: Hi, I'm back. aiclient, Raimar Falke, 2003/06/30
|
|