Fabian Mueller | 5 Mar 2009 21:05
Picon
Picon

AI is not in a releasable state

During balancing the "Legend of Wesmere" for the last 3 days I saw 
several strange AI behaviour that scared me so much that I want to draw 
some attention to it.

First, the ai is put into some sort of frozen state in which it shuffles 
the units around some place.
The bug 13105 attachment demonstrates that with an enemy leader that 
can't return to his castle to recruit more but doesn't attack either.
The units that had been recruited the turn before are shuffling in the 
keep except of the scouts which do some attacking.
https://gna.org/bugs/?13105

In bug 13120 the ai of side4 isn't doing any scouting. But shuffling. 
Just start LoW and "cl" to scenario3. You don't need to do anything. 
Just end the turns and watch the purple ai not scouting.
https://gna.org/bugs/?13120

I have also the impression that the ai doesn't choice it's terrain very 
wise these days. I imagine it better in the past. But that is hard to prove.
Trying to influence it's behaviour with the "caution" ai attribute 
doesn't seem to do anything.
Generally, I am spending hours of hours on ai tuning with little or no 
effect on the gameplay.
It feels just broken.

Greetings, Fabian
Eric S. Raymond | 5 Mar 2009 21:20
Picon
Gravatar

Re: AI is not in a releasable state

Fabian Mueller <fabianmueller5 <at> gmx.de>:
> It feels just broken.

Between these problems and the well-known northwest-bias bug, I think
the AI problems are serious enough to block a stable release.

Who knows the AI code well enough to try to fix it?
--

-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
dave | 5 Mar 2009 21:59

Re: AI is not in a releasable state

Quoting "Eric S. Raymond" <esr <at> thyrsus.com>:

> Fabian Mueller <fabianmueller5 <at> gmx.de>:
>> It feels just broken.
>
> Between these problems and the well-known northwest-bias bug, I think
> the AI problems are serious enough to block a stable release.

I'm not sure what the other problems are and/or how serious they are,  
but this "northwest bias" I hardly consider serious at all. It's been  
like that in every version of Wesnoth, and the AI only has a "north  
west bias" if all other things are equal.

>
> Who knows the AI code well enough to try to fix it?

Uhmmmm....me? Dragonking, perhaps. I think past experience has shown  
that others messing with AI code is a very bad idea; actually that's  
what got us into this mess to begin with.

However, I'm not sure when I will have time to dive into it. Most AI  
problems tend to be quite complicated to diagnose, and I have a bunch  
of "real life" things going on right now.

David

> --
> 		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
>
> _______________________________________________
(Continue reading)

Eric S. Raymond | 6 Mar 2009 00:14
Picon
Gravatar

Re: AI is not in a releasable state

dave <at> whitevine.net <dave <at> whitevine.net>:
> I'm not sure what the other problems are and/or how serious they are,  

See the following tracker bugs:

 #13120 	AI is not scouting
 #13119 	The ai should only recruit level one units for scouting
 #13105 	AI is blocked by a certain game configuration.
 #8410  	AI makes big mistakes in custom maps!

> However, I'm not sure when I will have time to dive into it. Most AI  
> problems tend to be quite complicated to diagnose, and I have a bunch of 
> "real life" things going on right now.

Ouch.  The problems that have piled up look to me like they are too
serious to allow a stable release.
--

-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
David White | 6 Mar 2009 06:06

Re: AI is not in a releasable state

On Thu, 2009-03-05 at 18:14 -0500, Eric S. Raymond wrote:
> dave <at> whitevine.net <dave <at> whitevine.net>:
> > I'm not sure what the other problems are and/or how serious they are,  
> 
> See the following tracker bugs:
> 
>  #13120 	AI is not scouting

This bug doesn't have any real instructions on how to reproduce. I have
updated it asking for them.

>  #13119 	The ai should only recruit level one units for scouting

I think this is subjective and not really an engine bug. If you don't
want the AI using level 2 scouts, don't make level 2 scouting units
recruitable by the AI.

>  #13105 	AI is blocked by a certain game configuration.

I have just fixed this bug, adding notes. Hopefully my fix won't cause
regressions elsewhere.

>  #8410  	AI makes big mistakes in custom maps!

This is a very old report which contains numerous issues, most of which
are subjective or not reasonably solvable. All issues are also very old,
dating to 2007. I have closed this bug.

Are there any other AI bug reports for me to look at?

(Continue reading)

Eric S. Raymond | 6 Mar 2009 17:01
Picon
Gravatar

Re: AI is not in a releasable state

David White <dave <at> whitevine.net>:
> On Thu, 2009-03-05 at 18:14 -0500, Eric S. Raymond wrote:
> > dave <at> whitevine.net <dave <at> whitevine.net>:
> > > I'm not sure what the other problems are and/or how serious they are,  
> > 
> > See the following tracker bugs:
> > 
> >  #13120 	AI is not scouting
> 
> This bug doesn't have any real instructions on how to reproduce. I have
> updated it asking for them.

