The Sheriff of Oosterbeek – A Scenario Design DAR/AAR

[agusto]

EDIT: deleted by user

[kohlenklau]

Hey Jon,

In part 13 you seem to have skipped over discussing the 170 by 170 picture (your views, etc.) Are you tucking that in with briefings?

I'm interested in hearing what you think should be in the picture and indeed if a small bit of tasteful nudity could be useful in getting the player to try the scenario.

[JonS]

haha - well spotted

Yep.

[pnzrldr]

You are revealing your nationality, with "knock-on effects." No one who doesn't play rugby has any idea what that means. ;-) My old man is visiting Wellington later this month. I told him if he doesn't bring back a Hurricanes jersey and an All Blacks jersey, he might as well not come back. He just mumbled back something about 30lb rainbow trout and hobbits.

[JonS]

15 - Briefings and Imagery

”[T]here are known knowns; there are things we know that we know.
There are known unknowns; that is to say there are things that we now know we don't know.
But there are also unknown unknowns – there are things we do not know we don't know.”
Donald Rumsfeld

Scenario briefing and imagery are the opportunity to communicate directly with the player, and to let them know what they’re trying to achieve in your scenario, and why they should care. It is the place where all the various pieces of story telling – on the map, with the units, via the objectives, and so on – should come together as a cohesive and coherent whole. It is worth the effort to make all the strands of the story plain so that the player is presented with a clear and uncomplicated story, which sets them up to fight your battle in a good state of mind.

The opening image is the one displayed when selecting a battle from the scenario list, and I find that it – like the scenario title – can be a tricky little beast. I want something that is interesting, and relevant to the scenario, yet which doesn’t inadvertently leak information that should be subject to FOW. For instance, imagine an opening image that includes a picture of a Tiger. Well, the Allied player now knows that the German player has a Tiger, and the German player knows that the Allied player knows, which blows a potentially significant surprise for both sides. Therefore I usually stick to something generic but still interesting and relevant. In a scenario between the US and Germans, for example, it wouldn’t be relevant to have an image of British infantry.

There’s pretty much no end to the types of images that could be used here, including photos, maps, icons, historic cartoons, propaganda posters, paintings, and in-game screen shots. Just try and make it relevant, and not leak too much FOW. For this scenario I’ve used a dramatic painting of Horsa gliders landing and British air borne troops coming out fighting. It really has nothing to do with the scenario, which isn’t set on the landing zones, except that it involves UK airborne forces, and in particular some glider-borne forces. (see image 13.1)

Artful cropping can be used to get an image that meets the maximum 170x170 pixel size, yet still has enough detail to see what’s being shown. The image needs to be saved as a .bmp file, and can be placed anywhere. For convenience I put them in a ‘Briefing Imagery’ folder nested in my ‘Scenarios’ folder.

The Strategic, Operational, and Tactical images are specific to each side, so they should be used for story telling to transmit information specific to each player. My graphic design and photoshop skills are terrible, so I’ve made friends with some artists, and have them create these for me, based on the information I provide. Over the last couple of releases, Normal Dude has developed a very elegant and consistent format for these images, which I tend to default to.
 

 

15.1: screenshot showing the three briefing images that the British Player of ‘The Sheriff of Oosterbeek will see. Strategic top left, Operational top right, and Tactical below. Note the amount of information available to players through these images.

The Strategic map (224x224 pixels) contextualises the scenario in space, giving a quick indication of roughly where the battle is taking place.

The operational map (702x224 pixels) gives a rough indication of the size of the map, along with indicating what main units are involved, and which sides of the map are friendly. Off to the side is a table showing the objectives for that side.

The tactical map is an unusual size (952x350 pixels), being much wider than it is high. This can make it awkward to find a scaling that displays anything pleasingly without a lot of black space on either side. The style developed by Normal Dude overcomes all this with a stylised representation of the CM map which shows major features, highlights objective locations, and indicates the rough location and type of friendly and enemy units. In another table off to the left side makes use of what would otherwise be blank space with a listing of off-map artillery support and reinforcement’s arrival times.

What I like about Normal Dude’s style of briefing images is that they’re consistent with each other, no space is wasted, and they elegantly convey a lot of information to the player.

Like the scenario opening image, these have to be saved as .bmps, and I keep them in the same ‘Briefing Imagery’ folder. It’s a decent idea to name them in such a way that it’s obvious which scenario they belong to, and also which side and which image slot they’re destined for.

You can also think outside the box with these images – there is no reason that they must be maps, and they don’t have to follow the strategic-operational-tactical flow. You could use aerial recon photos, letters, orders, or really anything to convey useful information to the player.
 

 

15.2: screenshot showing an early draft first page of the briefing which British Player will see.

The side specific briefings allow you to get deeply into telling the story, quickly and economically. In Real Life the player-as-commander(s) would have a ton of contextual information that would guide him in the forthcoming battle. The briefing is the means by which all that contextual information is presented so that the player has a good understanding of the situation, why he’s fighting, and what he’s likely to encounter.

In general the briefings – and in this I include the briefing imagery – must serve one important function: it must allow the player to develop a reasonable plan to achieve their objectives and win the fight. This requires a lot of story telling, as well as the judicious application of fog of war.

In order to develop a plan the player needs to answer several questions: –
1) what must I do? (objectives)
2) what forces do I have? (on map, off map, and reinforcements)
3) where must I do it? (terrain, weather, and environment)
4) how long do I have? (scenario length)
5) what is the enemy trying to do? (what are the enemy objectives)
6) what forces does the enemy have? (on map, off map, and reinforcements)

Not all of this needs to be explicitly or lengthily covered in the briefing. The player’s on-map forces only need to be given in outline, since they can be studied intimately on the map, although off-map artillery and any reinforcements are worth detailing. The map can also be closely examined by the player, so there’s no need to go into that too much. It is, however, worth highlighting any particular map settings, such as how soft the ground is, what the weather and especially the wind is doing, since that affects how easily vehicles will bog or smoke will form, and also note when sunrise or sunset will occur if that is due to happen during the scenario. Scenario length is another item the player can discover for themselves, but still worth noting. Related to duration is an indication of time and space issues – if the attacker has a long way to go, but only a short time to get there, it might be worth mentioning how long it will take to move between key locations when using the Move command.

