Question about CO2 scenarios and AI/CPU opponent?

[Bullman]

Hello,

If you consider all the scenarios available for CO2 (the battle packs and what is at the community created ones at the Steam Workshop), I would like to know what (if any) scenario specific "AI scripting" may have been coded by the scenario designers themselves for each scenario created. Or is it the case that the CO2 engine itself has all the "smarts" needed for the game to interpret any given scenario (map, unit, objectives etc) to "automatically" generate and direct the CPU opponent a player faces when playing CO2 single player (any side)?

I want to understand what is "driving" any/all of the higher level CPU opponent moves of ANY CO2 scenario and HOW that is achieved by the game (I understand that the game engine automatically creates all the "sub-orders" once a higher level order is given.)

What part (if any) does the scenario designer have in influencing, for example, the high level planning of the CPU opponent in any given scenario?

Bull

 

[jimcarravallah]

Hello,

If you consider all the scenarios available for CO2 (the battle packs and what is at the community created ones at the Steam Workshop), I would like to know what (if any) scenario specific "AI scripting" may have been coded by the scenario designers themselves for each scenario created. Or is it the case that the CO2 engine itself has all the "smarts" needed for the game to interpret any given scenario (map, unit, objectives etc) to "automatically" generate and direct the CPU opponent a player faces when playing CO2 single player (any side)?

I want to understand what is "driving" any/all of the higher level CPU opponent moves of ANY CO2 scenario and HOW that is achieved by the game (I understand that the game engine automatically creates all the "sub-orders" once a higher level order is given.)

What part (if any) does the scenario designer have in influencing, for example, the high level planning of the CPU opponent in any given scenario?

Bull

The AI opponent is largely controlled by the definition of objectives for the AI side. Objectives which return victory points for holding them receive the most attention from the AI. The AI behavior is moderated by setting the value for the objective, the time during the game that the value is calculated, and an evaluation of enemy (in this case human opponent) attention to the objective versus available (AI) resources.

Objective parameters are explained in detail on Pages 153 to 157 of the game manual. Those parameters apply to AI decisions as well.

The developer also can control AI behavior by creating 0-value objectives which attract AI resources when applicable. For example, assigning a 0-value objective to a critical river crossing would encourage the AI to pay some attention to holding and defending that crossing during the game. Assigning victory points would more closely assure the crossing was held and defended.

In addition, there are unit attributes built into the unit design in the Estab in terms of unit or commander training, cohesiveness, fatigue, leadership, aggressiveness and the like. Some of these attributes of unit health when set at start are designed to make the AI opponent more or less efficient in exercising the combat strength at the onset of the game but can change during the game if the unit is allowed to rest/defend for a period of time. Others such as training and combat experience status are relative, setting a floor or ceiling of performance that a unit cannot surpass during the game.

Finally, attributes such as supply status, weather, and reinforcement schedule can be used to modify AI activities.

There has been some talk of including dedicated AI scripting, but at the moment, there are no scenarios where this has been used.

 

[Bullman]

Thanks for the reply. It seems like quite a coding achievement for CO2 to have what I would call an "adaptive AI".

So I wouldn't be wrong in saying that once a map, objective(s) (including any 0-value ones as you describe) and OOB has been assigned by a scenario designer, the way in which the CPU opponent behaves/reacts etc is kind of mainly determined by the CO2 game engine itself once the scenario is loaded? How it interprets all these inputs, making plans/orders on "on the fly" is much in the same way a player would do once they review the map, objectives and OOB themselves (as in, they evaluate what has been presented and issues orders accordingly, by "working it all out themselves", rather than follow any script)?

Given the apparent "lassez faire" way the CPU opponent is left to operate once you start playing a scenario, it certainly raises the question of just how "adaptive" the CO2 engine is at simulating a credible CPU opponent given the vast variety of maps/OOB/scenarios are possible.

 

[jimcarravallah]