And fendrin has left a recipe.  I hope that will be sufficient for 
you to fix it.

> >  #13119 	The ai should only recruit level one units for scouting
> 
> I think this is subjective and not really an engine bug. If you don't
> want the AI using level 2 scouts, don't make level 2 scouting units
> recruitable by the AI.

I see this has been changed to an FR, which seems reasonable.

> >  #13105 	AI is blocked by a certain game configuration.
> 
> I have just fixed this bug, adding notes. Hopefully my fix won't cause
> regressions elsewhere.

Good.

(Continue reading)

Greg Boggs | 6 Mar 2009 14:56
Gravatar

Re: AI is not in a releasable state

I'm not sure how to report official bugs, but many many times the AI leader will choose to attack rather than recruit. It tends to do this when it has gotten more than 1 move away from its base. This means once the leader leaves the base, it's unlikely that it will go back before it dies even when it has 50-70 gold to spend, it just continues to commit suicide. To fix this problem the leader should always stay in its base, unless there is an enemy unit within 1 move of the keep. If it's not in the keep hex at the start of its turn, and it has gold to spend, it should return to the keep.

I have tried to fix this several times without having a measurable improvement in the AI ability to win. I used the Python interface, but with Python going away It doesn't look like I'll ever be able to contribute to the AI.

David White wrote:
On Thu, 2009-03-05 at 18:14 -0500, Eric S. Raymond wrote:
dave <at> whitevine.net <dave <at> whitevine.net>:
I'm not sure what the other problems are and/or how serious they are,
See the following tracker bugs: #13120 AI is not scouting
This bug doesn't have any real instructions on how to reproduce. I have updated it asking for them.
#13119 The ai should only recruit level one units for scouting
I think this is subjective and not really an engine bug. If you don't want the AI using level 2 scouts, don't make level 2 scouting units recruitable by the AI.
#13105 AI is blocked by a certain game configuration.
I have just fixed this bug, adding notes. Hopefully my fix won't cause regressions elsewhere.
#8410 AI makes big mistakes in custom maps!
This is a very old report which contains numerous issues, most of which are subjective or not reasonably solvable. All issues are also very old, dating to 2007. I have closed this bug. Are there any other AI bug reports for me to look at? David
However, I'm not sure when I will have time to dive into it. Most AI problems tend to be quite complicated to diagnose, and I have a bunch of "real life" things going on right now.
Ouch. The problems that have piled up look to me like they are too serious to allow a stable release.
_______________________________________________ Wesnoth-dev mailing list Wesnoth-dev <at> gna.org https://mail.gna.org/listinfo/wesnoth-dev
_______________________________________________
Wesnoth-dev mailing list
Wesnoth-dev <at> gna.org
https://mail.gna.org/listinfo/wesnoth-dev
Eric S. Raymond | 6 Mar 2009 17:11
Picon
Gravatar

Re: AI is not in a releasable state

Greg Boggs <greg <at> humhost.com>:
> I'm not sure how to report official bugs,

https://gna.org/bugs/?func=additem&group=wesnoth
--

-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
Nils Kneuper | 6 Mar 2009 15:34
Picon

Re: AI is not in a releasable state


Greg Boggs schrieb:
> I'm not sure how to report official bugs, but many many times the AI
> leader will choose to attack rather than recruit. It tends to do this
> when it has gotten more than 1 move away from its base. This means once
> the leader leaves the base, it's unlikely that it will go back before it
> dies even when it has 50-70 gold to spend, it just continues to commit
> suicide. To fix this problem the leader should always stay in its base,
> unless there is an enemy unit within 1 move of the keep. If it's not in
> the keep hex at the start of its turn, and it has gold to spend, it
> should return to the keep.

Yes, the AI is stupid. This is known and in general it "should" be improved. But
that it is stupid is nothing really new, is it?

> I have tried to fix this several times without having a measurable
> improvement in the AI ability to win. I used the Python interface, but
> with Python going away It doesn't look like I'll ever be able to
> contribute to the AI.

Yes, it is no longer possible to work against with with PythonAI. But have you
tried to use FormulaAI to do something against this? I don't know how to use it
and how much is possible with it, but this sounds like the only means to control
the AI that is "somehow working" at the moment...

Cheers,
Nils Kneuper aka Ivanovic
Greg Boggs | 6 Mar 2009 21:16
Gravatar

Re: AI is not in a releasable state


