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

[Alarantalara]

Maybe the leader, but if the mage goes there, it would just get hit by two grunts and do virtually no retaliation damage, which will remove it from the fight for a long time when I'd prefer to be able to attack with it. Also, spearmen have about the same health as the mage, so there isn't any real increase in survivability.

[mattsc]

Removing the leadership would definitely make it harder for a human player. The RCA AI didn't seem to use the leader at all, so it probably doesn't really matter.

I think I'll just make him an orcish leader (instead of orcish ruler). That way he has leadership but it doesn't help until he levels up.

As for allowing human play to be a gimmick, I found it very useful since when I went through it as a player I had to think about what weaknesses there were that I could exploit, which made it easier for me at least to see what the AI was doing incorrectly. I didn't experience that level of critical thought when I just watched the AIs play each other.

Ah, yes, another good point. I'll just claim that that was my intention then. Actually, simply the fact that you had to think about it counts as a success in my book.

On the other hand, the center hex has only 40% def, and it can be attacked by 2 units, which means that if a spearman is there it can die, while the leader or mage perhaps can't due to higher hps. So if there's zero chance to loose the unit I would move it there anyway.

and

Maybe the leader, but if the mage goes there, it would just get hit by two grunts and do virtually no retaliation damage, which will remove it from the fight for a long time when I'd prefer to be able to attack with it. Also, spearmen have about the same health as the mage, so there isn't any real increase in survivability.

There's also the question of how to calculate that there's zero chance to die. Calculating it for the two closest units (or the two strongest in the general area) is easy enough. But then one unit could die while attacking (especially if it's an archer against the mage) and then suddenly you're up against 3 attacks. All that can be calculated, of course, but maybe this "less ambitious" project is getting more complicated than I had bargained for. No, but seriously, this discussion really helps me a lot, please keep the comments coming. I'll put out an updated version soon.

[Max]

how fast is it on your machines?

mine is pretty decent but it's noticeable slower (was using 1.9.14 as suggested) and usually these things don't scale well with the number of units involved. right now i'd expect it to be too slow to be fun on older machines or with more units on the field.

[mattsc]

how fast is it on your machines?

mine is pretty decent but it's noticeable slower (was using 1.9.14 as suggested) and usually these things don't scale well with the number of units involved. right now i'd expect it to be too slow to be fun on older machines or with more units on the field.

Hmm... In my case (I have a reasonably new Mac), there's an almost unnoticeable delay. In fact, I had not not noticed it until you said this. When I go to 400 gold for the side (~22 units), this delay increases to about 0.25-0.5 seconds and seems about the same for 1.9.14 and 1.9.9 (eye-balled, not measured).

I'll see what I can do to speed things up. There's very likely something that can be improved simply because I don't know how some of the code does things. For example, my first version was a lot slower, until I noticed that

Code: Select all

local is_healer = (u.__cfg.usage == "healer")

takes a lot of time. I thought that that's just accessing a variable, but apparently there's more to it. So I pulled that out of the loop and things got a lot faster.

I'll look into it. Thanks for pointing this out!

[Anonymissimus]

The __something fields are expensive.
-Try to avoid using them at all.
-If you need them, try to use the __shallow_* ones.
-If still needed, try to access them only once.
local u = u.__cfg
for ...
...u.some_value
end

etc

The __parsed one is the most expensive I think. Also, it's often easy to add read access for certain variables so a feature request can speed up things.

[mattsc]

Max: I think I've eliminated the biggest time sink and uploaded v0.1.1. In my case, there's no noticeable delay left, even with 25 units on the map. Could you check this out and see if it works better (faster) now?

I've also made a couple other of the easier changes (haven't had time for the rest yet). Here's the changelog:

Code: Select all

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

Anonymissimus: Thanks for the information, that's good to know. Currently, I am accessing u.__cfg twice per unit per move (at most 20 times total). I could cut this down to half that, but my guess is that that's not the main time consumer, so I'll leave it for now.

[Max]

Max: I think I've eliminated the biggest time sink and uploaded v0.1.1. In my case, there's no noticeable delay left, even with 25 units on the map. Could you check this out and see if it works better (faster) now?

blazing fast now.

[mattsc]

blazing fast now.

Great!

Does anybody know how the AI decides what unit type a unit advances to if there are several choices and whether it is possible to override that? With the strategy I am using in the holding-the-pass scenario, one of the bigger problems occurs when the spearmen advance to swordsmen or pikemen. I even had one advance to a royal guard once, just to be slaughtered by a couple of measly orcish archers. I could, of course, change the AI behavior from defensive to offensive in those cases, but I'd rather have all spearmen advance to javelineers and keep the defensive strategy. I can think of different ways to do this:

• Use an 'advance' or 'post advance' event and transform the unit manually: this will either be awkward (post advance) or cause continuity errors (advance; I haven't tried it, but my guess is that I'd have to change underlying_id for this to work at all)
• Change the spearman unit type to advance only to pikeman. I'd rather not change this for all spearman.
• Use a 'recruit' event to change 'advances_to' for the spearmen recruited in this scenario.

I guess that, of these options, I like the last one best, but I'd still prefer to build something into the modified AI so that it is self-contained and relies on external events as little as possible.

[mattsc]

AI-demos v0.1.2 is on the server.

The highlights:

• If an attack will definitely, or at least most likely, result in leveling up, this move is done first
• XP are taken into account for positioning and attacking
• Spearmen now always advance to javelineers
• The 'require' error Max encountered has been fixed