Thanks for the reply. It seems like quite a coding achievement for CO2 to have what I would call an "adaptive AI".

So I wouldn't be wrong in saying that once a map, objective(s) (including any 0-value ones as you describe) and OOB has been assigned by a scenario designer, the way in which the CPU opponent behaves/reacts etc is kind of mainly determined by the CO2 game engine itself once the scenario is loaded? How it interprets all these inputs, making plans/orders on "on the fly" is much in the same way a player would do once they review the map, objectives and OOB themselves (as in, they evaluate what has been presented and issues orders accordingly, by "working it all out themselves", rather than follow any script)?

Given the apparent "lasse faire" way the CPU opponent is left to operate once you start playing a scenario, it certainly raises the question of just how "adaptive" the CO2 engine is at simulating a credible CPU opponent given the vast variety

There been some observed deficiencies in the AI performance such as choices for routing, organizing forces for movement and attack, or holding high quality at start defensive positions during the term of the game. The developers have been addressing these as they surface, resulting in more efficient combat decisions making the AI performance after updates better than what was experienced when the game was first delivered.

That said, the management of AI is an evolving process, so when every observed deficiency is addressed it appears new ones surface.

Best judge of the AI is whether it provides a decent opponent in combat, and based on users who report defeat against the AI or a disappoiinting outcome from a session, I'd say it's pretty good.

 

[Bullman]

FWIW, I am very averse to using the term AI to describe whatever code it is that runs the "computer opponent" a player faces when playing a computer wargame single player. The word "intelligence" just assumes so much about what it is you are describing. I think it is better to refer to it as a "CPU opponent", which implies nothing about how "intelligent" that digital opponent ends up being. If I ever use the term AI to describe a CPU opponent I am doing it only because it may be a more familiar way to describe what it is I am referring to.

It's easy to anthromorphise what we see a CPU opponent do in any computer wargame, essentially ascribing human like rationale and reasoning to explain how/why the CPU opponent acts, reacts and behaves. We want to assume we are playing against an "intelligent" virtual opponent that thinks and plans and reacts like a real human opponent would but in many cases what the player sees is far from that. Replicating in code all the things humans do/consider/evaluate etc when playing complex games (like many wargames are) is no mean feat, and one I think many people underestimate. Most game developers, generally great at graphics/UI/content/concepts etc are far from being invested AI coding specialists which explains why the CPU opponent in many computer wargames is very bad. Designing a computer wargame for head-to-head MP gameplay is way easier then going the next step and coming up with computer code for a CPU opponent that "understands the rule and how to play the game and win". Games such as NaWD is a classic example of a computer wargame that is a derivative of a boardgame that was always meant to be played and understood by two humans. Playing NaWD H2H is fine. However, it is blatantly evident that the developers didn't know what they were up for and were clearly out of their depth when they attempted to code even a "respectable' CPU opponent for that game to be played single player.

From my experience with CO2, I think the SP CPU opponent is surprisingly good, and that really is surprising given that it does seem to be an "adaptive" AI, with no real help from the scenario designers. It's obvious a fair bit of development was invested in this area which is great to see.

I would tend to think that many of the CO2 Battle Pack scenarios have been thoroughly tested and tweaked, but I am interested to know how some of the user-made scenarios available from the Steam Workshop play out in single player (either side). I doubt the scenario designers there had the time/resources to undergo adequate testing. All they did was essentially consider typically otherwise compelling historical battles, make custom maps, custom OOBs, assign units their starting positions and reinforcements etc. to suit, and expect the CPU opponent to "come to the party" and take control of one side once the scenario is loaded and hope it plays out as something credible. Is there something to say about how those scenarios play out in single player? eg. I've been looking at the massive Caen map and battle and wondering how the CPU opponent will go commanding all those units and considering all those objectives.

 

[jimcarravallah]