Nils Kneuper wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Greg Boggs schrieb:
>   
>> I'm not sure how to report official bugs, but many many times the AI
>> leader will choose to attack rather than recruit. It tends to do this
>> when it has gotten more than 1 move away from its base. This means once
>> the leader leaves the base, it's unlikely that it will go back before it
>> dies even when it has 50-70 gold to spend, it just continues to commit
>> suicide. To fix this problem the leader should always stay in its base,
>> unless there is an enemy unit within 1 move of the keep. If it's not in
>> the keep hex at the start of its turn, and it has gold to spend, it
>> should return to the keep.
>>     
>
> Yes, the AI is stupid. This is known and in general it "should" be improved. But
> that it is stupid is nothing really new, is it?
>
>   
>> I have tried to fix this several times without having a measurable
>> improvement in the AI ability to win. I used the Python interface, but
>> with Python going away It doesn't look like I'll ever be able to
>> contribute to the AI.
>>     
>
> Yes, it is no longer possible to work against with with PythonAI. But have you
> tried to use FormulaAI to do something against this? I don't know how to use it
> and how much is possible with it, but this sounds like the only means to control
> the AI that is "somehow working" at the moment...
>   
> Cheers,
> Nils Kneuper aka Ivanovic
>   
I spent about 3 hours with the functional API. The python API was far  
superior and the Python example code was a lot better. I eagerly await 
the next scripting implementation for Wesnoth AI.

> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.10 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iEYEARECAAYFAkmxNIsACgkQfFda9thizwVr1wCgmnjCfdYST+roYSfuf0HuVNm8
> E8kAmwfb2MR1uYJZbNcyrFe+DoyjahMA
> =X+9S
> -----END PGP SIGNATURE-----
>
> _______________________________________________
> Wesnoth-dev mailing list
> Wesnoth-dev <at> gna.org
> https://mail.gna.org/listinfo/wesnoth-dev
>
>   
Nils Kneuper | 6 Mar 2009 12:15
Picon

Re: AI is not in a releasable state


Okay, lets have a look at this list and add my personal view on the importance
of those for 1.6. I will explicitly try to compare to 1.4, that is if there is
no regression compared to this, we *can* release...

>>  #13120 	AI is not scouting
> 
> This bug doesn't have any real instructions on how to reproduce. I have
> updated it asking for them.
> 

Hmm, somehow a part of "make the AI better and easier to configure". Personally
I don't think that this was possible in 1.4 either. So this is not a real
regression.

>>  #13119 	The ai should only recruit level one units for scouting
> 
> I think this is subjective and not really an engine bug. If you don't
> want the AI using level 2 scouts, don't make level 2 scouting units
> recruitable by the AI.
> 

This is more a feature request about "make the AI recruits smarter for specific
purposes". Yes, it makes sense as request, but we know that the AI is not bright
when it comes to recruiting. This is why Dragonking worked on recruiting formulas.

>>  #13105 	AI is blocked by a certain game configuration.
> 
> I have just fixed this bug, adding notes. Hopefully my fix won't cause
> regressions elsewhere.
> 

This was a clear regression and it looks like Dave fixed it. Okay, the fix has
to be tested no.

>>  #8410  	AI makes big mistakes in custom maps!
> 
> This is a very old report which contains numerous issues, most of which
> are subjective or not reasonably solvable. All issues are also very old,
> dating to 2007. I have closed this bug.

Ancient "problem" and a case of "the AI has to do *something* if all options are
equal". Yes, this makes the AI more predictable which is not good, but we know
that the AI is not too smart, don't we?

To sum the stuff up:
The only real blocker and regression was fixed. The rest is a case of "we should
improve our AI (in general) and make it easier scriptable".
* Making the AI in general better is a non trivial task. The most likely way to
go over time looks like it will be via formulas, like we talked about at FOSDEM.
Having the AI not be smart is an ancient problem and no "new release blocking
bug" since it is not worse at all than in 1.4.x.
* For the scripting part once upon the time PythonAI was introduced, but it was
not much used and now removed due to the security risk of the implementation.
Since last summer we also got FormulaAI which is meant to allow some scripting,
so in those regards we *do* have an improvement.

In general I think those "AI finetuning parameters" we have in WML for ages were
never working perfectly and thus it is hard to judge if anything improved or
broke there. So the AI is most likely not in a state worse than in 1.4.x, in
fact it is in a better state, since several crashes due to the AI were fixed. At
the moment I don't see the AI as a blocker for 1.4.x, unless you show some
"real" regressions that break gameplay.

Cheers,
Nils Kneuper aka Ivanovic

PS: But I think that bug #13118 [1] should be fixed before rc2 is out!

[1] https://gna.org/bugs/index.php?13118
Eric S. Raymond | 6 Mar 2009 17:07
Picon
Gravatar

Re: AI is not in a releasable state

Nils Kneuper <crazy-ivanovic <at> gmx.net>:
> Okay, lets have a look at this list and add my personal view on the importance
> of those for 1.6. I will explicitly try to compare to 1.4, that is if there is
> no regression compared to this, we *can* release...
> 
> >>  #13120 	AI is not scouting
> > 
> > This bug doesn't have any real instructions on how to reproduce. I have
> > updated it asking for them.
> > 
> 
> Hmm, somehow a part of "make the AI better and easier to
> configure". Personally I don't think that this was possible in 1.4
> either. So this is not a real regression.

I think you are incorrect here; I don't recall that 1.4 had this behavior.
Fabi has left a recipe to reproduce it, so this may enable Dave to fix it.