Explaining the objectives to be achieved in order to succeed is relatively straightforward, and can be done via the briefing graphics and by explicitly noting the value of terrain objectives on the 3D map. At one time I thought it was a good idea to be coy about exactly what a player had to do to win, and used vague wording to try and imply a sense of relative importance between difference objectives. I’ve changed my mind about that. Tell the players exactly what each objective is, and what it’s worth, down to the point. It’s easier and clearer that way, and allows players to develop better plans.

Providing information on the enemy is crucial, but it must be tempered to try and retain FOW and surprises. In general, I think it’s a bad idea to outright lie to players, but that it’s okay to be vague or to omit some information, although the broad outlines should be correct. Particularly important here is the approximate size and composition of the enemy force – is it a company, or a battalion? Is it drawn from an armoured division (in which case there’ll probably be tracked fighting vehicles of some sort), or an infantry division (in which case there probably won’t be). Has the enemy been using artillery in this area, and if so what sort, how much?

Also important are the enemy’s intentions. There is no need to provide a detailed list of all the enemy’s objectives, with their locations and point values. But do include the main idea of what the enemy is trying to achieve – seize or hold a nominated hill or town, inflict casualties, exit in a particular direction, and so on.

Knowing what the enemy has and is trying to do, even roughly, allows the player to develop a meaningful plan, and will help build engagement with your scenario. Their plan doesn’t have to be perfect – players should expect that they will have to adjust in response to developments during the battle. But modifying an existing plan is quite different to scrapping it and starting over because the initial information was so bad.

There’s a lot to convey, but keep the briefing short and pithy - I aim for no more than two pages of the on-screen display. Any more than that and you’re writing a novel that wastes player’s time and attention. Remember that in addition to words there are the three briefing images to help tell the story, as well as what the player can discover for themselves in the 3D environment – it isn’t necessary to explicitly tell them everything.

So that’s the content of the briefings and some considerations to think about. What about the format? CM uses a semi-fixed briefing format, containing the following headings:
* Situation
* Mission
* Friendly Forces
* Enemy Forces
* Plan
* Notes

This a reasonable approximation of the standard NATO 5-paragraph orders format that a lot of players will have at least some familiarity with, even if they don't have any direct military experience.

Try not to repeat information in the various section headings, and also keep the briefing pitched at the appropriate level – if the scenario is about a company group, keep the chatter focussed on that company group and the battle it is about to fight, not the brigade or division to which it belongs, or the overarching campaign.

Although I don't believe it has ever been formalised anywhere - and I don't think it should be formalised – this is how I use these headings:

* Situation
This should tell the back story. How did the player get to be fighting this battle, here, now. In a general sense it should explain what's going on at a higher level and to the flanks. What is the command echelon above you, and the one above that, up to? What are your flanking formations doing. A lot of this is pure story telling, but it does impact planning. If, for example, you say that the flanking formations are lagging behind you, it is reasonable to suppose that the enemy might get reinforcements coming in from the map edges. If this is nominated as the main effort, it’s reasonable to suppose that you’ll get decent artillery support, and also that the enemy will notice something big is going on here and respond accordingly. For that reason it is important to think through the back story and come up with something coherent and consistent with the actual battle.

* Mission
This is a single sentence using the [WHO] is to [do WHAT] [WHERE] by [WHEN] in order to [WHY] format. For example:

 

"[b Company] is to [secure] [the crossroads] no later than [1400 hrs] in order for [the remainder of 1 Bn to advance on Aachen]."

The mission should be clear, correct - don't tell the players to secure a hill when actually taking a church on the other side of the map is more important in terms of points - and achievable. You don’t need to break it down into a series of nested objectives either – what is the main thing, the main idea, that the player should be working towards?

* Friendly Forces
Explain in outline what the player has, including fire support and reinforcements, and identify any key strengths or weaknesses (i.e., poor morale, low ammo). If it hasn’t already been covered in the Situation paragraph, this section can set the scene by talking in more detail about what the player's 'two-up' is doing in general and what their 'one-up' is doing in detail, and what the immediately flanking formations are doing. I wouldn’t go any wider or higher than that.

* Enemy Forces
This is the same as for friendly forces, with an emphasis on what the enemy is about on this battle on this map. Explain what the enemy has, including fire support and reinforcements, and identify any key strengths or weaknesses such as poor morale or low ammo. Again, you can set the scene by talking about what the enemy's 'two-up is doing in general, and what their 'one-up' is doing in a bit more detail. There should also be an indication of what the enemy is trying to achieve at a gross level. Obviously some FOW should be applied, so the information will be more general than for the Friendly Forces, but be really careful about telling outright lies. Some amount omission or slight under- or over-exaggeration, or emphasising something that is actually relatively unimportant, is ok, but telling outright lies so that any plan the player comes up with during setup is nullified once contact has begun is a sure-fire way of ensuring no one will play your scenarios.

As a stylistic thing, I aim to talk about what the enemy ‘will’ do, rather than what it ‘might’ do. Be positive and definite (and honest), so the player has confidence that the briefing actually means something, and isn’t just a rambling collection of words.

* Plan
I think this is the least important section. If the paragraphs above are sound, the player should be able to come up with a sound plan on their own. And, in fact, coming up with a sound plan is a big part of the game. 'Stealing' that from the players by giving them a perfect plan here is poor practice. On the other hand, you can give a broad-brush general outline of how you - as designer - think the battle will play out. Something like "1 Platoon will defend The Copse until reinforcements arrive and can advance to secure The Bridge" is ok, since you’re not telling the player how to defend the Copse, and are also reminding them that help is on the way, and therefore 1 Platoon can be ‘used up’ conducting its defensive task.

You can also guide the player in terms of what they're meant to be doing at different phases of the battle. So, the Plan could say something like
 

 

"3rd Platoon is close to the company objective, but isolated from the rest of A Company. But being paras the rest of A Company will be making their way here as quickly as they can. Use the time until they arrive to recon the objective and secure an Forming Up Point for the rest of the company to use when they arrive."