FWIW, I am very averse to using the term AI to describe whatever code it is that runs the "computer opponent" a player faces when playing a computer wargame single player. The word "intelligence" just assumes so much about what it is you are describing. I think it is better to refer to it as a "CPU opponent", which implies nothing about how "intelligent" that opponent will be. If I ever use the term AI to describe a CPU opponent I am doing it only because it may be a more familiar way to describe what it is I am referring to.

It's easy to anthromorphise what we see a CPU opponent do in any computer wargame, essentially ascribing human like rationale and reasoning to explain how the CPU opponent acts, reacts and behaves. We want to assume we are playing against an "intelligent" opponent that thinks and plans and reacts like a real human opponent would but in many cases what the player sees is far from that. Most game developers, generally great at graphics/UI/content/concepts etc are far from being invested AI coding specialists which explains why the CPU opponent in many computer wargames is very bad. Designing a computer wargame for head-to-head MP gameplay is way easier then going the next step and coming up with computer code for a CPU opponent that "understands the rule and how to play the game and win". Games such as NaWD is a classic example of a computer wargame that is a derivative of a boardgame that was always meant to be played and understood by two humans. Playing NaWD H2H is fine. However, it is blatantly evident that the developers didn't know what they were up for and were clearly out of their depth when they attempted to code even a "respectable' CPU opponent for that game to be played single player.

From my experience with CO2, I think the SP CPU opponent is surprisingly good, and that really is surprising given that it does seem to be an "adaptive" AI, with no real help from the scenario designers. It's obvious a fair bit of development was invested in this area which is great to see.

There is an focus on historical doctrine in the assembly of the components for opposing forces in CO2.

All state level military planning begins with a doctrine used to define what resources would be assembled and how those resources would be used in combat situations. CO2 has done a good job in replicating that doctrine for ground forces and shapes the scenarios by extensive research into the then current status of the opposing forces when they came into contact -- supply situation, troop health, unit morale and quality, leadership quality and task group organization.

The SP CPU opponent's actions are shaped by that doctrine using a mathematical evaluation of the options available to arrive at the most likely, if not the optimum, action for the situation the SP CPU opponent faces.

Victory is balanced against historical conditions allowing for the human player to start work with the same situation the real life commander faced at the time and play the game to see if the human player could improve on the method the historical commander used the forces at hand.

What's unclear is whether the fog of war a human player experiences affects the SP CPU opponent. The on map opposing force situation for the enemy forces is shaped by what the human force was capable of observing rather than a duplicate of what existed. How that FOW is translated for the AI decision tree isn't apparent in playing the game.

I would tend to think that many of the CO2 Battle Pack scenarios have been thoroughly tested and tweaked, but I am interested to know how some of the user-made scenarios available from the Steam Workshop play out in single player (either side). I doubt the scenario designers there had the time/resources to undergo adequate testing. All they did was essentially consider typically otherwise compelling historical battles, make custom maps, custom OOBs, assign units their starting positions and reinforcements etc. to suit, and expect the CPU opponent to "come to the party" and take control of one side once the scenario is loaded and hope it plays out as something credible. Is there something to say about how those scenarios play out in single player? eg. I've been looking at the massive Caen map and battle and wondering how the CPU opponent will go commanding all those units and considering all those objectives.

There has been some discussion on defining quality of a scenario.

Some developers focus on obtaining a historical outcome from playing the scenario.

I think the focus should be on whether the historical outcome was possible given the construct of the scenario. If the historical outcome is the only possible solution, it makes for a pretty boring test of combat skills the second or third time a player explores it. If it's one of the many possible outcomes, then the player can evaluate his / her combat skills against the real life commander's skills at the end of the game.

 

[GoodGuy]

.... I doubt the scenario designers there had the time/resources to undergo adequate testing. All they did was essentially consider typically otherwise compelling historical battles, make custom maps, custom OOBs, assign units their starting positions and reinforcements etc. to suit, and expect the CPU opponent to "come to the party" and take control of one side once the scenario is loaded and hope it plays out as something credible. Is there something to say about how those scenarios play out in single player? eg. I've been looking at the massive Caen map and battle and wondering how the CPU opponent will go commanding all those units and considering all those objectives."