> To sum the stuff up:
> The only real blocker and regression was fixed. The rest is a case
> of "we should improve our AI (in general) and make it easier
> scriptable".

I think #13120 is still an issue.

> In general I think those "AI finetuning parameters" we have in WML
> for ages were never working perfectly and thus it is hard to judge
> if anything improved or broke there.

Then why did we lead campaign designers to believe they had an effect?
They need to be better documented.

> PS: But I think that bug #13118 [1] should be fixed before rc2 is out!

Agreed.
--

-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
Fabian Mueller | 6 Mar 2009 14:25
Picon
Picon

Re: AI is not in a releasable state

Nils Kneuper wrote:
> In general I think those "AI finetuning parameters" we have in WML for ages were
> never working perfectly and thus it is hard to judge if anything improved or
> broke there.
This is a form of user punishment and makes me angry.
If that parameters don't work (I agree, they don't work) then remove them.
I have wasted my time trying to do something with them.
The wiki doesn't say anything about that the parameters don't work.
I am really angry about this.
>  So the AI is most likely not in a state worse than in 1.4.x, in
> fact it is in a better state, since several crashes due to the AI were fixed.
>  At
> the moment I don't see the AI as a blocker for 1.4.x, unless you show some
> "real" regressions that break gameplay.
>   
Nils, please start the first scenario of HttT and watch the blue player 
shuffling around his castle.
Many scenarios are unbalanced with the ai doing such stupid things.
It's easy to spot, just do some play testing.

Greetings, Fabian
Nils Kneuper | 6 Mar 2009 15:33
Picon

Re: AI is not in a releasable state


Fabian Mueller schrieb:
> Nils Kneuper wrote:
>> In general I think those "AI finetuning parameters" we have in WML for ages were
>> never working perfectly and thus it is hard to judge if anything improved or
>> broke there.
> This is a form of user punishment and makes me angry.
> If that parameters don't work (I agree, they don't work) then remove them.
> I have wasted my time trying to do something with them.
> The wiki doesn't say anything about that the parameters don't work.
> I am really angry about this.

I agree that it is really annoying that there are parameters and they seem to
not have a real influence. That is the params may have some influence, but it is
not enough that it really matters in gameplay. Though this is *NOTHING* that can
be fixed with any short term solution!

>>  So the AI is most likely not in a state worse than in 1.4.x, in
>> fact it is in a better state, since several crashes due to the AI were fixed.
>>  At
>> the moment I don't see the AI as a blocker for 1.4.x, unless you show some
>> "real" regressions that break gameplay.
>>   
> Nils, please start the first scenario of HttT and watch the blue player 
> shuffling around his castle.
> Many scenarios are unbalanced with the ai doing such stupid things.
> It's easy to spot, just do some play testing.

Yes, and Dave meant to fix this with a commit yesterday. Please have a look at
revision 33364 and check if the problem still exists.
That is I started httt on the default difficulty level in latest trunk as well
as 1.5.12 and in both the blue AI player does move its troops northwards in the
direction of my keep. Yes, it might not move the units to the north "as fast as
possible", but it is clearly not shifting units around on the keep in this scenario.

Cheers,
Nils Kneuper aka Ivanovic
Eric S. Raymond | 6 Mar 2009 17:39
Picon
Gravatar

Re: AI is not in a releasable state

Nils Kneuper <crazy-ivanovic <at> gmx.net>:
> Fabian Mueller schrieb:
> > Nils Kneuper wrote:

> >> In general I think those "AI finetuning parameters" we have in WML for
> >> ages were never working perfectly and thus it is hard to judge if
> >> anything improved or broke there.
> >
> > This is a form of user punishment and makes me angry.
> > If that parameters don't work (I agree, they don't work) then remove them.
> > I have wasted my time trying to do something with them.
> > The wiki doesn't say anything about that the parameters don't work.
> > I am really angry about this.
> 
> I agree that it is really annoying that there are parameters and
> they seem to not have a real influence. That is the params may have
> some influence, but it is not enough that it really matters in
> gameplay. Though this is *NOTHING* that can be fixed with any short
> term solution!

If we really believe the AI tuning parameters don't work, "short term
solution" would be to *put a warning on the wiki*, in the description
of the AI parameters, that they don't work!

Fabian is quite right to be angry about this. It's one thing to have
an AI that's dimmer than it could be; it's entirely another to pretend
to campaign designers that it's tunable in ways that it is not.

Just to complicate matters, I don't in fact think the tuning
parameters are useless; when I was writing THoT, in particular, I
recall side aggression levels having significant effects.  From my own
experience, I suspect that Fabi had trouble finding values that made
a difference because the interactions and ranges of these parameters aren't well
documented.

I'm looking at the wiki page for the [ai] tag, now, remembering
designing THoT scenarios, and there are obvious questions it doesn't answer.
Here are some of them.  Dave or Dragonking, would you please investigate 
and add answers to the wiki?

