Tweet
Regarding Implementation of AI (repost from Suggestions, June)
REGARDING SPECIFICS OF IMPLEMENTATION OF AI
While I do understand some of the underlying principals of AI design, I guess what I know in a total way is very minimal indeed. I have nothing but respect for a good AI, and its programmer, for this reason.
As far as I tell, the CtP1 AI was a form of list processing. The AIP and FLI files were the parsed files that were conditionally processed, producing weighted answers as to what should happen. The results were
‘hints’ to the games AI dll, as to what should be done.
There are two main challenges that the new AI has to meet.
First is its obligation to pose as an effective threat to the player, by doing three things militarily; first building good stacks, second put those stacks on transport, or many transports (and reconstitute the stack at the other end) and lastly attack with those stacks. The only way that the AI was TRULY effective (at least overseas) was as a nuisance, by employing special unit attacks. The reason for this, is that one special unit can be effective. However, grouping was never a thing it did very well at.
Secondly, newly created units (created by scenario designers) might have a very tough time, since they, unless some thought is put into AI behavior, will be unused by the computer. This ultimately means that certain scenario units could be unnecessarily unbalancing. The way to solve this, of course, is to have enough groupings of behavior where the new units could fit in. Behavior can generally be defined as movement and attack, since you can ‘preempt’ combat and do something ‘clever’ in SLIC or do something during or after movement.
There was the concept of grouping units by type and them having behaviors, in CtP1.
The problem is… that there were not enough groupings for customizing, and the way the units were described was by static tokens… yes?
The archetypal new custom unit in CtP1, which was employable by the user, but not the AI was the cruise missile. It was one shot, offensive… preferably against towns… or carriers, so it should be grouped for best effect, unlike a nuke. Perhaps carried by subs or ships…(not carriers), and not travelling on its own, except to get into position.
The defensive version of this, which I would like to have seen, though for technical reasons (lack of size classes,) it was impossible, is the Anti Aircraft Missile. A one-shot ship or land-carried unit, that would be used in response to threats within its range radius. Of course, certain people might say… this is too specific. Civ is all about abstraction. However, scenario designers should be given freedom to express their ideas in a flexible product. That is ultimately what the culmination of “Civ” should be.
These are two examples, but I can imagine another… a non-attacking, non-settling unit; one that either explores new sea or land territory, or wanders already discovered land or sea, in settled or unsettled regions. With SLIC, these movement patterns could be put to use, in ways that we don’t know now, but I’m certain will have great use later.
The extra or replacement AI unit classes that I am suggesting are:
SINGLE_SHOT_LAND_OFF
SINGLE_SHOT_SEA_OFF
SINGLE_SHOT_AIR_OFF
SINGLE_SHOT_TERROR (nuke)
SINGLE_SHOT_LAND_DEF
SINGLE_SHOT_SEA_DEF
SINGLE_SHOT_AIR_DEF
POWER_PROJECTION_SEA (the carrier, and sub?)
POWER_PROJECTION_AIR (nuclear strike aircraft)
POWER_PROJECTION_LAND (for completeness?)
WANDERER_LAND_EXPLORED_SETTLED
WANDERER_LAND_EXPLORED_UNSETTLED
WANDERER_SEA_EXPLORED_SETTLED
WANDERER_SEA_EXPLORED_UNSETTLED
WANDERER_AIR_EXPLORED_SETTLED
WANDERER_AIR_EXPLORED_UNSETTLED
WANDERER_LAND_UNEXPLORED
WANDERER_SEA_UNEXPLORED
WANDERER_AIR_UNEXPLORED
The problem of the static tokens in the AI file has to be remedied by moving their specification to where the units are defined; units.txt. I understand this is yet another line and flag to be added, and parsed. You could do vertical partitioning of the data, and split the property into another file… something like unitAIdef.txt or whatever. However, its important that if you want to have a customizable game, that you allow specification of a unit as within an AI behavior group.
The next thing to consider is how you want to define the organization of these units. Ultimately what you want to achieve is , say, a number of stacks; some bombard stacks with, for instance, a couple of attackers, and ranged units, and 5 bombard units (this stack would soften up targets for the assault) and some general purpose stacks with 4 strong and resilient attackers and 5 ranged attackers, to attack or perform defense within the empire, and some appropriate defensive stacks for cities. Sea stacks, air stacks and wanderer escort stacks would be yet another case.
You could define the proportions that you would like to see for each AI behavior pattern (aggressive, defensive etc.) and those would be scaled up or down as resources permitted into ‘build plans’ which the AI could carry out, still taking into effect ‘social’ building.
You might set up a text file that was parsed, with ‘descriptions’ of stacks… with incremental sizes and priorities… I.E.
Stack Defensive_Cities 255(all cities… not literatally 255) 10000 (priority)
{
Defensive_Land 1
Ranged_Land 1
}
Stack Offensive_Land_Stack 1 (a single stack to attack is the second priority) 5000 (priority)
{
Offensive_Land 1
Ranged_Land 1
}
Stack Defensive_Cities 255 1000 (third priority is a larger defensive force)
{
Defensive_Land 2
Ranged_Land 2
}
Stack Offensive_Land_Stack 1 (still single stack) 500
{
Offensive_Land 2
Ranged_Land 3
Slaver_Special 1
}
Stack Bombard_Land_Stack 1 450
{
Offensive_Land 2
Bombard_Land 2
}
AND SO ON, AND SO FORTH…
When a priority is met, you can move down the list
Lastly, stacks need to be treated as homogeneous entities in their own right, by the AI; they need to be regrouped after being split up to move past a city or across an ocean in small boats, and re-supplied with reinforcements after being damaged in battle. As new cities are added… perhaps parts of the attacking stack should be split off to constitute a new garrison.
While I do understand some of the underlying principals of AI design, I guess what I know in a total way is very minimal indeed. I have nothing but respect for a good AI, and its programmer, for this reason.
As far as I tell, the CtP1 AI was a form of list processing. The AIP and FLI files were the parsed files that were conditionally processed, producing weighted answers as to what should happen. The results were
‘hints’ to the games AI dll, as to what should be done.
There are two main challenges that the new AI has to meet.
First is its obligation to pose as an effective threat to the player, by doing three things militarily; first building good stacks, second put those stacks on transport, or many transports (and reconstitute the stack at the other end) and lastly attack with those stacks. The only way that the AI was TRULY effective (at least overseas) was as a nuisance, by employing special unit attacks. The reason for this, is that one special unit can be effective. However, grouping was never a thing it did very well at.
Secondly, newly created units (created by scenario designers) might have a very tough time, since they, unless some thought is put into AI behavior, will be unused by the computer. This ultimately means that certain scenario units could be unnecessarily unbalancing. The way to solve this, of course, is to have enough groupings of behavior where the new units could fit in. Behavior can generally be defined as movement and attack, since you can ‘preempt’ combat and do something ‘clever’ in SLIC or do something during or after movement.
There was the concept of grouping units by type and them having behaviors, in CtP1.
The problem is… that there were not enough groupings for customizing, and the way the units were described was by static tokens… yes?
The archetypal new custom unit in CtP1, which was employable by the user, but not the AI was the cruise missile. It was one shot, offensive… preferably against towns… or carriers, so it should be grouped for best effect, unlike a nuke. Perhaps carried by subs or ships…(not carriers), and not travelling on its own, except to get into position.
The defensive version of this, which I would like to have seen, though for technical reasons (lack of size classes,) it was impossible, is the Anti Aircraft Missile. A one-shot ship or land-carried unit, that would be used in response to threats within its range radius. Of course, certain people might say… this is too specific. Civ is all about abstraction. However, scenario designers should be given freedom to express their ideas in a flexible product. That is ultimately what the culmination of “Civ” should be.
These are two examples, but I can imagine another… a non-attacking, non-settling unit; one that either explores new sea or land territory, or wanders already discovered land or sea, in settled or unsettled regions. With SLIC, these movement patterns could be put to use, in ways that we don’t know now, but I’m certain will have great use later.
The extra or replacement AI unit classes that I am suggesting are:
SINGLE_SHOT_LAND_OFF
SINGLE_SHOT_SEA_OFF
SINGLE_SHOT_AIR_OFF
SINGLE_SHOT_TERROR (nuke)
SINGLE_SHOT_LAND_DEF
SINGLE_SHOT_SEA_DEF
SINGLE_SHOT_AIR_DEF
POWER_PROJECTION_SEA (the carrier, and sub?)
POWER_PROJECTION_AIR (nuclear strike aircraft)
POWER_PROJECTION_LAND (for completeness?)
WANDERER_LAND_EXPLORED_SETTLED
WANDERER_LAND_EXPLORED_UNSETTLED
WANDERER_SEA_EXPLORED_SETTLED
WANDERER_SEA_EXPLORED_UNSETTLED
WANDERER_AIR_EXPLORED_SETTLED
WANDERER_AIR_EXPLORED_UNSETTLED
WANDERER_LAND_UNEXPLORED
WANDERER_SEA_UNEXPLORED
WANDERER_AIR_UNEXPLORED
The problem of the static tokens in the AI file has to be remedied by moving their specification to where the units are defined; units.txt. I understand this is yet another line and flag to be added, and parsed. You could do vertical partitioning of the data, and split the property into another file… something like unitAIdef.txt or whatever. However, its important that if you want to have a customizable game, that you allow specification of a unit as within an AI behavior group.
The next thing to consider is how you want to define the organization of these units. Ultimately what you want to achieve is , say, a number of stacks; some bombard stacks with, for instance, a couple of attackers, and ranged units, and 5 bombard units (this stack would soften up targets for the assault) and some general purpose stacks with 4 strong and resilient attackers and 5 ranged attackers, to attack or perform defense within the empire, and some appropriate defensive stacks for cities. Sea stacks, air stacks and wanderer escort stacks would be yet another case.
You could define the proportions that you would like to see for each AI behavior pattern (aggressive, defensive etc.) and those would be scaled up or down as resources permitted into ‘build plans’ which the AI could carry out, still taking into effect ‘social’ building.
You might set up a text file that was parsed, with ‘descriptions’ of stacks… with incremental sizes and priorities… I.E.
Stack Defensive_Cities 255(all cities… not literatally 255) 10000 (priority)
{
Defensive_Land 1
Ranged_Land 1
}
Stack Offensive_Land_Stack 1 (a single stack to attack is the second priority) 5000 (priority)
{
Offensive_Land 1
Ranged_Land 1
}
Stack Defensive_Cities 255 1000 (third priority is a larger defensive force)
{
Defensive_Land 2
Ranged_Land 2
}
Stack Offensive_Land_Stack 1 (still single stack) 500
{
Offensive_Land 2
Ranged_Land 3
Slaver_Special 1
}
Stack Bombard_Land_Stack 1 450
{
Offensive_Land 2
Bombard_Land 2
}
AND SO ON, AND SO FORTH…
When a priority is met, you can move down the list
Lastly, stacks need to be treated as homogeneous entities in their own right, by the AI; they need to be regrouped after being split up to move past a city or across an ocean in small boats, and re-supplied with reinforcements after being damaged in battle. As new cities are added… perhaps parts of the attacking stack should be split off to constitute a new garrison.
Comment