Combat Mission games effectively use different types of ‘AI’. It’s worth bearing this in mind when discussing the ‘AI’ in the Combat Mission game engine.

First there is the TACTICAL AI – the easiest way to think of this is as your wee pixel guys (crews and infantry) behave in combat. It’s the combination of many factors such as instinct for self preservation, aggressiveness, skill etc. Basically this is what makes them intrinsically decide to ‘fight or flight’. The TACTICAL AI also manages how the infantry and vehicles move i.e. pathfinding, unit spacing, and so forth.

Next there is the “STRATEGIC AI” (my own term). This is how the AI decides to fight the scenario i.e. how it chooses it’s plan of attack, how fast it attacks, what sort of defensive arrangement tec. This STRATEGIC AI operates according to a PLAN. This PLAN is designed by the scenario designer. Simply put, this involves the scenario designer assigning each unit an AI GROUP within an AI PLAN (There are five AI PLAN slots within which there are eight AI GROUPS). This means that in any given scenario the designer could have the AI attack/defend in five different ways – each of which could be very different or slight variations on a theme. These AI PLANS are created in the scenario editor and simply involved painting a bread crumb trail on the map (points the AI will move to) and associating a ‘behaviour’ with these points, for example; assault, advance, dash, and so forth; and giving each specific “behavior” a time frame for performing. This time frame is measured using the in-game clock.

QUICK BATTLE purchases are a different beast and are not the AI as such. These instructions do not deal with how the QB thingy works – they are specific to scenario design and that sort of thing.

(In CMX1 (CMBB, CMBO, CMAK) the STRATEGIC AI was basically tied to where the designer had placed the FLAGs. If an AI controlled FLAG was lost it attacked. Simples J The TACTICAL AI was also a lot more basic.)

In Combat Mission x2, how well or how poorly the AI attacks is in a large part down to how good the designer is at creating AI plans. How the little guys perform in action at the tactical level is managed to a large extent the game engine and how the player (human or AI) handles the troops.

At the beginning of a scenario design, there are no triggers. If the Human is attacking to take an objective, the AI will not necessarily counter-attack on its own. The scenario designer has to create trigger events associated with that objective and then script an AI PLAN to mount any counter attack.

AI Planning:

When creating orders the behavior in an order group refers to the PREVIOUS order.

"Exit Between" times affect the next order. They tell the AI what time period to enact an order. The first time tells the AI to NEVER start the Order until that time. The second time tells the AI to NEVER start the Order later than that time. The time period between the first and second settings is the phase where the AI attempts to carry out the planned order. The behavior affecting this order is allocated in the next order.

So simply put (!) when creating an order you are telling the AI the behavior to adopt for the preceding order and telling it when to carry out the next order.

Set-up: 00:00 – 00:01

Order 2 behaviour here refers to order when moving out from set-up. Timing phase refers to the next order. So if the behaviour is ‘ADVANCE’ for Order 2 the AI will immediately at set- up move out using the ‘ADVANCE’ command.

Timing shown in this order i.e. order 2 now refers to the NEXT order i.e. Order 3, so 00:04 – 00:06 means that the unit will sit at this painted spot till the clock reaches four minutes then it will move out (using the behavior as indicated under ORDER 3).

Order 3 DASH – the AI after sitting at its current location for four minutes will DASH to the painted objective and attempt to reach that before the clock strikes 00:06. The timing under Order 3 now refers to the time phase before it starts on Order 4.

AI Triggers Overview

Sometimes you'll want an AI Group to act based on battlefield conditions rather than set times. This is achieved with the use of Triggers. You can tell an AI Group to "Wait For" another AI Group to execute an Order or to "Wait for" a unit (enemy or friendly) to touch a Trigger Objective. The same basic principles apply to both Order and Objective type Triggers, however you'll probably find some situations where one type works better than the other.

What Triggers cannot do is provide alternate commands. AI Orders are still followed one-after-another without branching. Triggers simply allow you to control when the next Order executes based on the Trigger parameters you choose.