In principle the player could chose *any* location for the FUP, but presumably the route you expect they’ll take will be quite obvious.

If you overplay the plan here in the briefing, it starts to look like you're telling the player exactly what to do, turning them in to a mere observer rather than an active participant, and/or trying to lead them into an ambush. In some ways, it's a no-win situation for the designer. My best advice is: be honest. You don't have to tell them everything, but don't deliberately lie about anything.

* Notes
Um ... other stuff? I use it to list all the objectives and their points values, and to note any sources I used during development of the scenario. You can also dump parameter data in here (date, time, weather, wind, map size, friendly map edges, scenario length, etc) which can be a handy reference for the players, although I tend to put most of that in the Designers Notes since it's the same for both sides.

PROTIP: Check that the spelling of landmarks is the same in the imagery, in the briefings, in the objectives section of the editor, and on the map.

PROTIP: I find it’s a good idea to compose the briefings in Word, or something that has a spellchecker, then cut and paste the text into a .txt file, to avoid littering my briefings with silly spelling mistakes.

PROTIP: Be careful with abbreviations. Even if you use bog-standard military abbreviations, it is guaranteed that not everyone will know or understand what they mean. Consider including anything you intend to abbreviate in full the first time it’s used, followed by the abbreviation in brackets. For example: “battalion (bn)”

With all that in mind, this is the British briefing for The Sheriff of Oosterbeek.
 

 

15.3: screenshot of Microsoft Notepad showing an early draft of the full British briefing. Note the special characters used to delimit the file.

The first thing to note is that I’ve broken some of my own rules! This is deliberate, and is due to the particular situation that Sheriff Thompson found himself in on the 19th September. The British forces tumbling back from Arnhem weren’t his, and he would have had only the barest idea of what was going on, and the German forces approaching. Nevertheless, it is clear what needs to be done to win, and what the enemy probably consists of and what they’re trying to do. That, in conjunction with an inspection of the map will allow the player to develop a viable plan, at least for the first stage of the battle.

The second thing to note is that this version of the briefing was still quite rough, and was written well before the decision to severely truncate the scenario. I find it useful to knock up a quick and rough briefing fairly early in the design process, as it can help to crystalise some thinking, and serves as an aide-memoir for design ideas that might get forgotten. It’s also a really good idea to have at least a rough briefing – even if there’s no briefing imagery - in place before involving any testers, so they’ll have some idea of what they’re supposed to be doing and why they’re fighting this battle, here.

The format of these files is fairly straightforward, once you know a few things about them. It’s a basic text file which can be created and edited with something like Microsoft’s Notepad. You can export a template briefing file from the game editor (see also pages 114-115 of the CMBN base-game manual for the template and the official notes on the Briefing format).

Paragraph headings are automatically generated, and cannot be changed. The ^ carets are used in the text file to indicate a break between paragraph headings – the carets themselves don’t show up. Deleting the carets will delete the headings from bottom to top. In other words, deleting one of the carets will get rid of the Notes heading. Deleting two will get rid of the Notes and the Plan headings. It is not possible to delete an upper heading while retaining a lower one, so for example you couldn’t get rid of the Plan paragraph but keep Notes.

The / slash is used as a reminder to myself that this text needs to be deleted before it’s imported into the game. Having the section headers there is a handy reminder, but they have to go before the import, otherwise they show up twice (once auto-generated, and again from the text file, prefixed by the /)

Completed briefings can be saved anywhere, although again I find it most convenient to keep them in a folder in my Scenarios folder called – imaginatively – Briefings.
 

 

15.4: this screenshot of the editor shows how images are imported and exported. Note that you can also export images, which is useful if you lose the original and want to do some updates, or want to extract the images from another person’s scenario. The exact same process is used to import/export the briefings.

As a final thought on the briefing and imagery, let me emphasise that there is no correct or perfect format, and imagination should be used to craft something interesting and compelling. About the only rule is that they should work together with other elements of the scenario to tell a coherent and useful story, a story that is relevant to the battle the players are about to fight.

Back to start of thread

Edited January 22, 2015 by JonS

[PanzerMike]

Not wanting to be a Grammar Nazi, but the correct spelling is Nijmegen (and not Nijmwegen).

Thanks for showing us how it's done.

[JonS]

Not wanting to be a Grammar Nazi, but the correct spelling is Nijmegen (and not Nijmwegen).

Thanks. That was noted and corrected a wee while ago, but I didn't get a chance to update that image Remember that everything you see here is pretty much a work-in-progress.

[Heirloom_Tomato]

I have been reading this thread with great interest and it has really helped encourage me to do some work on creating scenarios myself. It has been very educational and I would like to thank Jon for taking the time to do this.

I have a question about the editor itself. When working on a larger map the editor seems to really slow down when I try to look at "the big picture" if you will. Does this happen to anyone else or is it an issue on my end? :confused:

The three smaller picture views of the map all run nice and smooth but anytime I go to the two big picture views the editor seems to bog down to where there is a two or three second delay in following my mouse clicks. It is not really too big of a problem but when trying to setup objectives or setup zones it is nice to look at the big picture every once and a while.

What map view level do you do most of your work on Jon? Do you experience this slow down as well on the bigger picture views?

Thanks again for a great thread!

[agusto]

I have a question about the editor itself. When working on a larger map the editor seems to really slow down when I try to look at "the big picture" if you will. Does this happen to anyone else or is it an issue on my end? :confused:

The three smaller picture views of the map all run nice and smooth but anytime I go to the two big picture views the editor seems to bog down to where there is a two or three second delay in following my mouse clicks.

I am having the same lag in the editor. It is normal on older machines, i guess.

[poesel]

I have a question about the editor itself. When working on a larger map the editor seems to really slow down when I try to look at "the big picture" if you will. Does this happen to anyone else or is it an issue on my end? :confused:

Same here. If I zoom out on a large map the editor grinds to a near halt although it displays only static 2D pixels. Strange.

IIRC there was a thread in the support section but no solution or reply from BFC so far.

[JonS]

I have been reading this thread with great interest and it has really helped encourage me to do some work on creating scenarios myself.

Yay! Mission accomplished