caution: Is there a maximum above which this stops making a perceptible 
difference?  How does it scale? 

village_value: How does it scale?  How is this weighted against making
unit kills on opponents?

leader_value: How does this scale?  Does a value of 6.0 male the AI twice as
likely to target leaders as a value of 3.0?

scout_village_targetting: "multiplies" relative to what? 
--

-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
John McNabb | 5 Mar 2009 23:58
Picon

Re: AI is not in a releasable state

I may have some time freeing up which I could devote to returning to do some Wesnoth Development again.  I had started to tinker with my own WML-scriptable AI before real-life intervened over a year ago.  The idea behind the new AI was detailed here: http://www.wesnoth.org/wiki/User:Darth_Fool.  It is undoubtedly a little outdated at this point.

The resulting AI would be much more flexible and should fix the aforementioned "bugs".  Of course, it would also give scenario writers enough rope to hang themselves (or at least the computer controlled team) with.  The scriptability would also allow significant tweaking of the default AI, and eventually allow such default behavior as units with leadership like abilities semi-intelligently moving to support units before they attack.

At this point, I would undoubtedly need to start my revisions from scratch, which wouldn't be such a bad thing as my initial code started to get a bit kludgey near the end.  One thing I had realized shortly before my departure was that there were aspects to the underlying AI code that needed to be rewritten to achieve the flexibility I desired.  

I will need to check out the latest version and dig into it a bit before I commit to actually making changes.  It certainly would not be done for this release.  Comments on the scheme described in the above link are welcome.

John McNabb,
AKA: Darth Fool

-------------------------------------------------------------------
       "In theory, theory and practice are the same,
                but in practice they're different."
-------------------------------------------------------------------
John W. C. McNabb
-------------------------------------------------------------------


On Thu, Mar 5, 2009 at 3:59 PM, <dave <at> whitevine.net> wrote:
Quoting "Eric S. Raymond" <esr <at> thyrsus.com>:

> Fabian Mueller <fabianmueller5 <at> gmx.de>:
>> It feels just broken.
>
> Between these problems and the well-known northwest-bias bug, I think
> the AI problems are serious enough to block a stable release.

I'm not sure what the other problems are and/or how serious they are,
but this "northwest bias" I hardly consider serious at all. It's been
like that in every version of Wesnoth, and the AI only has a "north
west bias" if all other things are equal.

>
> Who knows the AI code well enough to try to fix it?

Uhmmmm....me? Dragonking, perhaps. I think past experience has shown
that others messing with AI code is a very bad idea; actually that's
what got us into this mess to begin with.

However, I'm not sure when I will have time to dive into it. Most AI
problems tend to be quite complicated to diagnose, and I have a bunch
of "real life" things going on right now.

David

> --
>               <a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
>
> _______________________________________________
> Wesnoth-dev mailing list
> Wesnoth-dev <at> gna.org
> https://mail.gna.org/listinfo/wesnoth-dev
>




_______________________________________________
Wesnoth-dev mailing list
Wesnoth-dev <at> gna.org
https://mail.gna.org/listinfo/wesnoth-dev

_______________________________________________
Wesnoth-dev mailing list
Wesnoth-dev <at> gna.org
https://mail.gna.org/listinfo/wesnoth-dev
Eric S. Raymond | 6 Mar 2009 00:15
Picon
Gravatar

Re: AI is not in a releasable state

John McNabb <mcn4bb <at> gmail.com>:
> I will need to check out the latest version and dig into it a bit before I
> commit to actually making changes.  It certainly would not be done for this
> release.

What would your estimated time to a production-ready AI be?
--

-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
John McNabb | 6 Mar 2009 22:31
Picon

Re: AI is not in a releasable state



On Thu, Mar 5, 2009 at 6:15 PM, Eric S. Raymond <esr <at> thyrsus.com> wrote:
What would your estimated time to a production-ready AI be?
 
Given that I (fortunately) still have a real job, my proposed AI would definitely be done in a time-scale measured in months.  Some improvements from my  new AI will inevitably involve some fixes under the hood of the current AI engine that may clean up a few bugs, but I would definitely not hold up the release for it.  Since several of these AI bugs sound familiar to me, I can assure you that they were around in some form over a year ago when I last was first looking at the AI.  Of course, other things might have compounded them and made them worse, or it might just be that with all the additional features in Wesnoth that the lack of control of the AI is becoming more obvious.

I expect that my new AI should have plenty of examples by the final release so that people can take advantage of it.  For one thing, my goal is to have an AI that can honestly beat the HttT campaign on easy.  This will involve adding AI tags to the players side which can be activated with the ":droid 1" command.  At least I believe that was the command...In any case, beating HttT "honestly" will require enough scripting and the ability to change the AI based upon certain in-game events.  I don't consider it to be fair (for example) to have the AI heading directly towards a hidden object when the human player has to search for it.  Basically, I want to be able to say to someone who says that they can't beat such and such a level to let the AI show them how to do it, and not have them come back and point out how the AI cheated.  Long ago as part of my idea for this project was to enable a standardized definition of easy, medium, and hard.  Easy meant that the AI could beat every level in the campaign starting the scenario with the minimum gold and no recalled units.  Medium meant the AI could beat the level with leftover gold and recalling units from the previous scenarios.  Hard was well...hard.   Probably you'd have to throw in something like wins 9 out of 10 games, but you get the idea.

