Exercises in Formula and Lua AI and AI-demos add-on feedback

[mattsc]

Hey Rigor: thanks for writing down some more of your thoughts.

from all of this, what is possible, what is utopia, and what do you think you did already?

I assume that you are not just talking about setting AI aspects differently for different times of day? That's built in and can be done using the time_of_day key to the [ai] tag. Or you could use one of the many AI macros, such as 'AI_SIMPLE_ASPECT_FOR_TIME_OF_DAY'.

Taking it a step further and having the AI execute different candidate actions (CAs = behaviors) during different times of day, or do them in different order or with different priority, is easy as well.

The problem is coding those CA's in the first place. When we talk about this, we use statements like "use some criterion" or "place units in formation on favorable terrain". Our brains are very good at pattern recognition things like that, but writing an algorithm for it is a very different beast. I have played with this for quite some time now and I still haven't found anything that could reliably beat the default AI on a random map (although some implementations will go 50/50 on average). One reason why I did that 'Pass Defense' AI is because it is a very specific, "controlled" setup in which it is quite clear what the AI should do. It could easily be applied to other bottle-neck-like situations, but it won't work on an open map.

I did, however, learn a lot from that and am tempted to apply it to other specific examples (holding a river bank, or a map where all terrain is equal, ...) I see those as stepping stones toward the bigger, overall picture because, quite frankly, I am stuck on that right now. I have several evaluation functions for "good defensive terrain" etc., but nothing yet that would, for example, consistently find the best defensive formations (as opposed to individual unit placement).

So, if you have suggestions for a different behavior that you would like to see and you can describe it very specifically, I'd be grateful for any ideas. Or if you have, say, as sample map for which you can specify exactly where you want units to be during different parts of the day and what they should do there, I'd be happy to take a shot of that.

[Crab]

So, if you have suggestions for a different behavior that you would like to see and you can describe it very specifically, I'd be grateful for any ideas. Or if you have, say, as sample map for which you can specify exactly where you want units to be during different parts of the day and what they should do there, I'd be happy to take a shot of that.

A good and useful thing to have would be a way to teach the AI to 'protect' certain unit (which might not be a leader), while moving the unit to location B and doing attacks-of-opportunity (where the unit can't be easily hurt). For example, in HttT 1, Delfador should not die, but it's useful to attack with him; so, if we want the AI to play HttT 1, we must teach it how to use Delfador to help move Konrad to the target location, yet to avoid getting him killed.

For example:
0) this is for unit with ID=id
1) do not attack with that unit in normal attach phase
2) do not move this unit in normal strategic move-to-targets phase
3) just-after-combat, if there's good attack available which can be done without exposing this unit to heavy this-turn or next-turn retaliation, do it.
4) if the unit is threatened, retreat or cover him with other units.
5) otherwise, try to move closer to a target hex/unit, but not on exposed locations.

Right now, AI doesn't know how to handle should-not-die units, any improvements would be great.

Note: I can send you the patch which lets the AI play campaigns in unattended mode, auto-clicking through messages, or you can just use :droid

[mattsc]