What map view level do you do most of your work on Jon? Do you experience this slow down as well on the bigger picture views?

Yeah, I get that too, and so I usually scroll on the speedy views and ... actually, I tend to do almost everything on the two biggest views. I usually only use the smaller views when I want to get an overview of the spatial relationships on the map.

[JonS]

16 - Programming the AI

"Artificial Intelligence usually beats natural stupidity."
trad., anon.

Creating the scenario for CM can take one of two distinct routes.

The first is the scripted linear approach which is targeted towards making the AI, and playing against it, the centrepiece. This can result in mazelike maps, with AI challenges stashed at various points for the player to overcome - the scenario is a puzzle for the player to solve. Design approached from that angle make it difficult to create a scenario suitable for H2H play because that design approach is inherently at odds with H2H play. These scenarios are artificial constructs and for the most part have very little connection with real accounts of battle because the Order of Battle and the terrain is moulded to fit the puzzle being created. An unexpected or undesirable outcome can be mitigated by adding extra force to the AI, or restricting the player’s freedom of manoeuvre in an effort to tightly control the flow of the battle and so maximise the strength of the AI. Scenario balance consists of creating the circumstances by which the player’s options can be limited – through restrictive or impassable terrain, restrictive setup zones, or force mis-matches – to produce the expected outcome.

The other route sees scenario design as more of a Table Setting approach. The designer is seeking to set the starting conditions with a map and an OB, and then allowing the player to tackle the tactical problem however he wants to. Balance in this form of scenario consists of weapon and overall force matchups, and careful consideration of the two side’s respective objectives. Making and adjusting this type of scenario can be more difficult and time consuming because you are always dealing with tradeoffs. Making a terrain adjustment to make it easier for one side to get their weapons into action is almost heretical, because the object is to give the player enough freedom to adapt and overcome the situation on their own using the tools available and their own talent. The designer doesn't need, or want, to give the player a crutch. A scenario like this is made appealing by giving the player command of interesting force combinations, unique weapon systems, interesting terrain to fight on, or an interesting tactical problem.

In practice the differences are never that stark, but designers generally fall towards one end or the other on that spectrum.

For head to head play 'table setting' scenario design style is the only way that will work if you want to make something fun to play for both sides. Scripted linear will produce great campaign scenarios, but it will always be hard to make good H2H scenarios because the mindset is fundamentally at odds with maximising freedom of action.

I aim to produce Table Setting scenarios, in which each side is presented with a problem, and the tools by which it can be solved. Inevitably that means that my scenarios generally aren’t ‘balanced,’ whatever that means in an environment in which player skill is wildly variable. They offer different challenges when played in different play modes, but those challenges are not all equally difficult. For the Sheriff of Oosterbeek I’m not aiming to beat the player, exactly, but rather to offer them the challenge of going up against plausible course of action by the AI. I expect that it will be:
* Easier to win as British Paras against the German AI. Planning a decent AI attack with forces that will also be viable H2H is very difficult.
* Harder to win as Germans against the British AI. Getting the AI British to set up a series of mini-fortresses, that the German player must reduce one by one, is a much more achievable task.
* Easier as British in H2H, because defending in complex terrain is generally an easier activity, and the Germans in this scenario aren’t favoured with overwhelming force which would allow them to attack everywhere.

Note that I expect them to be 'easier' or 'harder', not 'easy' or 'hard'.

The AI in CM consists of two separate elements:
1) TacAI – the Tactical Artificial Intelligence routines control unit’s responses to in-turn stimuli, in particular how they respond to the sighting of enemy units, target selection, and how they react to incoming fire. It also controls things like the exact route that units take across the map and around obstacles. The TacAI affects human-controlled and AI-controlled units equally. It cannot be controlled by the scenario designer.
2) StratAI – the Strategic Artificial Intelligence is programmed by the scenario designer, which provides the high-level scheme of manoeuvre that AI-controlled units will attempt to execute. Human-controlled forces have no StratAI – that function is hopefully being provided by the player!

(There is, technically, also the Operational Artificial Intelligence – OpAI – which handles the interpretation and execution of StratAI orders on a unit-by-unit basis, but I’ve ever worried too much about that.)

The first thing to realise about programming the StratAI in CM is that you are creating a strict schedule, and the schedule will be followed come hell or high water. The StratAI Plan you create is not dynamic – the AI-controlled units will continue to try and take that hill or defend that village, regardless of what the human player does. At a micro level the TacAI will dynamically handle engagements with enemy forces as they appear, but the StratAI will not alter its overall approach at all.

Therefore, it’s crucial to try and get ‘inside the head’ of potential players, and guesstimate they different ways they’re likely to go about tackling the tactical problems your scenario presents them. Also, I think that at a high level AI plans need to be fairly simple and generic – broad sweeping movements to seize or hold ‘big’ objectives, rather than fine scale movements from one piece of cover to another.

Of course, exactly how ‘simple and generic’ gets applied depends on the specific scenario – if you’re programming a platoon-sized action, it is possible, reasonable, and often necessary to include a large number of very specific orders for small groupings of units. But with larger scenario I find I need to step back and use a more sweeping approach.

The Sheriff of Oosterbeek is a reasonably big scenario, which means that the planning is going to be fairly sweeping. At a high level, there are three basic courses of action open to the German player - straight up the guts along the Benedendorpsweg, left-flanking through the open ground of the Rosander Polder, or right-flanking through the built up area along the north of the map. Feints and diversions can add some variety to each of those broad approaches, but those are the main outlines. The British player is most likely to create a series of ‘fortresses’ which maximise the defensive benefits of the buildings and hedgerows with liberally sprinkle the map and the short-range firepower of the multiple Stens present in every unit.

Programming the Sheriff of Oosterbeek’s AI started with the German plan no.1, which I refer to as “Straight up Benedendorpsweg” (or more technically “up the guts”), since that’s basically what I will have the AI doing. I’m not going to programme a left-flanking-through-the-open-ground attack, as that is too tactically naïve. However, I will develop at least one plan based on the other two courses of action, and probably a variant of each of those, for a total of four distinct plans. The discussion that follows, however, only covers the first 30-45 minutes of the ‘up the guts’ plan, otherwise this chapter would never end! For each of the plans I am aiming for the Germans to secure enough terrain objectives to get a draw or minor victory. I am not planning for them to advance clear across the map.