Oh well, I need to stop waxing philosophic and reactivate my gna account so that I can actually download the latest version and see how much has changed and what I am getting myself back into.

Later,
John McNabb
aka darth fool

-------------------------------------------------------------------
       "In theory, theory and practice are the same,
                but in practice they're different."
-------------------------------------------------------------------
John W. C. McNabb
-------------------------------------------------------------------

_______________________________________________
Wesnoth-dev mailing list
Wesnoth-dev <at> gna.org
https://mail.gna.org/listinfo/wesnoth-dev
John McNabb | 18 Mar 2009 18:11
Picon

Re: AI is not in a releasable state

OK, I have completed my initial look at the changes in AI since last I played with it and I figured I would send out my plan of attack on creating an improved AI.  I am hoping for constructive criticism/comments to the plan in case there is something I have overlooked that should be included in the planning stage.

First off, I think the thing to do is to have my new AI initially inherit most everything from the formula AI.  This will allow me to take advantage of the existing code while not creating an inconsistent syntax for doing math in WML.  (Well, my old dfool AI already has an inconsistent syntax as it predated formula AI, but it was never complete).  The new AI (I will call it fogged_ai for now) will replace a few of the functions currently defined in formula AI to make it impossible for the AI to have access to information that a player wouldn't have.  The most obvious of these functions to change would be the enemy unit list, but there are others involving pathfinding as well.  Note that if Fog of War and Shroud is turned off for the AI side, these functions should behave identically to the current functions.

The next step will be to implement the orders functionality that I had abandonded a year ago.  The order functionality would be written as some combination of formula_ai functions and C++ routines.  The idea will be to develop a library of useful formula_ai functions.

The testing of the AI will be on three fronts.  First, there will be a special test scenario for checking the correctness of the AI's non-cheating.  Second, I will be developing the AI for the players side in the HttT campaign (activated by the "droid 1" command).  Finally, I will be testing as an AI in standard single map games.  The first case is necessary to make sure that having the AI unaware of invisible units doesn't break things.  I had started doing this before, but I am not sure what state it is in now.  The HttT development should both prove that the scripting of the AI is sufficient for most campaign purposes as well as forcing me to develop a good list of formula AI library routines for campaign designers use.  It will also provide the examples of how to use it.  The final case is in some ways the most important.  The key will be that the fogged AI when working on an unscripted map must have a reasonable set of defaults.  I plan on having a special AI WML file that defines the default behaviour in these cases.  This should provide for an easy mechanism for changing/improving the AIs default behaviour on unscripted maps.  I will probably also release some simple shell scripts demonstrating how to run AI v. AI in batch mode to evaluate AI success.  There may be some additions to wesnoth command line options to make this easier.

Once items within the fogged AI have reached a certain level of maturity, if desired they could be moved down to become part of or replace elements of the original formula AI.  In addition, once the fogged AI is able to regularly beat the default AI on unscripted maps, it can be slid in to replace it.  Neither of these actions need to or should take place before thorough testing of the 3 test cases by people other than myself.  While I have confidence that my tackling the above three test cases should result in a fairly robust AI, I also recognize that it is a common human failing to be unable to recognize errors in ones own creations.  The difficult side to this, as always, will be getting volunteers to test things that have not been pushed into the default AI.  Never the less, I do think that it is important (as discussed in a different email thread) to have more than one person looking at changes that will effect how the default AI works before it gets pushed into the default AI.  So, expect a call for volunteers.

Key differences that I see in the fogged_AI vs. formula AI:
1)  The AI will explicitly not have access to information that would be invisible to a human player playing the same side.
2)  The default fogged AI will operate based upon orders.  These will likely be largely built up out of the formula AI, but should provide an easier mechanism for non-experts to manipulate the AI's behaviour in intuitive AI than the low level formula code.  This should expand the library of formula AI code.  Most of the library should work with both fogged and formula AI.  Any that only works in the fogged AI will be obviously marked as such.
3)  Unit based AI will not by default run before other orders.  There will be a command to explicitly call a units default AI, and I can imagine building a mechanism for unit based AI functions.  So, for example, one might call my_unit.scout() as part of a general scouting function to activate special scouting code for that unit (if any exists).  If none exists a default scout() function would be called.   
4)  It will be possible to run a default version of the AI on maps that have no specific AI written for it.  There will be a WML configuration file that defines this behaviour.