Hi Crab, thanks much for the suggestion. Interestingly, in one of my campaigns I have a scenario in which you have to escort a cart and among the protectors are 3 units that may not die. I have started working on making the AI do that (but haven't gotten very far yet). The way you describe it splits it up into several parts that seem more manageable. I will look into that, thanks!

Note: I can send you the patch which lets the AI play campaigns in unattended mode, auto-clicking through messages, or you can just use :droid

Is there a real advantage of using the patch over :droid? For testing something like this, I would work with an "skimmed down" version of a scenario anyway, without message and unnecessary events. Maybe later this could be tested for a number of existing campaigns, but that's a long way off.

[Crab]

Is there a real advantage of using the patch over :droid? For testing something like this, I would work with an "skimmed down" version of a scenario anyway, without message and unnecessary events. Maybe later this could be tested for a number of existing campaigns, but that's a long way off.

the patch allows the AI to play a campaign, when wesnoth is launched from command-line. AI auto-skips dialogue (choosing option 1 when necessary), and jumps to next scenario on it's own. It's not that useful if you're testing a single scenario, but is useful if you want to test a campaign.

[mattsc]

the patch allows the AI to play a campaign, when wesnoth is launched from command-line. AI auto-skips dialogue (choosing option 1 when necessary), and jumps to next scenario on it's own. It's not that useful if you're testing a single scenario, but is useful if you want to test a campaign.

That sounds like a neat patch, but as you said, probably not that useful for me right now. I'll probably get back to you later about it though. Thanks.

[mattsc]

Crab, All:
I have taken a very first step in the direction of a 'protect a unit' algorithm. It's available in scenario "Protect the Wizard" of the "AI-demos" campaign v0.4.2. Currently it does this:

- Do not participate in normal combat phase
- Just after combat, move the unit to a spot that is close to own units and as safe from enemy attacks as possible
- All remaining units do the normal move-to-targets phase

As I said, it's a first step and very simple, but I think it already does reasonably well.

Question: currently I have the protected unit move to a safe location based on where units that did not partake in combat could move in the move-to-targets phase. It would be better to do this after they actually did move. However, that would mean that I have to exclude my protected unit from the move-to-targets phase (just as it is excluded from combat with the attacks aspect and [filter_own]). Is that possible? I didn't find a similar aspect/facet for the MTT phase. If it is not possible, I could write a candidate action that takes attacks and moves away from the unit at the beginning of the AI turn, and another that gives them back at the very end and executes the move, but that seems ... unnecessarily complicated unless that's the only way.)

Next steps:
- After the combat phase, have the remaining units move around the protected unit in order to protect it actively
- Add low-risk attacks for the protected unit


As always, any kind of feedback and suggestions for improvements would be very helpful.

[Anonymissimus]

I looked at the patrol scenario.

• You unfortunately took over the terrain Ggf from my map which is deprecated and removed in trunk so the map no longer loads (wmllint should have caught it actually )
• Jabb did not attack for me.
• I see always that you embed the lua code in the scenario so that it can't be modified on-the-fly. If patrol_ai (for Konrad's moves) was a global table, not a local one; and the scenario had a right-click menu which called wesnoth.dofile for a pure lua file *and* a "main" function from that file after reloading it. That main function wrote into the global patrol_ai table the functions which you put into the [engine] tags, and changes to them resulted in changed ai behavior without the need to restart the scenario - so would that or similar thing work ? If not I'm very reluctant to make anything with lua AI.

EDIT
Looking at the code I see the condition is not "in range" but "adjacent". However, even that didn't work.

[mattsc]

You unfortunately took over the terrain Ggf from my map which is deprecated and removed in trunk so the map no longer loads (wmllint should have caught it actually )

It would have, wouldn't it. Thanks, I'll take care of that...

Jabb did not attack for me.

Looking at the code I see the condition is not "in range" but "adjacent". However, even that didn't work.

The way it is set up in 'A Rough Life' and how I adapted it from there, is that Jabb attacks at the end of his move. As in, he moves along his route first. If he ends up next to Jacques by accident, he attacks. He does not seek him out in order to attack and he doesn't attack if he is next to him at the beginning of the move. If you move Jacques to 8,13 on the first move, will Jabb attack him?

I see always that you embed the lua code in the scenario

Yeah, that's a bad habit of mine that I've already decided I need to change, I just haven't done so yet. In fact, there's a bunch of stuff in those scenarios that needs cleaning up. However:

so that it can't be modified on-the-fly. If patrol_ai (for Konrad's moves) was a global table, not a local one; and the scenario had a right-click menu which called wesnoth.dofile for a pure lua file *and* a "main" function from that file after reloading it. That main function wrote into the global patrol_ai table the functions which you put into the [engine] tags, and changes to them resulted in changed ai behavior without the need to restart the scenario - so would that or similar thing work ? If not I'm very reluctant to make anything with lua AI.[/list]

