Combat Mod AI projects

[Thunderbrd]

I have a number of projects regarding AI to flesh out the combat mod in preparation for eventual full use. I was thinking about how to go about some of these and realized I should probably bring each up here and let us discuss the best ways to implement them.

Not wanting to address everything at once, I figure its a good idea to keep focused on one issue at a time.

So to get started, I'm thinking the first issue to address is Equipment.

In review:
Currently Equipments are delivered to qualifying (usually by combat class) units by buildings when tech and resource requirements are met. If such a unit is built from a city or moves into a city offering a particular Equipment promo, the unit will automatically pick up the Equipment.

Equipments work along Promotion Lines. Equipments of higher Line Priorities than what exists on a local unit will automatically replace the Equipments those units have in the same Promotion Line. (assuming qualified to receive the better promo.)

I've just finished including a feature that allows us to have multiple Equipment Promotions on the same Promotion Line rating at the same Line Priority (representing promotions that are filling the same kind of slot, for example, arrows, but are equivalent to each other, not better or worse but different in effective benefits/penalties.)

Lateral Equipment choices like this allow a unit with an Equipment Promotion that exists in a city that offers such an equivalent (and equally qualified for) selection to choose to switch promotions. Thus, for example, a Unit that has Steel Arrows (Arrow Promotion Line) can switch to Flaming Steel Arrows (Arrow Promotion line with the same Line Priority as Steel Arrows) if its in a city that offers Flaming Steel Arrows, and toggle back to Steel Arrows as well if the city also offers Steel Arrows.

I've also designed a method by which we can allow units to NOT automatically update to an alternative style in the same line.
A tag for Equipment Promos:<NoAutoEquiptoCombatClassTypes> allows us to define combat classes that, while they may be able to qualify for this equipment promotion, they do not automatically TAKE this promotion if its available, instead requiring a Re-Equip action to select this promotion instead.

Thus we make, say, Flaming Steel Arrows give the SubCombatClass 'Flame Wielders' and give all other arrow types the tag NoAutoEquiptoCombatClassTypes a definition for Flame Wielders so that once an Archery unit selects any Flaming Arrow type Equipment it will wait for an equivalent Flaming Arrow style Equipment without jumping to upgrade as soon as the next basic Arrow equipment level has become available in the city its in.


So.... where's the AI here? There's a few things to consider.

The first AI task that needs to be developed is to get the AI units to recognize when, if those units are not in a city that has just achieved a better equipment than they currently possess and that they can qualify for, it becomes appropriate for them to move to that city for an upgrade. (It seems they need to be in the city at the end of a turn to pick up the upgrade at the beginning of the next turn.)

Then of course, once they recognize that the time is appropriate for them to do so, they need to move to that city for the upgrade and return to whatever they were doing before once they have it.

Now, generally I would assume that most of the time an Equipment upgrade is earliest to be reached along the basic Equipment line path and any alternative equivalent options will either be reached at the same point OR still have something yet to develop thereafter (a building to give access, or a tech still to reach.) Thus, Steel Arrows would probably be available at a particular tech with a fletcher in the city while Flaming Steel Arrows would only be available with an additional prerequisite of a tar pit in the city or access to oil... perhaps even an additional tech, even though you may already have access to Flaming Iron Arrows. Therefore, I would think units that have taken alternative equipments along the same line should only be looking to go out of their way to upgrade along the same type they have now. But at some point they'd still find it worth taking a more advanced alternative option if that's all that's available.



But that's not what I wanted to fully focus on here. No... I first just want to establish WHAT exactly makes it worth pulling the unit out of doing whatever its doing to go out of its way for an upgrade. From what I understand, units begin to act as one larger entity when they are formed into stacks. At what point should the stack act to go get its units upgrades? Obviously the situation the nation is in and the missions the units are on should have a lot to do with it.

So we have a growing positive value, countered by a resistance value (the 'its just not worth it at the moment' value) and a threshold of positive value that must be reached to trigger the unit/stack to move towards available upgrades.

And how do we define it all? In process at least? And I wouldn't mind getting some advice from Koshling here on how to best interface with the current AI structure when applying these evaluations and action commands as well.

Anyhow, ideas and guidance are welcome.

 

[Koshling]

From what I understand, units begin to act as one larger entity when they are formed into stacks. At what point should the stack act to go get its units upgrades? Obviously the situation the nation is in and the missions the units are on should have a lot to do with it.