Key differences that I see in the fogged_AI vs. default AI.
1) Same as above.
2) Since it is based on formula AI, it will obviously be much more flexible.  It should be pretty straight forward to modify the AIs behaviour with parameters that have obvious effects. 
3) Elimination of things like the North-West bias.  When choosing between equally good moves(by whatever measure), the AI will choose randomly from amongst them.
4) Ultimately, it should be able to regularly beat the default AI on a large number of maps without customized AI scripts for those maps. 
5) The fogged AI will be able to complete at least one campaign(HttT) on easy.

I am not crazy enough to issue a timeline for this project, however I expect to have some functional form ready for the next stable release, although it will likely not have achieved all of the above goals by then.  As stated before comments and criticisms are welcome.

Darth Fool

-------------------------------------------------------------------
       "In theory, theory and practice are the same,
                but in practice they're different."
-------------------------------------------------------------------
John W. C. McNabb
-------------------------------------------------------------------


On Fri, Mar 6, 2009 at 5:31 PM, John McNabb <mcn4bb <at> gmail.com> wrote:


On Thu, Mar 5, 2009 at 6:15 PM, Eric S. Raymond <esr <at> thyrsus.com> wrote:
What would your estimated time to a production-ready AI be?
 
Given that I (fortunately) still have a real job, my proposed AI would definitely be done in a time-scale measured in months.  Some improvements from my  new AI will inevitably involve some fixes under the hood of the current AI engine that may clean up a few bugs, but I would definitely not hold up the release for it.  Since several of these AI bugs sound familiar to me, I can assure you that they were around in some form over a year ago when I last was first looking at the AI.  Of course, other things might have compounded them and made them worse, or it might just be that with all the additional features in Wesnoth that the lack of control of the AI is becoming more obvious.

I expect that my new AI should have plenty of examples by the final release so that people can take advantage of it.  For one thing, my goal is to have an AI that can honestly beat the HttT campaign on easy.  This will involve adding AI tags to the players side which can be activated with the ":droid 1" command.  At least I believe that was the command...In any case, beating HttT "honestly" will require enough scripting and the ability to change the AI based upon certain in-game events.  I don't consider it to be fair (for example) to have the AI heading directly towards a hidden object when the human player has to search for it.  Basically, I want to be able to say to someone who says that they can't beat such and such a level to let the AI show them how to do it, and not have them come back and point out how the AI cheated.  Long ago as part of my idea for this project was to enable a standardized definition of easy, medium, and hard.  Easy meant that the AI could beat every level in the campaign starting the scenario with the minimum gold and no recalled units.  Medium meant the AI could beat the level with leftover gold and recalling units from the previous scenarios.  Hard was well...hard.   Probably you'd have to throw in something like wins 9 out of 10 games, but you get the idea.

Oh well, I need to stop waxing philosophic and reactivate my gna account so that I can actually download the latest version and see how much has changed and what I am getting myself back into.

Later,
John McNabb
aka darth fool


-------------------------------------------------------------------
       "In theory, theory and practice are the same,
                but in practice they're different."
-------------------------------------------------------------------
John W. C. McNabb
-------------------------------------------------------------------


_______________________________________________
Wesnoth-dev mailing list
Wesnoth-dev <at> gna.org
https://mail.gna.org/listinfo/wesnoth-dev
Guillaume Melquiond | 18 Mar 2009 20:25
Picon

Re: AI is not in a releasable state

On 2009/3/18, John McNabb wrote:

> When choosing between equally good moves(by whatever measure), the AI will choose randomly from amongst them.

Please don't, unless your goal is to make reproducing AI bugs from
savegame impossible.

Best regards,

Guillaume
Eric S. Raymond | 18 Mar 2009 21:43
Picon
Gravatar

Re: AI is not in a releasable state

Guillaume Melquiond <guillaume.melquiond <at> gmail.com>:
> On 2009/3/18, John McNabb wrote:
> 
> > When choosing between equally good moves(by whatever measure), the AI will choose randomly from
amongst them.
> 
> Please don't, unless your goal is to make reproducing AI bugs from
> savegame impossible.

Easily solved.  Psdseudorandomly wit the generator state included in the
savegame.
--

-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
Bruno Wolff III | 18 Mar 2009 21:31
Picon

Re: AI is not in a releasable state

On Wed, Mar 18, 2009 at 20:25:16 +0100,
  Guillaume Melquiond <guillaume.melquiond <at> gmail.com> wrote:
> On 2009/3/18, John McNabb wrote:
> 
> > When choosing between equally good moves(by whatever measure), the AI will choose randomly from
amongst them.
> 
> Please don't, unless your goal is to make reproducing AI bugs from
> savegame impossible.

It could be psuedo random so that it would be reproducible, but not
predictable.
Nils Kneuper | 6 Mar 2009 00:30
Picon

Re: AI is not in a releasable state


Eric S. Raymond schrieb:
> John McNabb <mcn4bb <at> gmail.com>:
>> I will need to check out the latest version and dig into it a bit before I
>> commit to actually making changes.  It certainly would not be done for this
>> release.
> 
> What would your estimated time to a production-ready AI be?