I do all my testing with on-the-fly changes and a right-click menu option. (Only when it is all done do I copy it into the scenario file.) Check out Testing setup on the 'Lua AI Howto' page which gives a step-by-step procedure of how to set this up. Most of it should be pretty obvious, but there are a couple little tricks you need, such as letting the AI play through one move before you take control of the side, otherwise the 'ai' table with all the AI functions is not populated.

Thanks for the comments and please let me know if I should change anything on the wiki for clarity or completeness. (P.S.: one thing I do need to change is the statement that a preload event is necessary. It is not, or at least not under all circumstances.)

[Crab]

"However, that would mean that I have to exclude my protected unit from the move-to-targets phase (just as it is excluded from combat with the attacks aspect and [filter_own]). Is that possible? "
For historical reasons, ai_special="guardian" (in the unit definition) was supposed to achieve that ( see src/ai/testing/ca_testing_move_to_targets.cpp +296 ) - so, try it. If it doesn't work, it's a bug.

[mattsc]

For historical reasons, ai_special="guardian" (in the unit definition) was supposed to achieve that ( see src/ai/testing/ca_testing_move_to_targets.cpp +296 ) - so, try it. If it doesn't work, it's a bug.

Oh, right. I've used the guardian many times and didn't even think of that. Doh!
However, it seems that this is dealt with by the AI by effectively taking the moves away from the unit rather than by excluding it from consideration altogether. So operations like ai.move_full(), [store_reachable_locations] and wesnoth.find_reach() give results as if the unit had moves=0. That's all easy to deal with, I'm just pointing it out for future reference.

[Elvish_Hunter]

Jabb did not attack for me.

Looking at the code I see the condition is not "in range" but "adjacent". However, even that didn't work.

The way it is set up in 'A Rough Life' and how I adapted it from there, is that Jabb attacks at the end of his move. As in, he moves along his route first. If he ends up next to Jacques by accident, he attacks. He does not seek him out in order to attack and he doesn't attack if he is next to him at the beginning of the move. If you move Jacques to 8,13 on the first move, will Jabb attack him?

In case that it may be interesting, I just tested on Wesnoth 1.10.0, Windows 7-64 bit, and moving Jacques to 8,13 Jabb attacked him. Not only this, but Jabb hit twice leaving Jacques with only 3 HP. Ah, that's a rough life for a thief...

[mattsc]

You unfortunately took over the terrain Ggf from my map which is deprecated and removed in trunk so the map no longer loads (wmllint should have caught it actually )

I seem to be too stupid for this... I ran wmllint and it didn't tell me anything about the terrain being deprecated. I also searched the 1.10 changelog for 'Ggf', which does not mention it either. I am confused now. You said trunk, so is this for 1.11 or am I missing something else?

[Alarantalara]

* flower base terrain is deprecated, now available as an overlay

It's not mentioned by code in 1.10, but is indeed deprecated. It's still present in 1.10 (except in the editor) so maps produce no error at the moment, however it has been removed entirely in trunk, so anything using it will eventually not work.

[mattsc]

* flower base terrain is deprecated, now available as an overlay

It's not mentioned by code in 1.10, but is indeed deprecated. It's still present in 1.10 (except in the editor) so maps produce no error at the moment, however it has been removed entirely in trunk, so anything using it will eventually not work.

Ah, ok. I had only searched for the 'Ggf' string, not for the words (and in the meantime I have found the trunk changelog as well, which mentions it by string name). I'll change that, and then go over the 1.10.0 and 1.11.0-svn changelogs more carefully to see what else I might have missed. Thanks!

[mattsc]

I just posted v0.4.3. This is a maintenance update with no functionality changes (except that, hopefully, it will now work in trunk also), see changelog below. I am mentioning this for two reasons:

1. Lua engine functions are now loaded in the scenarios from separate Lua-only files. In the engine, that leaves something like this:

   Code: Select all

               [engine]
                   name="lua"
                   code= <<
                       ai = ...
                       return wesnoth.require "~add-ons/AI-demos/lua/patrols_engine.lua" 
                   >>
               [/engine]
   

   which only works if 'ai = ...' is defined as a global variable (at least if there are calls to the 'ai' table functions). That, in turn, means that there is a conflict if more than one side with custom AI engines exists (and apparently even if one of them is Lua AI and the other Formula AI, at least in some cases). Thus, the 'ai' variables need to be given different names, for example 'ai_side2 = ...' and 'ai_side3 = ...' -- and that means that the ai command functions need to be called with 'ai_side2.move()' etc. I am just writing this down here so that it is documented. I will also add it to the wiki.
2. I pulled a lot of the common functions out of the Lua engines and put them into ai_helper.lua, which now includes many more functions.

The full changelog:

Spoiler:

Code: Select all

0.4.3, 20 Feb 2012
- Maintenance update
  - Pulled all the Lua AI engine code out of the scenario files into separate engine files.  This requires some changes to local vs. global variables, and adjustments if more than one engine is present in a scenario
  - Pulled common functions out of Lua engines and put into ai_helper.lua
  - Some other minor changes based on wmllint and wmlindent output
- Patrols:
  - Changed map terrain: Ggf -> Gg^Efm (so that it'll work in trunk)

0.4.2, 19 Feb 2012
- General
  - Added ai_helper.lua
- Protect the Wizard
  - Added first, very simple, version of this scenario

0.4.1, 13 Feb 2012
- Patrols:
  - Fixed Jabb behavior to go toward occupied waypoint also

0.4.0, 12 Feb 2012
- General:
  - Eliminated preload macro from all Lua AI code
  - Changed message font size handler to use new wml_actions Lua function
  - Overall editing for comments, translatable strings
- Patrols:
  - completed scenario with Urudin retreat behavior

0.3.2, 8 Feb 2012:
- Patrols:
  - Added goblin handler Jabb patrol
  - Changed Konrad code so that it only applies to Konrad, not all units of that side

0.3.1, 7 Feb 2012:
- General:
  - Added first (still imcomplete) version of 'Patrols' scenario
- Guardians:
  - Added 'home guard'
  - Added "normal" non-guardian units

0.3.0, 3 Feb 2012:
- General:
  - Added 'Guardians' scenario
- Pass Defense:
  - Reduced map size

0.2.0, 29 Jan 2012:
- General:
  - Now on BfW 1.10!!
  - Added 'Lurkers of the Swamp' scenario
  - Minor changes to wording in several scenarios, files

0.1.3, 28 Jan 2012:
- General:
  - Added 'Grnk the Rouser' unit file
- Switchboard:
  - Changed right-click context menu so that scenario overviews are only visible in 'switchboard' scenario
- Pass Defense:
  - Fixed a minor bug in the level-up attack selection and move execution
  - Made attacks a bit more conservative
  - Added wesnoth icon to question for player

0.1.2, 27 Jan 2012:
- Pass Defense:
  - Positioning/attacks now take XP into account
  - If level-up will definitely or likely follow an attack, do this attack first thing
  - Orc leader is now Orcish Leader (was Orcish Ruler)
  - Don't load WLP debug_utils in preload event any more, to avoid dependency on WLP
  - Spearmen now always advance to Javelineers
  - A few minor tweaks to the algorithm

0.1.1, 26 Jan 2012:
- Pass Defense:
  - Changes to improve speed of move evaluation
  - Healer and leader don't take center hex on front line any more
  - Lieutenant can now hire spearmen and bowmen

0.1.0, 24 Jan 2012:
- First version, with Pass Defense scenario