Complete.Org: Mailing Lists: Archives: freeciv-ai: May 2002:
[freeciv-ai] Re: Generalised improvements AI support

[freeciv-ai] Re: Generalised improvements AI support

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: Raahul Kumar <raahul_da_man@xxxxxxxxx>
Cc: "Per I. Mathisen" <Per.Inge.Mathisen@xxxxxxxxxxx>, Freeciv-ai <freeciv-ai@xxxxxxxxxxx>
Subject: [freeciv-ai] Re: Generalised improvements AI support
From: Raimar Falke <hawk@xxxxxxxxxxxxxxxxxxxxxxx>
Date: Wed, 8 May 2002 08:15:38 +0200
Reply-to: rf13@xxxxxxxxxxxxxxxxxxxxxx

On Tue, May 07, 2002 at 05:58:43PM -0700, Raahul Kumar wrote:
> > > > I'm only worried it might get a little too complicated. The flags code 
> > > > is
> > > > simple to understand, simple to code and simple to extend. The gen. 
> > > > impr.
> > > > approach is none of the above. But this is another discussion.
> > >
> > Simple to extend? *Bullshit* cough. I seem to remember two people who've
> > already run hard into Raimar's decision that the current no of flags + 2
> > was enough.

> > Being fixed.

Here I think that your quoting is wrong.

> Did you find the bug?

The "fix" is to extend it.

> > And simple to understand: Have you read combat.c? The convulutions I had to
> > go through to support Aegis properly etc is fast reaching the point where 
> > the
> > flags system cannot cope.
> > 
> > It has its weaknesses.
> Flags and roles are not a good approach. I'd prefer the AI to compute what the
> best unit is.

Flags in the current code are axioms. They are basic building
blocks. You can't compute them.

You can "calculate" roles at runtime. I would also prefer it this
way. But this is more that you remove the hint that the ruleset author
gave the AI.

> > And worst of all, the flags system is only open to two coders, Per and
> > myself. Have you seen anyone else send in patches? The AC approach is 
> > better.
> > Moving stuff into rulesets is the obvious and smart approach.
> > 
> > I am in doubt how much extra, needed flexibility this approach will give.
> > To convince me you will need to post an example ruleset or something (like
> > a list of sensible units that cannot easily be created with flags) that
> > shows me why I am wrong.
> I'll offer you two types of evidence. If there are any modpack writers reading
> this email, please chip in. One: the existing sytem is far too limited. Look 
> at
> all the existing modpacks. They all implement the exact same wonders, and 
> quite
> often the exact same units, just with different graphics. The Ancients modpack
> is a great example of this. The buildings are uncannily similar.

The current approach is that the modpack writer submit a patch which
implement a new flag and this flag is added to the CVS. At some point
we have a convex hull over all flags.

> Two: Let's use unit_defend, my favourite part of impr-gen. Yes, it's currently
> limited to buildings, but it would be trivial to extend it to units. With 
> unit 
> defend, you can replace the following flags
> F_HELICOPTER -> Ben assures me that negative bonuses work with his code. 
> And what if people decide to add two new effects, say for example a 300% bonus
> against ships, and 300% def penalty for tanks when attacked by helis. In the
> current system I would have to introduce two flags
> Then I would have to open combat.c, and actually use those flags! Substitute
> relevant bit of code for combat.c where it applies. Now combat.c is relatively
> clean compared to most of the code in CVS. I don't think it would be easy for 
> a
> newcomer to grok it.
> And under the current CVS, it would mean NO one else could add flags again.
> This is the wrong approach. I know you probably agree Per, that the right
> approach is to have the users modify the rulesets, rather than the actual 
> code.
> Best of all, we could stick with the same approach. One bit of code doing
> unit_defend means we can ditch an enormous no of flags.

The gen-unit approach is more general. The questions are: how much
generality do we need and how much does it cost us.


 email: rf13@xxxxxxxxxxxxxxxxx
  Two OS engineers facing a petri net chart:
        "dead lock in four moves!"

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