Short guess: several *month*, not days or "one or two weeks". You do know that
this stuff is complicated as hell...
Cheers,
Nils Kneuper aka Ivanovic
Eric S. Raymond | 6 Mar 2009 01:26
Picon
Gravatar

Re: AI is not in a releasable state

Nils Kneuper <crazy-ivanovic <at> gmx.net>:
> Short guess: several *month*, not days or "one or two weeks". You do know that
> this stuff is complicated as hell...

Of course I know that.  We may face an unpleasant choice between holding for 
those months or shipping a broken game.
--

-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
Ignacio Morelle | 6 Mar 2009 03:01
Picon
Gravatar

Re: AI is not in a releasable state

On Thu, Mar 5, 2009 at 9:26 PM, Eric S. Raymond <esr <at> thyrsus.com> wrote:
> Nils Kneuper <crazy-ivanovic <at> gmx.net>:
>> Short guess: several *month*, not days or "one or two weeks". You do know that
>> this stuff is complicated as hell...
>
> Of course I know that.  We may face an unpleasant choice between holding for
> those months or shipping a broken game.

Are the same bugs present in 1.4?

If so, I personally don't see any reason to consider 1.6 more broken /
less "shippable" than 1.4 was. IIRC there were also some important
bugs in 1.4 which could not be fixed without breaking MP
interoperability or add-on compatibility across 1.4.x releases. There
have been many improvements in other areas in 1.6 (WML, engine,
graphics, music, MP usability, FormulaAI, security), and if the AI has
been "broken" in such ways in the last stable series then it's not a
strong enough reason to delay 1.6 further and minimize chances of
having 1.6.0 or later in new releases of major GNU/Linux
distributions. However, it may be a good idea to shrink our goals for
1.8.0 so that 1.8.0 can it can be released before a whole year passes,
and after the AI is fixed or improved as required.

Regards
-- Ignacio R. Morelle <shadowmaster>
Eric S. Raymond | 6 Mar 2009 04:06
Picon
Gravatar

Re: AI is not in a releasable state

Ignacio Morelle <shadowm2006 <at> gmail.com>:
> On Thu, Mar 5, 2009 at 9:26 PM, Eric S. Raymond <esr <at> thyrsus.com> wrote:
> > Nils Kneuper <crazy-ivanovic <at> gmx.net>:
> >> Short guess: several *month*, not days or "one or two weeks". You do know that
> >> this stuff is complicated as hell...
> >
> > Of course I know that.  We may face an unpleasant choice between holding for
> > those months or shipping a broken game.
> 
> Are the same bugs present in 1.4?

According to fendrin, no.  He reports tripping over these while trying 
to tune LoW.
--

-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
David White | 6 Mar 2009 03:23

Re: AI is not in a releasable state

On Thu, 2009-03-05 at 23:01 -0300, Ignacio Morelle wrote:
> On Thu, Mar 5, 2009 at 9:26 PM, Eric S. Raymond <esr <at> thyrsus.com> wrote:
> > Nils Kneuper <crazy-ivanovic <at> gmx.net>:
> >> Short guess: several *month*, not days or "one or two weeks". You do know that
> >> this stuff is complicated as hell...
> >
> > Of course I know that.  We may face an unpleasant choice between holding for
> > those months or shipping a broken game.
> 
> Are the same bugs present in 1.4?

I think this is the most important question.

I do think that developing a new AI from scratch to allow 1.6 to release
is not a realistic approach. (Though I do hope that DarthFool does do
work on a new AI for future releases).

I'll see what I can do to fix as much of the AI as possible. Can anyone
easily verify which of the bugs that ESR referenced earlier are
regressions?

David

> 
> If so, I personally don't see any reason to consider 1.6 more broken /
> less "shippable" than 1.4 was. IIRC there were also some important
> bugs in 1.4 which could not be fixed without breaking MP
> interoperability or add-on compatibility across 1.4.x releases. There
> have been many improvements in other areas in 1.6 (WML, engine,
> graphics, music, MP usability, FormulaAI, security), and if the AI has
> been "broken" in such ways in the last stable series then it's not a
> strong enough reason to delay 1.6 further and minimize chances of
> having 1.6.0 or later in new releases of major GNU/Linux
> distributions. However, it may be a good idea to shrink our goals for
> 1.8.0 so that 1.8.0 can it can be released before a whole year passes,
> and after the AI is fixed or improved as required.
> 
> Regards
> -- Ignacio R. Morelle <shadowmaster>
> 
> _______________________________________________
> Wesnoth-dev mailing list
> Wesnoth-dev <at> gna.org
> https://mail.gna.org/listinfo/wesnoth-dev
Eric S. Raymond | 6 Mar 2009 04:07
Picon
Gravatar

Re: AI is not in a releasable state

David White <dave <at> whitevine.net>:
> I'll see what I can do to fix as much of the AI as possible. Can anyone
> easily verify which of the bugs that ESR referenced earlier are
> regressions?

All of them except the north-west bias, I believe.  That *was* present
in 1.4.
--

-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Gmane