The AI can split stacks if it has cause to. Obviously you need to write AI to have it examine when to do so though.

 

[Thunderbrd]

The AI can split stacks if it has cause to. Obviously you need to write AI to have it examine when to do so though.

Would it be better for the stack to remain consistent and simply move as a group when a certain value is reached for the units within it or would it be better to split the stack and send its upgradables out to the cities offering the new equipments and have them return when those units are finished?

 

[Koshling]

Would it be better for the stack to remain consistent and simply move as a group when a certain value is reached for the units within it or would it be better to split the stack and send its upgradables out to the cities offering the new equipments and have them return when those units are finished?

Well. It depends doesn't it. One can probably come up with examples in both directions

 

[Thunderbrd]

Don't we have some processing concerns if we over-evaluate best courses of action though? From that angle, shouldn't one or the other process be considered only? Getting the AI to consider either one would be a number of additional calculations that could be bypassed by a more generic method wouldn't it?

 

[Koshling]

Don't we have some processing concerns if we over-evaluate best courses of action though? From that angle, shouldn't one or the other process be considered only? Getting the AI to consider either one would be a number of additional calculations that could be bypassed by a more generic method wouldn't it?

Possibly. Depends if you can cheaply determine that a more detailed analysis is worthwhile, and that it will be only in relatively are cases

 

[Dancing Hoskuld]

One thing that should be considered is that units on the way to do a job, going to a rally point, or even just patrolling, should consider going via a city that can give them an upgrade if it is not too far out of the way.

 

[Thunderbrd]

Do you think it should only consider cities 'on the way' or should it evaluate the 'nearest city with an upgrade (plus the value of the upgrade)' and how far that city is away from the rally point?

 

[Dancing Hoskuld]

As I was typing I was considering the first move being away from the destination. It probably depends on the urgency at the time, if there is no war and no barbarian threats then a saunter through the nation picking up equipment is not a problem. However if there are barbarians at the gate getting there is the priority.

 

[Thunderbrd]

Ok. Makes sense.

So far I'm thinking something along the lines of:

1) A function that detects newly available equipments in the nation and tallies up a 'desire' value for any given qualifying unit.
2) A function that determines the 'resistance' value for any given qualifying unit.
3) A function that determines the 'average desire value' for a stack.
4) A function that determines the overall resistance value for the stack itself.
5) A function that determines the viability of splitting the stack to allow those with strong enough 'unit desire vs stack resistance' to split off from the stack, while tagging the stack as something to rejoin with later.
6) A function that compares, for units not in stacks, their desire vs resistance and determines if the unit should put getting the upgrade ahead of its current order.
7) A function that evaluates average stack desire vs overall stack resistance to determine if its valuable enough to take the stack on a tour through the nation that would allow all its units to get the desired upgrades.


In each of these cases then, the previous mission order would be stored and recalled once the 'go to equip' mission was carried out.

Every one of these evaluations needs to take all necessary variables into consideration. Thus, we can zero in on those variables as well.

And of course distance between current location, any target location of the current mission, and the closest providing city would be a major variable in establishing desire. So the desire variable would operate a little like gravitational pull, the closer the unit is to the city offering a benefit, the greater the desire to go there for the upgrade.

Units at war with wartime objectives would have a great deal of 'resistance' factor, as the target is more important than a minor boost unless the minor boost was significantly easy to achieve and wouldn't greatly throw off the overall eta on mission goal achievement by much.

So... zeroing in on the first variable, desire, what would be all the factors that should be taken into consideration when BUILDING the desire variable?

 

[Baskedyt]

[Off topic]
Where is the forum/thread for this new "Combat mod"? I would like to read more about it.

I've been reading about it, in parts, in different threads in this forum, but haven't found "the mother load".
Is it just hidden in a thread by a different name? Like in the "promotion" thread. I've read like the last 100 posts, but it still doesn't feel like the original thread for that debate.

Thanx.

 

[Thunderbrd]

You can find links to all the main Combat Mod info in the Modder's Documentation thread.

 

[ls612]

[Off topic]
Where is the forum/thread for this new "Combat mod"? I would like to read more about it.

I've been reading about it, in parts, in different threads in this forum, but haven't found "the mother load".
Is it just hidden in a thread by a different name? Like in the "promotion" thread. I've read like the last 100 posts, but it still doesn't feel like the original thread for that debate.

Thanx.

Much of it has not yet been implemented, just so you know.