[freeciv-ai] Re: Generalised improvements AI support

[Raahul Kumar <raahul_da_man@xxxxxxxxx>]

--- Raimar Falke <hawk@xxxxxxxxxxxxxxxxxxxxxxx> wrote:
<snip>
> 
> Here I think that your quoting is wrong.

Yes, a little bit of hand editing to make sure the lines didn't look too ugly.

> > Did you find the bug?
> 
> The "fix" is to extend it.

Per has a new implementation of flags that increases the number. He hasn't
found the bug in it yet. 

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

I didn't say compute flags. I said compute the best unit! That means instead
of checking if a unit has F_NUCLEAR, select it based on its incredible attack
damage. I hope this is more explicit. 

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

The ruleset authors don't always do a good job. Is it true that tank is
attack_good, or is maybe a howitzer far better against cities? Also,
conversely,
isn't a tank much better outside cities. A single tank could kill three
howitzers. One howitzer cannot kill three tanks.

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

I don't understand what you mean by convex hull. 
 
> > 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_AEGIS
> > F_PIKEMEN
> > F_HORSE
> > F_MISSILE
> > 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
> > 
> > F_SHIPBUSTER
> > F_TANKBUSTER
> > 
> > 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.

We need all the generality we can possibly get. Unfortunately, we also need all
the performance we can possibly get. Once gen-impr works with AI, there can be
a discussion about performance. Until then, there is little point.

You're missing a big drawback with the current approach. As far as possible, I
always thought our goal was to make Freeciv configurable via rulesets. I want
to keep modpack authors out of the code.

Consider: If someone wanted to add the proper Civ 2 air combat to Freeciv
before my changes. If the land of AC patches, I could have opened a tileset,
added some 
unit_defend changes, and I would have been done.

Time taken: 5 minutes, and that's being generous. Includes testing time.

Current system: I have to find the parts of the code that deal that matter,
combat.c, which is easy to find/understand. Not a fair test. There's lots of
other freeciv code which is much harder to grok. Now that I've changed the
flags system, I have to compile, fix any compile errors, and finally I'm ready
to test
my patch. Time taken: 15 mins, without testing.

There is a big difference in the time it would take a modpack writer to be up
to speed with the two systems. The flags way, the writer must get proficient
with freeciv code. The AC way, anyone can easily write their own modpacks.

Admittedly, the AC way is slightly more complex for us. 

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

Aloha,
RK.

If it looks like a duck, and quacks like a duck, we have at least to consider
the possibility that we have a small aquatic bird of the family anatidae on our
hands.
{Dirk Gently's Holistic Detective Agency, 1987}

__________________________________________________
Do You Yahoo!?
Yahoo! Health - your guide to health and wellness
http://health.yahoo.com