Nijmegen 1944

Version 1.2 (02.11.2013)

The scenario is a tribute to the first computer wargame i played, CCS’ Arnhem for Amstrad CPC and my first TOAW PbEM which was Erik Nygaard’s ‘A bridge too far 1944′. It is strictly historical, without the small ‘what-if’ options you may know from my other scenarios. I always found the battle for Nijmegen to be one of the most decisive parts of Market Garden. If the Allies had taken Nijmegen bridge earlier or just would have pushed on after the bridge fell instead to pause, the entire operation most probably could have been successful. Harmel, commander of 10.SS Panzer-Division, wondered, even after the war, why the tanks that had rushed the Nijmegen bridge with such elan had not continued further: ‘At this instant there were no German armoured forces available to block Elst’. In fact, the British pause allowed the Germans to organise their defence on the Betuwe and to deny XXX Corps the route to Arnhem.

The scenario has been designed for and under TOAW 3.4 and can be played with the new supply and the new turn order rules. Download (external link – dropbox)

PBEM and Human vs PO play (both sides PO enabled)

Date: Sept 17th, 1944
Location: Nijmegen, Netherlands
Map Scale: 1km/hex
Turn Scale: 6 hour turns
Unit Scale: Company/Battalion
Length: 14 turns

Due to the uncommon scale the following editor parameters have been set:

Supply & Readiness Cost for Movement: 40
Combat Density Penalty: 200
Movement Bias: 250 (both sides)
Entrenchment Rate: 33

MRPB: 3
Attrition Divider: 20

The scenario uses a modified version of Brian Wilson’s WWII equipment database with adjusted artillery ranges to fit the 1km scale. The scenario also uses a modified GameText.xml that displays marsh as polder. Make sure that you put the file “Nijmegen1944GameText.xml” into the same folder as the scenario file. Note that the special GameText file is in English and overwrites other language settings when you open the scenario. To play the scenario in an other language than English rename or remove “Nijmegen 1944GameText.xml” from the scenario folder before opening the scenario.

Version Changes

Version 1.2

  • Fixed a bug that withdrew the wrong RAF unit on turn 6
  • Lowered KG Henke’s 1st and 2nd battalions’ formation proficiencies
  • All units have now veteran status. Note that this is only pro forma as final unit proficiency variation after first combat has proved to be too „wild“.
  • Updated the Briefing. Special thanks to ‘General Staff’ for proof-reading.

Version 1.1

  • Changed the escarpments for Nijmegen bridge
  • Reworked AT values for German Squads and RPzB 8.8cm
  • Slight change in US Airborne TO&Es: Replaced the M1919 MMG in airborne and glider infantry companies with M1919 LMG teams
  • Reduced German garrisons’ formation proficiencies from 60 to 40
  • Briefing: Expanded chapter 5.0 Scenario Design Notes and added an OOB chart as chapter 6.0

Map and turn 1 setup:

Classic Redux II

This is not only an update to the Classic Redux I graphic mod, but also an extension as the mod contains several GUI styles and a complete unit counter set. However, i have split the download in three parts – terrain, GUI and counters – so that everyone can pick their likes. The look of the terrain tiles is only partially similar to the Classic Redux I mod as some graphics have changed completely ( especially urban and rivers) while others have only been slightly modified (i.e. open and desert terrain) and some stayed the same (hills, marsh i.e.). But see for yourself (thumbnails can be clicked for detailed view):

Unit Counters: All color combinations in one picture:

Counters

And the GUI:

There is not only one, but 10 GUI Mods! Note that the GUI mods are themed, i.e. the Mod ‘Eastern Rust’ has a World War II Soviet theme while the Modern Olive style is a Cold War/Post Cold War general theme. Also note that the download contains an Opart 3 fonts .ini file with the settings and fonts that have been used for the screenshots. Please also read the ‘readme’ text file that is contained in the download.

Download links (dropbox):

Terrain: https://www.dropbox.com/s/6ljkp07c0sstby6/Classic%20Redux%202%20-%20Terrain.zip

Unit Counters: https://www.dropbox.com/s/pnurw1zjwlirkre/CR2%20Counters.zip

GUI: https://www.dropbox.com/s/5u00rvhdvqyn6uz/CR2%20GUI%20styles.zip

Shunwick’s Supply Calculation Spreadsheet

Long time “TOAWer” Mr. Shunwick kindly permitted me to host his supply calculation spreadsheet for TOAW which – in his own words – is “a very simple spreadsheet to calculate how much supply a unit will receive and how many turns it will take a non-moving unit to fully resupply”. I think it’s a useful tool, not only for players, but also for scenario designers. Klick the link below to download the excel file.