16.1: Using a worksheet for each plan helps to keep track of the various AI elements, and what they’re doing. Like the Objectives, I find it helpful to keep it information relating to each plan for each side together in a single location. This sheet provides an overview of the basic ‘up-the-guts’ plan and its moving parts, and is not intended to provide a waypoint-by-waypoint level of detail. I could have made my life easier by keeping all the elements of each Kompanie – in particular 1 Kp. – in adjacent AI slots. Initially I thought I was going to need slots A15 and A16 for a different force element.

The worksheet shown in figure 16.1 shows how I intend to group and use each AI force element, which in this case range in size from a rifle platoon down to a single StuG. There are no hard and fast rules around grouping units, but some rules of thumb I tend to use are i) try and respect the C2 chain, so units aren’t running about the place in weird amorphous blobs, ii) try and keep units of different mobility in different groups so tanks and infantry aren’t attempting to keep to the same timetable of waypoints, iii) avoid mixing on-map-at-start units in the same AI group with reinforcements, because the reinforcements will have to leg it across the map to try and catch up with their mates at the next waypoint.

The next step is to create a stepping-stone path of waypoints for each force element to move along. In order to keep the development of the AI plan tractable, I tend to break it down into discrete chunks, and develop each chunk through to completion before moving on to the next chunk. In this case that means through to the 30-45 minute mark for the Germans, which – all going well – will see them in possession of The Factory area. Once that is chunk is complete for all the force elements, I’ll move on to the second chunk, and so on until the plan is complete.

It is fairly easy to set a series of waypoints that will naïvely move the separate force elements to their intended ultimate location, but that will, predictably, leading to a bloodbath for the AI. Waypoints need to be set keeping in mind whether the force element is likely to be in contact with the enemy during each leg, or simply moving point-to-point. That, in turn, requires some consideration of how the overall battle is likely to be developing, and also how the various AI groups are moving and supporting each other. I don’t worry about timings at this stage, and instead focus on the larger picture of “while 1 Platoon is clearing the buildings between these waypoints 3 and 4, 2 Platoon provides support from their waypoint in the Barn, and the MGs are in overwatch from their waypoint on the Knoll.”

16.2: Composite image of the waypoints to be used by the German 2nd Kompanie, moving from the setup zone east of the overpass west towards the Factory. I haven’t worried about timings at this stage, only the locations the platoon will be moving to. This is one quarter of the AI groups in use, and already it’s getting pretty complicated.

Next up is timings, and these can take a while to wrap the old noggin around.

Each order is created with a time-window during which it should commence.
Exit After: refers to the earliest time that the AI force element will start trying to execute the order.
Exit Before: refers to the latest time the order will be commenced.

Generally, all being well, the units will commence their orders at the first possible opportunity. The main exception is if they’re currently actively in contact with the enemy, in which case the commencement of the order might be delayed until a safer moment.

The other exception particularly affects WEGO. If the time-window has not opened during a WEGO orders phase, then the AI will not issue orders to the units concerned. This means that if the Exit After time is set to 10:30, the units will not receive any orders until the 11:00 orders phase. Be a bit careful with the difference between Real Time and H2H - the overall rate of movement is faster in RT than it is in H2H. Their actual speeds aren't any different, but in RT they don't have to wait about for each turn to end before interpreting and applying the next order.

The actual times entered refer to the elapsed time since the start of the scenario. So if, for example, there is a series of three movement legs, which will each take 8 minutes, with a halt for a couple of minutes at each way point, then the timers should be set as follows:

Order 0: 00:00/00:30
Order 1: 10:00/10:30
Order 2: 20:00/20:30
Order 3: 30:00/30:30

That way the AI group will start moving as soon as the scenario starts (or at least within 30 seconds of scenario start), move the first way point, and wait there until 10 minutes in to the scenario. Then within 30 seconds of the 10 minute mark the AI group will start moving to the next way point, and so on.

You need to make sure that there is enough time to reach the waypoint within the designated time. If units of the AI force element don't reach waypoint 1 until the 12 minute mark, then they can ‘fall off’ the main line sequence of orders and subsequent moves and timings tend to fail – the AI force element will go to ground and just sit on its hands, not moving any more for the rest of the scenario. That's ok if they come under contact - you /want/ them to react to the enemy rather than blundering forward in a futile effort to follow The Plan. But if it's just a move out of contact with the enemy, and your timing is off, well, then the actual fighting you had planned for later in the scenario might never happen.

One method for ‘scooping up’ any units that’ve fallen off the sequence of orders is to deliberately introduce a very long time interval between two subsequent orders. This helps to ensure that units will be in a state to start responding to orders again - not broken or routing or in active contact with the enemy – when the applicable Exit After time rolls around.

A technique, or hack, that exploits this behaviour is to deliberately leave the Exit Before/Exit After times at 00:00/01:00, but it works best for admin moves out of contact. When a unit encounters a series of orders that are all set to 00:00/01:00 it’ll move through the waypoints as quickly as practical, without halting at each waypoint and waiting for the next Exit After timing. This can, for example, be a good way of efficiently moving reinforcements up from a map edge, but ‘real’ timings will be need to be in place when contact with the enemy is expected.

Initially I set all the time intervals between orders in 5-minute time chunks, which is assuredly wrong but provides a start point from which elegance and subtlety can be progressively introduced during a cycle of development-testing-refinement-more testing-etc. I’ll go into testing in more detail later on, but just briefly; watching the AI go about its order in Scenario Author Mode is an excellent way of checking that the units are moving the way you want them to, and that you've allowed enough – but not too much - time between waypoints.

16.3: Composite image of the waypoints and timings to be used by 2nd Kompanie, moving from the area near the overpass westwards towards the Factory. Note that the Kompanie HQ and HMGs moves up on to the rail embankment quite early, then stays there for quite a while providing firesupport to the rest of the kompanie as it advances, leapfrogging platoons past each other, through the buildings towards The Factory area. The timings shown here are the result of several cycles of testing and refinement.