As a result, the AI now plays (much?) better than before and wins against the RCA AI even more often with 8 recruits. (Note that this is a somewhat arbitrary test, and that I've never seen it lose at all with 10 recruits.) Using high-XP units preferentially also puts them at higher risk of being killed, but I think that it's overall the better strategy.

Issues:

• This might be a little slower than before again. If somebody could test that, that would be great. The problem is that I am working around some Lua AI functionality that isn't there yet. I think I have it at a reasonable speed now, but if it seems slow, please let me know.
• There still seem to be some minor bugs in the code, causing "E_NOT_REACHED_DESTINATION" errors etc. This shouldn't cause any major problems other than the AI sometimes not doing the best move(s). I'll look into this.
• 'Return value of AI ACTION was not checked' error still needs to be fixed

Any comments, in particular on bugs or suggestions for improvement, will be much appreciated.

[mattsc]

I found the remaining bug, and also tweaked the behavior a little more (making it slightly less aggressive in the attacks). As a results, AI_demos v0.1.3 is uploaded.

As far as I am concerned, this is the last version of the Pass Defense scenario, unless somebody finds more problems or weaknesses. I've had it play against the RCA AI all afternoon and have not seen it lose a single time. To be honest, I think it is getting harder to beat it as a human player. Of course, it's always possible to win simply by attrition, but doing so reasonably quickly is not all that easy, I think.

The one suggestion I did not implement is to have the mage attack from a hill hex whenever possible. The mage will take position on those hexes if needed, but unit positioning remains solely based on defensive considerations (with the exception of level-up attacks). It's a choice I made mostly to keep the algorithm as simple as possible. Adding more offensive elements should not be too hard if that is desired for other applications.

The next step now is to add the other AI modifications of this thread and the wiki page to the campaign. Then I'll start working on the next project. I'm not quite sure yet what that will be. Escorting a cart full of magical prunes through an area swarming with undead is an option...

[Rigor]

this thread is interesting. do you have some experience letting the AI play smarter on any other map than the pre-designed scenarios?

[mattsc]

this thread is interesting.

Thanks. I certainly think so. (rolling my eyes at myself, not you)

do you have some experience letting the AI play smarter on any other map than the pre-designed scenarios?

Well, depends what you mean. I have done quite a bit of playing with different aspects of the AI, in particular with the placement of units based on terrain and not attacking under all circumstances. In fact, I was fiddling with that again at the time your post came in. On the other hand, I am a long way from having an AI that does better than the default under general circumstances. The standard AI really does rather well with that. I am working on it, but having had no previous exposure to the topic it's slow going and a lot of trial and error.

I don't know how many of the posts in this thread you've read, but I am frequently asking for suggestions and ideas along those lines. So if you have any, or experience with or interest in the topic, I'd really like to hear about them.

[Alarantalara]

I've been exploring some more of the AI routines you've placed in the scenario, and the patrol/waypoint AIs feel excessively easy to immobilize.

Standing on any of Jabb's waypoints prevents movement for Jabb entirely.
Meanwhile, the Konrad imposter is incapable of moving around a single footpad at 19,11

Finally, I had to change all the swamp lurkers to be on the same team to avoid watching most of them quickly die from infighting.

[mattsc]

Hey, cool, thanks for doing that!

Standing on any of Jabb's waypoints prevents movement for Jabb entirely.

I think I fixed this (v0.4.1). He will now try to go toward the next waypoint whether there's an enemy on it or not. He will keep trying to go there until it is free, rather than skipping it and going to the next one. Depending on one's point of view, that could be the desired behavior or not. I guess I could add another patroller who does it the other way...

In the process, I noticed that Jabb goes to WP 2 after a reload, no matter where he is on his route. This is because the value of the current waypoint variable gets lost over save/load cycles. There are several ways to fix that...

Meanwhile, the Konrad imposter is incapable of moving around a single footpad at 19,11

Thanks, I hadn't noticed that. This is because the goal is set using goto_x,goto_y coordinates, which always tries to move the unit in a straight line, even if that leads into a dead end. It would probably be better to do a Jabb-like algorithm for Konrad as well.

Finally, I had to change all the swamp lurkers to be on the same team to avoid watching most of them quickly die from infighting.

Ah, yes, I actually did that intentionally. That way you can sit back and watch the lurkers do their thing without having to do anything yourself. It's also why the player has the right-click options for adding new lurkers. How about I give the player the option of having the lurkers fight each other or work as allies at the beginning of the scenario.

Thank you very much, this is great feedback! I'll take care of the remaining issues over the next few days.

[Rigor]

sorry for not replying to your previous post - i forgot it completely. no i havent read all previous posts, i DLed the addon and saw the results. i quite like what i see, especially that the AI is not ALWAYS attacking stupidly, perhaps the "sit on a village" stance might be used to tweak the real AI we have. i, who have no experience wiht AI programming, envision a "global command" to defend, rather than "attack always no matter what". what i would find particularly interesting and possible would be this: a time-of-day dependent script that give the undead information when its a good idea to open the gates and when to rather stay put.

just imagine this: the ai sees second watch, switches from extra-cautious loyalists to "formation of attack" loyalists, and dawn they are somewhere in the center of the map, and when its DAY, they are in position to fully use their powerplay, kill stuff, take villages etc. like the normal ai would (use normal AI for that script). in contrast, during the second turn of day 2, the treshold to attack is much higher and they are more reluctant to execute the aggressive mode. some formulae and defined parameters could give the AI a good "feeling" when to go home or continue. then, during dusk and night they go back to their villages, use all defensive terrain they can see, and yeah... defend

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

cheers R