Supply Spreadsheet

I also added it to the right side bar under ‘Useful Tools’.

Struggling with the Ev(il) Ed – Part 3: MASAF

The Allied PO’s handling of MASAF (Mediterranean Allied Strategic Air Force) provided a new challenge. The background: MASAF should be activated when the German player occupies one or more hexes within a certain radius from Anzio (by a ‘Force 2 occupies’ event). I assume this to happen in the context of a general counteroffensive against the beachhead as was the case historically. However some more conditions must be met for the actual activation of MASAF:

  1. MASAF should be activated when the German player occupies one or more hexes within a certain area centered around Anzio – Nettuno.
  2. MASAF should not be activated on a storm turn, but on the next non-storm turn after condition no. 1 has been met. (re storm turns and the weather engine please read the previous post)
  3. MASAF should not be activated prematurely due to a local attack early in the game.

This means we will have to trigger an event by more than one trigger. Colin Wright, who encountered a similar challenge (see his post at TDG), inspired me to use a combination of ‘Set Ownership’ events and a ‘Blocking Unit’.

This is what i came up with – again i added the weather engine’s triggering events (#74 – #79):

Actually the event sequence for the activation of MASAF is splitted in two parts. The first part is from event #622 to event #627, the following, second part follows the usual activation patterns as for MATBF.

Let’s begin with the first part. It is essentially a loop that sets an ‘off map’ hex (hex 45/62 – see the picture below) to ‘Ownership 2′ on the pre-dawn turn and back to ‘Ownership 1′  on the morning turn.

For this the loop is tied to the weather engine’s perpetual loop which also fulfills condition no. 3 as the weather engine starts not until turn 25. The hex is occupied by a Force 1 unit, so that the ‘Ownership 2′ event (#622) can not trigger until the unit is withdrawn. When the German player fulfills condition no. 1 (event #626) that blocking unit is withdrawn. On the next pre-dawn turn the ‘Ownership 2′ event (#622) can fire -  note that it can only fire on a pre-dawn turn (event #74, which it is tied to, is activated each pre-dawn turn) and that it is repetitive. Also note that it fires on each pre-dawn turn due to the repetitive ‘Ownership 1′ event (#623). This is to enable a synced activation of MASAF. We don’t want the PO to use MASAF on PM turns due to the severe PM air shock. By the way, the Force 1 supply point in the off-map hex that prevents the blocking unit from starving and eventual evaporation doesn’t influence the ‘Ownership’ events.

Now for the second part. There is not much to say that hasn’t already been said in part 2 of this series as it follows the same pattern as MATBF (3)’s activation. When the ‘off-map’ hex (45/62) changes ownership to Force 2 it triggers a ‘Force 2 occupies’ event (#630) which triggers the PO activation of MASAF. This event can, as outlined above, only be triggered on pre-dawn turns and due to events #628 and #629 only on non-storm turns (fulfilling condition no. 2).

Struggling with the Ev(il) Ed – Part 2

The saga continues. I thought i’d continue from the last article and maybe make a series of Event Editor articles as i progess with my work and encounter interesting and somehow challenging things – particularly as i think other TOAW scenario designers may find this helpfull and rookie designers may get an insight into the Event Editor’s capabilities – and pitfalls.

In the last post i described how i got the PO to activate a certain event on a certain turn that is depending on a random event, but before I continue I think i first need to explain the background a bit more detailed. In ‘Anzio 1944′ the Allied player has a series of theater options for additional air support. There are three different formations available to him, US XII ASC (U.S. XII Air Support Corps), MATBF (Mediterranean Allied Tactical Bomber Force) and MASAF (Mediterranean Allied Strategical Air Force), each one will be available for two turns. Let’s take MATBF: the Allied player has five activations of MATBF, each one brings in a new formation from the TOAW OOB after the ‘previous’ formation has withdrawn. The formation that is activated by the first theater option already starts on the map, but in garrison mode. This is the according event sequence (left column is the event number, right column is for explanation and comments):

However, the Allied player must take care of weather and daytime. The scenario has 6 hour turns; each day is represented by four turns, two AM turns (morning and afternoon) and two PM turns (night and pre-dawn). There is an air shock of 5% on PM turns. Additionally, each day (beginning on turn 26) there is a 40% chance for stormy weather which will prevent effective use of aircraft by a severe air shock on the two AM turns. This is handled by a repetitive loop that produces a storm warning each pre-dawn turn in the ‘recent news’. We can leave the effects of the event chain aside (air shock, theater recon etc) and just look at the loop itself:

So, what we need is to prevent the PO from selecting an Air Support Option on such a storm turn. This has been handled by the previous article.

But that article described only how the PO should handle one Air Support Option – or better: the first option that is subject to the ‘storm turn problem’. As it turned out this was a bit more complicated for following options of the same formation. Again we take a look at MATBF, this time the third activation. Needless to say, the third activation should occur on the next non-storm day after MATBF’s second activation (note that MATBF’s first activation occurs before turn 25 when the weather loop starts).

The relevant events start at #609. I included MATBF (2) and again the ‘weather loop’ as MATBF (3)’s events refer to these. Note that we need almost twice as many events as for the previous activation events for MATBF (2).

The first two events, #609 and #610, prevent the actual activation event (#615) from triggering immediately after event #604 (MATBF’s 2nd activation) has been activated. Events #611 and #612 kill this perpetual loop upon activation of MATBF (2) by event 604. Note that i had to insert these four events before the actual activation sequence. If i hadn’t put them on top of the sequence, but at the end, event #615 would have fired one turn after event #604. This is because the Editor goes through the events in numerical order. Event #613, being dependent on event #78, which would have triggered event #604 by a failed probability check, would have enabled #615 before the perpetual loop could have cancelled it.

Yet, that’s not all. Event #609 is again fired one last time one turn after event #604 (and thus #611 and #612) is triggered. This again prevents immediate triggering of event #615.

Next follows the activation sequence in almost the same pattern as described in the previous article, except for two variencies. According to the event pattern of MATBF (2) i would have needed a delay of 1 for event #613, but inexplicably this didn’t work and MATBF (3) entered the map already on the pre-dawn turn. I then set event #615 to trigger an additional event (#620) that triggers yet an other event (#621) which has a delay of 1. Then it did work as intended.

I hope that was not too confusing. Rookie designers calm down, the above is quite pushing the Event Editor to its limits. Most scenarios have not that demanding and special set-ups. Also note that a lot of work with the Event Editor, especially in such a demanding case, is try and error. As it was in this case. It took numerous runs with a test scenario until i found a working event pattern. Feel free to comment or criticize.

News from the front – struggling with the Ev(il) Ed

A short update.. i am currently working on updating ‘Anzio 1944′ to TOAW 3.5 which eats up most of my time, so i really haven’t had time for other design projects, especially Exporter.  For 3.5 – with the increased event slots – i will merge the PO version with the PBEM version into one scenario which means i’ll have to re-write the entire event sequence from scratch. The original scenario’s event sequence has become quite a mess due to numerous edits and bug fixes. To retain clarity and for overview purposes i now use an excel sheet. It might not be the best tool, especially as portation to the editor has to be done manually, but it works. I can group event sequences with filters, use colour codes and other kinds of visualizations to mark important events that trigger others, add comments etc.:

Having a clearly structured sheet/overview for the entire event structure will make future edits, additions and debugging a lot more comfortable. Not only that – it might also help players who may want to modify the scenario to their gusto and other designers to see ‘how the others do’. The sheet will certainly ship with the scenario.

As always when it comes to the Event Editor i’ve ran into the usual problems. It took an entire evening and numerous runs with test scenarios to figure out how to prevent the PO from using one of the Air Support Options during a storm turn. I know, i have done this before for the 2km version and for the 1km PO version, but that was not as sophisticated. I wanted the Allied PO to select an air option on a certain turn, but it should only trigger on the next non-storm day. Had i known – or remembered(?) – that events with the ‘Event Cancelled’ trigger do not ‘recycle’ themselves like the ‘Event Activated’ trigger does, i could have saved quite some time and headache.. For anyone who wants to dig into this, see the following chart.

 

One might think that the simple sequence:

#595 EvCancelled 78, Enable 597
#596 EvAct 78, Cancel 597
#597 Turn 28, PO 1 activate

would suffice. But, as written further above, this isn’t. With this configuration event 596 would only fire if there is no second storm day following a first one.

Event 78 triggers the stormy weather and related effects (air shock among others) with a 40% probability every fourth turn. Should the event fire, the ‘PO 1 Activate’ event will be cancelled. Events 595 and 596 will have to be re-enabled every fourth turn. This is done by event 75 (via events 598 and 599) which also is ‘responsible’ for the weather loop. Finally, when the PO has activated the theater option, the mini-loop will be ‘killed’ by events 600 and 601 to prevent further triggering of the TO on later non-storm days.

Note the delay of 1 with event 595. This has been necessary to ensure that event 481 is triggered on the correct turn if its activation is delayed by one or more storm turns. Without the delay it would trigger one turn too early.