PROTIP: be really careful with the arrival timing for reinforcements. It's quite easy to have a reinforcement arriving in a time window that overlaps with its AI order time window. For example, a unit is set to arrive sometime between 10-15 minutes, and its first movement order is at 12 minutes. If the unit arrives at the 10 or 11 minute mark there's no problem. But if the unit arrives after the AI order was set to initiate the unit will "fall off" the orders sequence, and never move at all. Therefore I tend to give units definite arrival times (rather than arrival windows), and set their first order to initiate at least 1 minute after they will arrive. This is what I’ve done for the Sheriff of Oosterbeek. Alternately, if I really want reinforcements to arrive in a window (which I think is generally better when playing against a live opponent) I’ll set the first AI order to begin at least 1 minute after the arrival window closes ... which can mean that units which arrive early sit around for a while before moving.

With the timings done the AI Order (basically, the movement stance, ranging from Dash through to Max Assault) and any end-point conditions (such as the floors to be occupied, or the range to engage at) can be adjusted. The following table shows the results of each AI Order type, tested using UK rifle platoons (HQ, three sections, and a 2-in mortar).

16.4: Table showing observations of AI behaviour using different AI Order types. Test was run over 800m on flat open ground. A British Rifle Platoon was used as it has an HQ, some rifle sections, and the 2-in mortar as a support weapon. The AI in CM treats each of these differently. To prevent unit getting too strung out many short legs can be used, instead of long distances between waypoints.

PROTIP: ‘Assault’ and ‘Max Assault’ will not work if there is only a single unit in the AI group, or the units in the AI group would not be capable of utilising the Assault command. As a rule of thumb, ‘Assault’ and ‘Max Assault’ should only be given to AI groups that contain several multi-team infantry sections.

PROTIP: The AI does not handle terrain that’s been bottle-necked very well, particularly with vehicles.

If you are going to have constricting terrain in a map, you have to be really really careful about how you programme the AI. A tank company in a single AI Group rushing a bridge is just not going to work. Tanks in overwatch for an infantry assault on the bridge probably would though.

NorMons (from the CW module) used an extremely authentic base map. When I started AI testing, it quickly became obvious that AI was having trouble moving about because of all the fields. I had plenty of little man-sized gaps in the bocage, but vehicles were limited to single tile wooden gate bottlenecks in what was otherwise a wall of green. The tanks were extremely vulnerable as they all tried to get through each tiny gap at the same time, jerking forward, pausing, and moving in tactically absurd ways.

To overcome this the map was changed by adding two or three tiles of low wall on either side of each wooden gate. Since the AI will happily drive tanks over walls to get to the next waypoint, this made the pathing options the AI investigated more numerous. At a stroke that resolved most AI pathing issues. The map wasn't quite as authentic anymore, but so what? It worked, and that’s more important. Often bottleneck terrain won’t become obvious until you start plotting out the AI plans, or running tests. If you notice that you’re trying to get a large number of units to squeeze through a single narrow gap, make a note to watch out for that during testing, and consider altering either the path units are using, the size of the AI Group using that path (that is: break a company up into several independent AI groups, with different time windows for transiting the bottleneck), or modify the map.

16.5: On the left is an example of potentially bottlenecking terrain. One or two vehicles will be able to get through this gap, but a platoon of four or five tanks will probably end up milling about in confusion as they all try to squeeze through at once. On the right is the same terrain, but with the bottleneck mitigated by replacing the bocage immediately adjacent to the gate with rural wall. As far as the AI is concerned this creates a much wider movement corridor, allowing multiple units to traverse it simultaneously with few problems.

Once the whole plan is complete, and thoroughly tested, it can be copied and pasted into another AI Plan slot and tweaked to create minor or major variations. This is a really useful way of adding some variety to the AI without a ridiculous amount of effort – compared to building an entire second plan from scratch it is relatively straightforward to, for example, alter the assault route and/or timing of a platoon while everything else remains the same.

Once more than one AI plan has been developed, their relative frequency of occurrence – that is the relative frequency players will encounter each plan - can be set. I believe players will generally only play a scenario - especially the bigger scenarios - once against the AI, and as such the player is only ever going to 'see' one AI plan. They won't know - or care - whether the plan they encountered was a good one or a dumb one. From their perspective they get the plan they're given, and that’ll be their impression of the scenario.

Furthermore, even if a player does replay a scenario, I think it's dollars to donuts that they would want to play against a different plan. As a designer that’s certainly what I’d want for them. But making other plans ‘rare’ or ‘infrequent’ just increases the chances they'll end up encountering the same favoured plan again, which defeats the purpose of having multiple plans in the first place.

Rare or Infrequent can be used as a way to ‘hide’ suboptimal plans, but I'm not sure that’s a good idea. If you aren’t happy with an AI plan, either improve it or set it to 'never.' Setting a sub-par plan to 'rare' simply guarantees some players will encounter it, and be disappointed.

Given all that, I think all plans should be set to an equal likelihood of appearance, and they should all be, broadly, as capable as each other

In a previous chapter, the friendly map edges were set in the scenario parameters. One of the key uses for that setting is helping the AI interpret terrain as either friendly or enemy. The AI will set up within each waypoint on the ‘friendly’ side of terrain such as hedgerows walls, using the Friendly Map Edge (FME) setting to determine which side that is. However, since there can only be one FME, anytime you have the AI moving in a direction that isn’t directly away from the FME they’re likely to struggle to set up in the way you’d expect them too. Having infantry move to a hedgerow then set themselves up on the enemy side can be frustrating, so careful consideration of the FME setting, and reasonably simple AI plans that take it into account, are useful tricks to remember.

PROTIP: giving the AI a hide order for several minutes, then following that up with an ambush order (but no new movement waypoint) is a good way to lull an unwary player right into a trap.

Although not used in The Sheriff of Oosterbeek – artillery and mortars for both sides have been deliberately delayed to arrive as reinforcements – the AI Fire Support plan is a good way to have the AI make decent use of its artillery assets. Basically, paint a number of target areas, then set the kind of fire support you want to arrive. During the seyup phase the AI will automatically assign artillery resources from top to bottom of the list, so if there are more targets that fire units, the bottom targets will always be ignored.

