More AI observation of playing against the computer

[shevegen]

It appears to me - and I may be wrong - that the AI favours maximizing damage via its units
first and foremost; and secondarily, killing one of the player's units. So, this allows us players to
"draw" (kite) away enemy units, where they will try to rush in, in order to kill weak units. And on
the next turn, we (the players) can then kill those enemy units that moved forward. This is not the
only behaviour though - sometimes when there are too many of my units aggregated, the enemy
units wait in aggregation, perhaps for another turn. Quite funny to see how they pull back a bit.

I did, however had, also notice something else just now.

As I am playing To Lands Unknown, one enemy unit was attacking one of my units,
weakening it; but then the next enemy unit, was not attacking that wounded unit
but another unit - probably because it can deal more damage, and the AI favours
that.

This makes sense, but sometimes you need to control the game map and must
kill certain units. I understand that this may be hard to code, but with the current
behaviour it seems as if the computer never makes strategic decisions and always
favours short, max-damage behaviour. For many maps this may not be problematic
but for some maps this can be problematic. And in the map I am now playing, I
already gained dominance of half of the map, so the behaviour of the enemy units
where they go forward to deal more damage, really does not help them as I
will just heal up on the next turn(s). They would have been able to do more if
they would have stood in aggregation, rather than moved forward; or, if they
would really want to, injure my already injured unit more, even if it does not
kill that unit on this turn. That unit would need to pull back and heal up for a
few more rounds as a result.

I understand that this is also hard to code, but if we ever have some developer who
understands AI stuff or tactics stuff, perhaps some more thought could be given
here. Or perhaps more AI behaviour that yields more flexibility, such as "filing
the ranks" (e. g. minimize how many units can deal damage to you; in one file
if all are standing next to one another, only two enemy units can hit, so this
should be the best strategy if applicable, unless some units would die quickly
and then create an opening in the ranks).

[beetlenaut]

It appears to me - and I may be wrong - that the AI favours maximizing damage via its units
first and foremost; and secondarily, killing one of the player's units.

Yes, and the scenario designer can set some parameters like how much the AI worries about retaliation damage. It takes forever to test different values though, so most designers just go with the default. They adjust the difficulty mostly by changing the amount of gold the AI gets instead.

but sometimes you need to control the game map...I understand that this may be hard to code

It is easy to code, but it is hard to define. The AI could have a mode where it "controls the map" (whatever you mean by that), but what can it look at to determine that it needs to change to that mode? There needs to be a formula using just what you can see: owned villages, hitpoints of units, unit paths to favorable terrain, how clumpy the forests are, and so on. There are probably a hundred bits of data and millions of ways to rearrange them, and for each one a million different values for the numbers. Then you need to determine what moves need to be made in that mode, which compounds the problem by a few thousand times. Then, you need some way to measure which set of values makes it harder for most players, so each one needs to be tested for a dozen or so games. The lifetime of the universe probably isn't long enough to create this mode. And, that is only one possible AI mode. You also said that there should be a mode where the AI tries to "kill a certain unit," or "fill the ranks." Those present the same problem.

The current AI does pretty well, considering how little information it actually uses on each turn. Anyway, the understanding of the programmers isn't the barrier to making it better.