That's a misconception, there. Quite a few community designers were eager to iron out quirks in their scenarios and even offered revised versions, after they received feedback or when they found some quirks. Some tested their scenarios without any additional help, which means that the design and testing process of a large map/scenario could take weeks or even months, depending on how much spare time was available. On top of that, you need to add the time needed to reasearch a given battle (course of combat), obtain detailed maps (see the scenarios forum to get an idea about what level of effort is needed to create a decent map) and research the historical force composition, if the setting is supposed to be historical.
Some community designers ask(ed) their friends or members of this forum (or the old HTTR/COTA forums) for input or even to help testing.
The community designers then use(d ) the feedback to relocate/correct objective rings, adjust objective priorities or edit victory conditions.
Especially with some historical scenarios, a number of scenario designers didn't just "hope (that) it plays out as something credible", they actually ensured (with proper playtesting/scenario tweaking) that their scenarios were able to deliver the historical outcomes.

I playtested a number of community scenarios, and the designer(s) usually worked hard to get the AI as challenging/realistic as possible, they often adjusted their scenarios multiple times, to influence/direct the AI opponent's general directions and force allocations, until the AI opponent's behavior looked right or until the historical outcome could be achieved, for instance.
I created a large fictional scenario (40 km) for HTTR, covering the (historical) defense of Cologne with additional para drops on the right river bank - Operation Varsity style, but the actual design of the scenario and several rounds of tweaking - after playtesting - took more time than the creation of the map. After a series of changes, both sides were playable, eventually, and both sides could pull a win.

Some scenario designs were/are optimized for the "winner force", means that this force was supposed to be played by the human player. Other designers even rather focused on the "loser side", means they put the player in a situation, where he had to prevent/alter the historical outcome, basically. Not every scenario was/is suited to be played on both sides, this goes for some community scenarios, and for one or another scenario in the original HTTR game, which would then contain hints like "designed to be played as Allies" in the scenario briefing, for instance. In such scenarios, the designer could not (or didn't want to) get the objectives/victory conditions (for the Allies, in this example) to a level, where the AI would properly move to/cover all required objectives, if the AI was put on the side that was meant to be played by the human player.
In quite a few cases, even community scenarios were playtested on both sides, though, some even extensively, either "just" by their designers or with the help of additional helping hands.

 

[Arkadiy]

This is from a very limited experience (pretty much replaying St Vith time and time again), so may not be always true. But it appears to me that the enemy does not care enough to protect Bases/high level HQ's/Artillery. It is content with leaving them on map's edge and proceeding to attack and guard objectives.
Is that just my being unlucky, insufficient exposure (i.e. the scenario itself isn't best in representing enemy's capability) or is there nothing in the game's mechanics that makes the enemy take own HQ/Bases into account when making plans?

Edit (20211122): never mind, in this case it's definitely the scenarios. I just played as Wehrmacht...

 

[Tommy.w]

Slightly related to this topic - I just tried to use ChatGPT to see if it could list some ORBATs.
For example I tried to use it to tell me which units were involved in the battle for Manhay Crossing.
It lists some of the key units - but certainly not in the detail the scenario has.

Once ChatGPT has access to more historical data sets it might be a useful asset for scenario designers..

 

[Dave 'Arjuna' O'Connor]

Bullman,

We don't use scenario specific scripting. The AI is generic and works the same in all scenarios. As Jim has highlighted above, the scenario designer can influence where and by how much the AI prioritises certain objectives. He/she can prescribe a certain orbat for each side. But in doing so there is good flexibility to change the force mix from one replay to the next by way of the reinforcement schedules. For instance, you can have historical, standard, favour allies or favour axis schedules that the player can choose and within each of these categories the designer can setup multiple schedules of which the AI will randomly choose one at game start. The designer doesn't have to do this, but the capability is there.