With the perfect knowledge the designer has it is possible to use this functionality to smite the player, badly. That’s the kind of thing that really annoys players, and is probably best avoided. I tend to use it to shape the battlefield by applying low-rate maximum-duration missions to deny areas I’d prefer the player didn’t move through, rather than high-intensity but brief destruction missions. It’s also a good idea to save some artillery ammunition for the AI to use as it sees fit on targets of opportunity later in the battle.

There is only one AI Fire Support plan available, and the catch with using it is that only the first AI plan will be utilised, regardless of how many there are, nor what the relative frequency is set to. After a bit of thought the reason for this becomes obvious: with only one Fire Support plan available, it is all but impossible to craft one that would suit several different movement plans. To put that more succinctly: if you are going to use the Fire Support, you only need create one AI Plan.

AI Plan Checklist:
* create a plan for your AI elements and map it out before starting with the AI editor.
* Think in terms of moving force elements, rather than individual units.
* Try and keep the plan fairly simple.
* Pay attention to where the Friendly Map Edge is.
* Get one plan working well before copying and pasting it.
* Set modest and reasonable ambitions for your AI plans. Don’t expect to be able to programme a Rommel-esque plan without a lot practice.

Back to start of thread Edited January 8, 2015 by JonS

[Ithikial_AU]

2) StratAI – the Strategic Artificial Intelligence is programmed by the scenario designer, which provides the high-level scheme of manoeuvre that AI-controlled units will attempt to execute. Human-controlled forces have no StratAI – that function is hopefully being provided by the player!

From someone who has had to write home to Pixeltruppen mothers more than once with the excuse "Jimmy took that hill as ordered, but the Company CO forgot he had a planned arty barrage to come down upon it a couple of minutes later..." StratAI is not always guaranteed by a human player.

Quick question. More about reserves rather than AI plans but is there any way for designers set an 'exit' time for off map support? ie. Your 105mm howitzers will be needed elsewhere after the first thirty minutes and no longer available. If a scenario author wanted to have a 'use it or lose it' factor involved with off map support.

[JonS]

From someone who has had to write home to Pixeltruppen mothers more than once with the excuse "Jimmy took that hill as ordered, but the Company CO forgot he had a planned arty barrage to come down upon it a couple of minutes later..." StratAI is not always guaranteed by a human player.

Ha! The pixeltruppen under my command have the same problem :eek:

Quick question. More about reserves rather than AI plans but is there any way for designers set an 'exit' time for off map support? ie. Your 105mm howitzers will be needed elsewhere after the first thirty minutes and no longer available. If a scenario author wanted to have a 'use it or lose it' factor involved with off map support.

No. That kind of thing has been asked for several times, and there've been times where I'd like to have used it, but at CMs scale it probably isn't really necessary. At the scale of Bn and Coy command, once you had an asset you tended to keep it until you'd finished your, uh, combat mission. Resources were haggled for beforehand, and would be whipped away afterwards, but not while you were actually in combat.

One way you can sort-of simulate it, though, especially with off-map artillery, is to really dial down the amount of ammo available. I've used that to sim the guns and their bombs being needed elsewhere, and/or your battle not being the main effort.

[Seedorf81]

JonS,

If you haven't yet received an offer from an university to give lectures, it can only be because they did not see this magnificent thread.

[kohlenklau]

Loamshire University?

[A Canadian Cat]

There is only one AI Fire Support plan available, and the catch with using it is that only the first AI plan will be utilised, regardless of how many there are, nor what the relative frequency is set to. After a bit of thought the reason for this becomes obvious: with only one Fire Support plan available, it is all but impossible to craft one that would suit several different movement plans. To put that more succinctly: if you are going to use the Fire Support, you only need create one AI Plan.

That is an important bit of information. It would seem like a good idea to have a fire support plan for each AI plan.

That leads to a question: How good is the AI at making use of its artillery on targets of opportunity? What I am trying to figure out is this: if I have a force with a decent amount of artillery does it make sense to create multiple AI plans and forgo a fire support plan? Or would I be better off sticking with one plan but having a fire support plan that works with it.

[Paper Tiger]

That is an important bit of information.

I don't think he meant to say that the AI will only use the first AI plan when there are multiple AI plans when an artillery fire plan is used.

Here's a very simple test. There are three AI plans and one artillery fire plan. In plan 1, the AI will set up its units in the Plan 1 lane and move up.

In Plan 2 they'll set up in Lane 2 and advance up. Same with AI plan 3. There is an artillery fire plan where the AI will drop mortars near the top edge of the Plan 2 lane.

In the first run through, AI Plan 1 is set to Use Frequently while 2 and 3 are set to Rarely. Here's what happens:

As you can see, AI plan 1 is selected, the artillery is falling and the AI is moving the units up lane 1.

Now we change the frequency so that Plan 2 is Use Frequently while 1 and 3 are used Rarely. Here's what happens:

The AI sets up in lane 2 and moves up as the artillery fire plan falls.

And again with AI Plan 3 set to Frequently and the other two to rarely:

So it is possible to create an artillery plan and have the AI utilise all the available plans.

[Paper Tiger]

Oops. I'm not really sure what some of this is supposed to mean:

Next up is timings, and these can take a while to wrap the old noggin around.

Each order is created with a time-window during which it should commence.

Exit After: refers to the earliest time that the AI force element will start trying to execute the order.

Exit Before: refers to the latest time the order will be commenced.

Generally, all being well, the units will commence their orders at the first possible opportunity. The main exception is if they’re currently actively in contact with the enemy, in which case the commencement of the order might be delayed until a safer moment.

The manual gives quite a clear explanation of these two orders and your interpretation of how Exit Before works is slightly different.

From the manual P139

The Exit Before option causes the group to try very hard to get to the next Order in the plan before the specified scenario time is reached. This does not mean that the Group will do it, just that it will try. If it has taken excessive casualties, is immobilized or heavily engaged, it may blow the Exit Before time. It will still attempt to execute the next order in the plan, just not within the time that the scenario designer allotted for it.