Setting up a Trigger

Triggers are always set up first and then linked to specific Orders. A Trigger can be used by as many Orders in as many Friendly AI Groups as you want, but an Order can only be assigned to use one Trigger. Setup can never be used as a Trigger and the last Order of an AI Group can never be triggered.

For an Objective Trigger you must first designate a Terrain Objective on the map, and then choose what sort of unit can trip it. You can choose between friendly or enemy and either any type of unit or only armored ones.

For an Orders Trigger you must identify a specific Order (Setup is not an Order) in a friendly AI Group and change the popup just below the Order Number to "Can Trigger" from "Not Trigger".

Now that you have a Trigger specified you need to instruct one or more AI Groups to use it. Find the Order you want to wait for a Trigger and click on the "Wait For..." button at the bottom of the Orders panel. When you do this a dialog appears with a popup menu that shows all the Triggers you have made. Select one and it becomes the active Trigger for that Order.

Exit Between Times

The first thing to understand is how the "Exit Between" times affect tripping. The first time tells the AI to NEVER start the Order until that time even if the Trigger is tripped. The second time tells the AI to NEVER start the Order later than that time even if the Trigger is not tripped. The time period between the first and second settings is when the Order is paused waiting for the Trigger to be tripped.

If you want an AI Group to always wait for a Trigger to be tripped leave the first timer to 00:00 and set the second timer to something greater than the scenario's maximum game time. If you want an AI Group to give up on a Trigger if it isn't tripped by a particular time (a failsafe) then leave the first timer to 00:00 and set the second timer to the time you have in mind. Sometimes you will want an AI Group to wait until a specific time even if the Trigger is tripped, in which case you set the first timer to that time. If the Trigger is tripped before then the AI Group will start executing its Order only when the first timer's time is reached. If it hasn't been tripped by then the AI Group will remain idle until either the Trigger is tripped or the second timer's time is reached (whichever happens first).

The Tricky Part

While setting up Triggers is fairly straight forward, getting them to do what you expect is not necessarily as easily done. The more complex your Plan is, the more interdependent AI Groups are to each other, the more challenging it is to get the results you want. This section tries to get you started on the right path.

The most important, and definitely most difficult, concept to understand is which Order to select as the Trigger. The natural inclination is think of Triggers being tripped when an Order is complete (i.e. the units arrive in the painted area). This is not how it works. Instead a Trigger is tripped when the designated Order starts, not when it ends. This means if you want to key off of units arriving in the painted area of Order 5 you must select Order 6 as the Trigger, not Order 5. While this may be counter intuitive to us Humans, to the computer it's solidly logical and there are very good reasons for it.

The second most common source of error is having two or more AI Groups use Triggers to "leap frog" each other. This can definitely work, however designer error and/or unforeseen game events can cause a huge chain reaction that stops your AI from functioning. For example, you could find Group 2 waiting for Group 3 which is waiting for Group 4 which is unexpectedly waiting for Group 2. This error is commonly called "circular logic". Careful use of the Exit Between timers can limit the damage, but keeping things simple is an even better way to go.

Combining Objective and Orders Triggers can produce some sophisticated behavior if done right. For example, AI Group 2 Order 4 waits until Objective Blue is tripped by enemy armor, at which point it starts a wide flanking action using three additional Orders. Order 6 places the units in a key spot which signals that AI Group 3 should begin its own movement. In which case AI Group 3 would be set to trigger off Order 7 so that it starts its attack when AI Group 2 is at the key spot.

TIP! In the event that you want the last action of an AI Group to be a Trigger (which it cannot be by default) you can fake out the system. Create your last Order to do whatever action it is you want done, then create a new last Order with the parameters to be the same as the previous one and no painted objective zone. Then go back and assign a Trigger to the previous Order. This allows the last meaningful action of that AI Group to act as a Trigger even though technically it's not its last set of instructions. That's because the actual last Order is nothing but a repeat of the previous instructions.