I'd have to say that that is how it appears to work when I test it and it's been that way since CMSF. I'd hesitate to say that your interpretation is wrong as you are a very experienced scenario designer and you've been on the design team a LOT longer than I have but I can't understand how the scenario designer can set a designated time for the AI to reach the waypoint if Exit Before works the way you claim in this part of your post.

You need to make sure that there is enough time to reach the waypoint within the designated time. If units of the AI force element don't reach waypoint 1 until the 12 minute mark, then they can ‘fall off’ the main line sequence of orders and subsequent moves and timings tend to fail – the AI force element will go to ground and just sit on its hands, not moving any more for the rest of the scenario. That's ok if they come under contact - you /want/ them to react to the enemy rather than blundering forward in a futile effort to follow The Plan. But if it's just a move out of contact with the enemy, and your timing is off, well, then the actual fighting you had planned for later in the scenario might never happen.

It's quite possible to create plans entirely without using the Exit After parameter and not see the AI group 'fall off'. For example, as you explain here, you can leave them both at the default and the AI will move from waypoint to waypoint unless they are somehow prevented as explained in the manual. How is this possible if what you said about Exit Before is true?

A technique, or hack, that exploits this behaviour is to deliberately leave the Exit Before/Exit After times at 00:00/01:00, but it works best for admin moves out of contact. When a unit encounters a series of orders that are all set to 00:00/01:00 it’ll move through the waypoints as quickly as practical, without halting at each waypoint and waiting for the next Exit After timing. This can, for example, be a good way of efficiently moving reinforcements up from a map edge, but ‘real’ timings will be need to be in place when contact with the enemy is expected.

If you are correct, then isn't the Exit Before telling them to start moving to the next order sometime before the first minute of the mission? There's nothing telling them when they should arrive by.

[ASL Veteran]

That is an important bit of information. It would seem like a good idea to have a fire support plan for each AI plan.

That leads to a question: How good is the AI at making use of its artillery on targets of opportunity? What I am trying to figure out is this: if I have a force with a decent amount of artillery does it make sense to create multiple AI plans and forgo a fire support plan? Or would I be better off sticking with one plan but having a fire support plan that works with it.

Another way of saying it is that there is only one artillery plan and every AI plan will use the same artillery plan. Therefore if I have three AI plans all three will use the same artillery plan since there is only one artillery plan. This effectively restricts how you contruct your AI plans since all of your AI plans are stuck with the same artillery plan.

The AI is pretty good with opportunity fire for artillery. On the attack you generally need to have someone sitting in place for a while before they use it. If they are continuously moving then the AI doesn't have a chance to drop it anywhere since they may end up running into the area that the FFE is landing.

[Paper Tiger]

Well, I guess I should 'fess up and say that there does appear to be something wonky with AI plan selections when there is an AI fire plan and the frequency settings for each plan are equal. Skew them by setting one to Use Frequently and the others to Rarely and it will pick the Frequently one. Set them all to Sometimes and it will pick the same plan almost every time.

I guess it's easy to miss when I'm testing my AI plans as I disable all the others while testing one and so the fire plan will work with whichever plan I use.

[A Canadian Cat]

Well, I guess I should 'fess up and say that there does appear to be something wonky with AI plan selections when there is an AI fire plan and the frequency settings for each plan are equal.

pick the same plan almost every time.

Bummer, I was hopeful after your earlier post. Can you make frequency choices for the different plans to compensate and end up with settings that are close to equal when there is a fire plan?

[Paper Tiger]

Well, curiouser and curiouser. In my first test, I used Allied units for the AI side. I set up another test, this time using German AI units and it all seems to be working just fine. The problem seems to occur when you're making fire plans to support the Allied side. Since I have been working with Allied forces against AI-controlled Axis forces, this would explain why I haven't seen this before. More testing will be required but the more of us doing it, the better.

Edit to add:

I've run the same test about ten times: three Axis AI plans, all set to Use Sometimes, three lanes and an off-map support asset. It picks each plan regularly.

Also, for the Allied side, it doesn't matter if the artillery assets firing are on-map or off-map. The Allied AI will always seem to pick the same plan when the weight is the same.

[ASL Veteran]

Well, curiouser and curiouser. In my first test, I used Allied units for the AI side. I set up another test, this time using German AI units and it all seems to be working just fine. The problem seems to occur when you're making fire plans to support the Allied side. Since I have been working with Allied forces against AI-controlled Axis forces, this would explain why I haven't seen this before. More testing will be required but the more of us doing it, the better.

Edit to add:

I've run the same test about ten times: three Axis AI plans, all set to Use Sometimes, three lanes and an off-map support asset. It picks each plan regularly.

Also, for the Allied side, it doesn't matter if the artillery assets firing are on-map or off-map. The Allied AI will always seem to pick the same plan when the weight is the same.

Many were noticing the odd way that the AI plans were being selected even when no artillery plan was being used. It was never able to be proven to the point where something was done, so perhaps you can reply in Pete's thread if you haven't already (I haven't checked those forums yet before typing this).

[ASL Veteran]

With regard to the Exit after and Exit before .... it used to be that broken and rattled troops would stop following the AI plan but that was modified back sometime ago .... in between when Commonwealth was released and CMBN was released. I don't remember exactly. Anyway, the truppen will always follow the plan to completion or until they are eliminated whichever comes first. The only thing is that currently Rattled and Broken etc status truppen will follow the plan much more slowly and will hang back from non rattled truppen. Another thing that I have noticed is that the AI will not necessarily wait until all members of a group reach a certain waypoint before moving on to the next waypoint. So your truppen can get really strung out if you have to move them a long way and you don't have any delays baked in with the Exit After times. This especially seems to happen with Mortar teams and higher level HQ teams. Sometimes they actually wait so long to move that the leading elements of a group have already started off to the next waypoint - in which case the mortar teams and HQ teams may skip a waypoint and just head for the next one. This is very annoying behavior if you have carefully selected a covered approach and all of a sudden, because your mortar team was hanging back for so long they end up running out in the middle of a field because they are skipping a waypoint. Exit Before times are useful for keeping those mortar teams from falling too far behind the leading elements.