MWIF Monthly Reports

[Shannon V. OKeets]

April 14, 2021 Status Report for Matrix Games’ MWIF Forum

Product Releases
No new Hot Patches last month. The beta testers didn’t get any new versions either. Mostly I spent March (and half of April) going over the code for calculating supply paths. Some of my time I spent on overland supply, but for the majority, I was deep in the code for overseas supply. All told, the number of lines of code making supply work in MWIF is 20,000+.

A lot of nested loops are necessary to check for each major power and minor country through all the sea areas. There are over 5500 ports on the map ,which have the potential of connecting sea areas to rail lines. The program needs to look into all of them too.

Because World in Flames rules for supply include several important optional rules, especially when coupled with the rules on cooperating major powers and states of war between major powers on opposite sides, programming all the requisite pieces is very aggravating. In the end, it isn’t as simple as just finding a path from one hex to another. Each hex and sea area along the way has to be checked to make sure supply can flow through it. And those checks are executed repeatedly to include every country with units on the map.

Bugs
All three of my tasks lists are out-of-date. They were in pretty good shape as of the end of March. But that was 2 weeks ago. Those tasks lists are: (1) bug reports from Tech Support (and other threads in the MWIF forum), (2) problems reported by the beta testers, and (3) the automated emailed bug reports (Mad Except errors).

My estimate is that supply works correctly 99.9% of the time. Which means that when I go through the code trying to fix a bug, that percentage of the code is correct. The trick is to ‘see’ the lines that are imperfect in the midst of all the correct code. To accomplish that I add hundreds of debug statements and then step through the code line by line until I find something that yields an incorrect result.

Here are the 4 corrections I have made over the past 4 weeks:

1. Fixed a bug in tracing a Basic supply path greater that 1 hex from a port to a primary supply source. This was causing some overseas units to be out of supply which needed to find primary supply 2 or 3 hexes inland from a port.

2. Fixed a problem with the Axis propagating overseas supply through Gibraltar (when it is Axis controlled).

3. Fixed a problem with the form that displays Supply Sources and Routes. It had not been showing the capitals of conquered minor countries which trace supply to a major power that cooperates with the conquering major power.

4. Fixed a problem with tracing overseas supply through the Eastern Med for Italy when the conquered Greek city of Athens must be used as a secondary supply source.

Right now I am trying to figure out why units in Damascus, Syria (controlled by the Free French) are unable to trace supply to Dakar, Senegal (the capital of the new home country for France). Once again, the overseas supply links are the problem. The are no Allied convoys in the Med and the Commonwealth doesn’t cooperate with France, so the supply path has to go around southern Africa, using Commonwealth convoys - which is legal. I’m close to solving this, ... that seems to be my continual state with all of these supply bugs.

Missing Optional Rules & Half Map Scenarios
I still need to get the optional rule Flying Bombs working. My list for the remaining missing optional rules is unchanged from last month.

5. USSR Japan Compulsory Peace Rules as Coded 13.7.3
6. Guards Banner Armies Rules as Coded 22.4.14
7. Naval Supply Units Rules as Coded 22.4.13
8. Limited Aircraft Interception Rules as Coded 14.2.1
9. Hitler’s War Rules as Coded 13.3.2
10. Partisan HQs Rules as Coded 22.4.16
11. Recruitment Limits Rules as Coded 4.2
12. Rough Seas Rules as Coded 22.4.6

AI Opponent (AIO)
Nothing new on the AI Opponent in March. I expect to get back to this in April - which is already half gone.

[Shannon V. OKeets]

May 8, 2021 Status Report for Matrix Games’ MWIF Forum

Product Releases
No new Hot Patches last month. The beta testers got 4 new versions. Continuing my focus on supply, most of the code changes this past month were to fix problems where supply calculations were taking too long. I expect to get a new hot patch out mid-May.

Bugs
All three of my tasks lists remain out-of-date. None of them is close to being current. Which, obviously, is what I need to work on tomorrow.

To figure out the problems in supply, I added dozens of timing snapshots. There are 23 steps to calculate supply for all the units on the map. First is identifying all the primary supply sources for all the countries. Then the possible secondary sources are tested to see if they can trace paths to a primary. That requires several steps since it is best if a secondary can trace to a primary controlled by the same major power. Overland and overseas are another place where the work has to be done twice. Cooperating major powers, aligned minor countries, HQs functioning as primary supply sources for the impulse and turn, all add to the complexity.

Using the timing data, I am able to determine which major powers are taking a long time to find supply paths. Next I insert more fine tuned timing snapshots to see if the problem is with individual secondary supply sources, and if overseas routes are the guilty parties. None of this is easy. I have detailed notes for a lot of specific bug reports. In a few instances, fixing one bug solves one or two others. But that is rare.

By now I have cleared roughly 2/3rds of the supply bugs on my master task list. In that group several dated back to 2016. Those that remain I view as very low priority. It is time to go back to working on other stuff.

Here are 5 corrections I made over the past 3 weeks:

1. Fixed a problem with supply calculations taking too long. For incompletely conquered France, with a new home country in, say, Western Africa, the program should not attempt to find supply back to its new capital from ports in the USSR or Scandinavia. Indeed, no ports in Europe should be investigated unless the new capital is in Syria, Tunisia, Algeria, Morocco, or Yugoslavia.

2. Fixed another problem with supply calculations taking too long. The program was searching for a path from ports in Scandinavia, the Balkans, Greece and Turkey to a Commonwealth primary supply source. No port in those countries is ever going to be able to reach a city in India (primary supply for the Commonwealth), so the searches shouldn’t even be attempted.

3. Fixed a problem with tracing basic path supply overseas to Baku in the Caspian Sea.

4. Fixed an obscure supply bug where Mao was unable to trace supply to a Chinese city controlled by Communist China once Japan was conquered and China became neutral.

5. Fixed a problem with finding primary supply cities for Nationalist China when Japan has been conquered and China is neutral.

Missing Optional Rules & Half Map Scenarios
I still need to get the optional rule Flying Bombs working. My list for the remaining missing optional rules is unchanged from 2 months ago.

1. USSR Japan Compulsory Peace Rules as Coded 13.7.3
2. Guards Banner Armies Rules as Coded 22.4.14
3. Naval Supply Units Rules as Coded 22.4.13
4. Limited Aircraft Interception Rules as Coded 14.2.1
5. Hitler’s War Rules as Coded 13.3.2
6. Partisan HQs Rules as Coded 22.4.16
7. Recruitment Limits Rules as Coded 4.2
8. Rough Seas Rules as Coded 22.4.6

AI Opponent (AIO)
Nothing new on the AI Opponent in April. I have to get back to working on this in the rest of May.

[Shannon V. OKeets]

June 8, 2021 Status Report for Matrix Games’ MWIF Forum

Product Releases
No new Hot Patches last month. The beta testers got 3 new versions to check out. I just now uploaded another new version for the beta testers. Once they have had a week or so to look it over, I’ll post it as a Hot Patch for customers.

The slowdown in releasing new versions is due to me spending more time on developing the AI Opponent. That is likely to continue to be the case for the rest of this year. Not that bugs and other stuff will be completely ignored, but the only way for me to make progress on the AIO is to give it higher priority, week after week.

Bugs
I brought 2 of my 3 task lists up-to-date: bug reports by the beta testers and those posted in Tech Support. The third task list, emailed bug reports from customers, remains a couple of months out-of-date. Actual fixes for reported bugs were few in May. A couple odd items reported in Tech Support, and a few that I ran into playing NetPlay. None of these was very dramatic. All of them were rare occurrences and most of them could simply be ignored by clicking on the Continue button in the Mad Except bug report form.

I am playing MWIF 20+ hours a week against my “worthy opponent”, as I have been doing since the pandemic started back in the spring of last year. In our current game, we are up to Jul/Aug of 1944. Interestingly, the count for the Game Record Log (GRL) in our current game is over 19 million. Each time a player moves a unit, or makes some other decision in a NetPlay game, the program generates another GRL, which it sends to the other computer. There are also a lot of GRLs generated by the program doing internal stuff. For instance, at the start of a new year, the program moves new units into the Force Pools for the major powers to build. Then there are the GRLs for each phase of the game (60+), for each subphase of naval combat (25+), each subphase of land combat resolution, air-to-air combat, etc.

My point here is that the program has successfully generated over 19 million GRLs in our current game and sent them over the internet. This is the primary reason I feel confident in stating that the NetPlay code is now solid. Of course a few glitches occur from time to time, but those can easily be corrected by going back and restoring a recently saved game. More often we do that because one of us forgot to do something: “Argh, I meant to attack the partisan unit too!”.

Missing Optional Rules & Half Map Scenarios
I fixed a bug with setting up City Based Volunteers when their arrival hex is fully stacked. They now can be placed in an adjacent hex, if playing with the optional rule Off City Reinforcements. If not using that optional rule, they are moved to arrive next turn.

AI Opponent (AIO)
I split the monolithic LAIO (Language for the Artifical Intelligence Opponent) setup script for the USSR for Barbarossa into 3 parts: for setting up air and land units and later for placing the reserve units on the map. The naval unit setups are fixed in Leningrad and Sevastopol. Having the variable scripts in 3 small pieces makes them easier to manage. Edits no longer require searching through the entire mass of LAIO code.

Another task accomplished was using the Combat Value code I wrote earlier this year to select which of the setup air units are placed on the map and which go into the Reserve Pool (or back into the Force Pool when not playing with the optional rule Pilots). The air units with the highest CV are selected for placement on the map.

Below is the current script for setting up the USSR Barbarossa air units. The screenshot is for USSRAir1 - note that the specific air units will vary depending on the randomness of the units drawn for setup.

// Use a random number to choose air units' deployment.
RandomNum = GetRandomNumber(1, 100)
IF RandomNum < 65 THEN
Setup=USSRAir1
ELSE IF RandomNum < 75 THEN
Setup=USSRAir2
ELSE IF RandomNum < 85 THEN
Setup=USSRAir3
ELSE IF RandomNum < 95 THEN
Setup=USSRAir4
ELSE Setup=USSRAir5
// *********************************************************************************
// Setups for USSR air units.
// 'F2 4/4', 'L2 1/1', 'L3 3/1', 'L4 1/1'
// F2, choose 4 out of 8; L2, choose 1 out of 2; L3, choose 3 out of 4; L4, choose 1 out of 2.
// USSR has 9 pilots: 4 FTR2, Ranges 3, 4, and 5; Air2Air 3, 4, 5
// 1 TAC2, Ranges of 3 and 5; Tac 2, 3, 2Arm
// 3 TAC3, Ranges of 5, 7, plus 5 and 11 extended; Tac 2, 3, 4
// 1 TAC4 Ranges of 11 and 17; Tac 3, 4
// It is possible to assign 2 units to a city.
// *********************************************************************************
[Setup USSRAir1]
1 FTR2, (44,53) // W of Vitebsk
1 FTR2, (52, 58) // E of Kiev
1 FTR2, (46, 54) // SS of Vitebsk
1 FTR2, (40,52) // NE of Pskov
1 TAC2, (39, 52) // SS of Leningrad
1 TAC3, (43, 54) // NE of Vitebsk
1 TAC3, (50, 57) // NN of Kiev
1 TAC3, (47, 54) // EEE of Minsk
1 TAC4, (49, 57) // SE of Gomel
[Setup USSRAir2]
1 FTR2, (44,53) // W of Vitebsk
1 FTR2, (52, 58) // E of Kiev
1 FTR2, (40,52) // NE of Pskov
1 FTR2, (55, 59) // Dnepropetrovsk
1 TAC2, (55, 61) // Stalino
1 TAC3, (43, 54) // NE of Vitebsk
1 TAC3, (51, 55) // WNW of Kiev
1 TAC3, (39, 52) // SS of Leningrad
1 TAC4, (46, 58) // ESE of Smolensk
[Setup USSRAir3]
1 FTR2, (46, 54) // SS of Vitebsk
1 FTR2, (41,53) // EE of Pskov
1 FTR2, (55, 59) // Dnepropetrovsk
1 FTR2, (50, 57) // NN of Kiev
1 TAC2, (44, 56) // NW of Smolensk
1 TAC3, (43, 54) // NE of Vitebsk
1 TAC3, (51, 55) // WNW of Kiev
1 TAC3, (47, 54) // EEE of Minsk
1 TAC4, (53, 62) // E of Kharkov
[Setup USSRAir4]
1 FTR2, (46, 54) // SS of Vitebsk
1 FTR2, (52, 58) // E of Kiev
1 FTR2, (41,53) // EE of Pskov
1 FTR2, (55, 59) // Dnepropetrovsk
1 TAC2, (39, 52) // SS of Leningrad
1 TAC3, (47, 54) // EEE of Minsk
1 TAC3, (51, 55) // WNW of Kiev
1 TAC3, (54, 59) // NW of Dnepropetrovsk
1 TAC4, (49, 57) // SE of Gomel
[Setup USSRAir5]
1 FTR2, (44,53) // W of Vitebsk
1 FTR2, (50, 57) // NN of Kiev
1 FTR2, (52, 58) // E of Kiev
1 FTR2, (46, 54) // SS of Vitebsk
1 TAC2, (44, 56) // NW of Smolensk
1 TAC3, (43, 54) // NE of Vitebsk
1 TAC3, (39, 52) // SS of Leningrad
1 TAC3, (55, 59) // Dnepropetrovsk
1 TAC4, (46, 58) // ESE of Smolensk

[Shannon V. OKeets]

July 7, 2021 Status Report for Matrix Games’ MWIF Forum

Product Releases
No new Hot Patches last month. The beta testers got 3 new versions to test. I need to check in on things with the beta tester posts and the Tech Support posts. Once I give those a once over, I’ll put together a new hot patch - but don’t expect anything dramatic.

Most of my time is spent on the AI Opponent code internals - see below.

Bugs
Nothing new in June.

Missing Optional Rules & Half Map Scenarios
Nothing new in June.

AI Opponent (AIO)
If the AIO wants to move a unit to a city, it first has to define a variable in the script for city type. It does that with the line in script: CitTyp: TCityTypes. When the parser reads this line, it records CitTyp as an enumerated variable of the type ‘etCityTypes’. The script can then store the city type of a hex in that variable. To determine whether the hex contains a city, CitTyp can be tested against the 4 possible MWIF city types: (cyNone, cyCity, cyMinorCapital, cyMajorCapital).

For example, suppose the AIO wants to move a Russian unit in the Ukraine out of a clear hex and east, into a city hex where it cannot be overrun - and where it will always be in supply. The program examines each hex that the unit can reach in the current impulse, taking into account weather, terrain, and enemy zones of control. It also has to tentatively consider hexes that cannot presently be entered because that would cause overstacking. Then the program can set CitTyp equal to the city type of the potential destination hex. If CitType equals cyCity, cyMinorCapital, or cyMajorCapital, then the program can record the potential destination as having a city. Human players do this with a glance at the map. But the AIO is similar to a blind person playing the game. It has to laboriously check hexes one by one.

The full list of enumerated types for LAIO is:
(etTerrainTypes, etHexsideTerrainTypes, etCityTypes, etPortTypes, etSingleFactoryTypes, etFactoryTypes, etWeatherZones, etWeatherTypes, etSeaWeatherTypes, etSides, etUnitType, etSetupAirUnitType, etForcePool, etGearingType, etSupplyTypes, etTurn, etPhase, etReinforceSubPhase, etDigression, etAirSubPhase, etDOWSubPhase, etNavalCombatSubPhase, etLandCombatResSubPhase, etVichySubPhase, etQuality, etInitBonus).

Besides enumerated types, LAIO also supports the usual integer and real variables. But there are numerous other MWIF specific variable types available to the author of a LAIO script; for example, hexes, units, unit stacks, land regions, theaters of operation, etc.

Looking at the script I posted last month, you can see references to the enumerated list etSetupAirUnitType for the air units being placed on the map.

[Setup USSRAir1]
FTR2, (44,53) // W of Vitebsk
FTR2, (52, 58) // E of Kiev
FTR2, (46, 54) // SS of Vitebsk
FTR2, (40,52) // NE of Pskov
TAC2, (39, 52) // SS of Leningrad
TAC3, (43, 54) // NE of Vitebsk
TAC3, (50, 57) // NN of Kiev
TAC3, (47, 54) // EEE of Minsk
TAC4, (49, 57) // SE of Gomel

I spend my time on the AIO code switching between a broad overview of the code (e.g., all enumerated types) and specific instances I need to get working for the USSR Air Unit Setup script (e.g., FTR2). Each of the enumerated lists has over a hundred lines of code to process a variable.

[Shannon V. OKeets]

August 6, 2021 Status Report for Matrix Games’ MWIF Forum

Product Releases
I took 3 weeks off in July. It had been over two years since my last vacation. Starting in August I got back in harness.

Bugs
I fixed a half dozen bugs that were reported in the Tech Support forum.

Missing Optional Rules & Half Map Scenarios
Nothing new in July.

AI Opponent (AIO)
Nothing new in July.

[Shannon V. OKeets]

September 10, 2021 Status Report for Matrix Games’ MWIF Forum

Product Releases
Release version 04 02 03 02 was posted as a Hot Patch in August. I’m working on the next Hot Patch (version 04 02 03 04) with the expectation of making it available in mid-September. First it needs to undergo some testing by the beta testers.

If all goes well, we hope to make it available as a public beta, with the goal of replacing the current official update version of the program in mid-October.

Bugs
I fixed a various dozen bugs that were reported in the Tech Support forum.

Missing Optional Rules & Half Map Scenarios
Nothing new in August. Although some of the bug fixes were for optional rules that were recently added.

AI Opponent (AIO)
Nothing new in August, other than my rereading some of the code so I can resume work on the AI Opponent parser of the setup scripts for the USSR in Barbarossa.

[Shannon V. OKeets]

October 5, 2021 Status Report for Matrix Games’ MWIF Forum

Product Releases
Release version 04 03 00 00 was posted as a Hot Patch in early October. Unless problems are reported for this version, we will make it available as a public beta, with the goal of replacing the current official update version of the program in late October.

Bugs
I fixed a dozen various bugs that were reported in the Tech Support forum. The most important was correcting the number of movement points remaining available to a group of naval units after an interception attempt by enemy units.

Missing Optional Rules & Half Map Scenarios
Nothing new in September.

AI Opponent (AIO)
Most of my time on the AIO was spent reducing my tome on coding the AI Opponent from 77 pages down to 44 pages. The smaller file is for coding the AIO decisions for the USSR in the Barbarossa scenario. Below is a segment of that which describes the AI Opponent’s view of the scenario’s geography with a breakdown of the AIO “decision makers” for each geographic area.

I decided to not display the attached graphic of the map in the forum since it is so large. However, you can download the JPG file and examine it at your leisure.

==============================================================

III. Geographic BreakDown
For both the USSR and Germany there are 3 decision makers at the highest level: Joints Chiefs of Staff (JCS), Air Force General Staff (AFGS), and Army General Staff (AGS). Both have an Air Marshal (AM) and a Field Marshal (FM), as well as an Air Fleet Commander (AFC) and an Army Group Commander (AGC) for each AO. The AFC makes strategic bombing decisions. Other operations for air units are under the control of the AGC. Each Land Region (LR) is under the control of a Commanding General (CG) for each major power.

3.1 Theaters of Operations
There is one primary Theater of Operations in Barbarossa with a small portion of a second.
• Eastern Europe (EE, #5)
• Western Europe (WE #3)

3.2 Areas of Operations (x) => not in USSR Barbarossa
The Barbarossa scenario uses only one Area of Operations (Greater Germany AO #22) in Western Europe and within that AO just two land regions (Northern Germany LR #51 and Austria/Czechoslovakia LR #53). The first of these land regions includes East Prussia and the Danzig corridor through Poland, connecting East Prussia to the rest of Germany. The second land region contains the Czechoslovakian hexes that abut Eastern Poland.

Within the Eastern Europe TO there are 9 Areas of Operations - only 7 are used in Barbarossa. The land regions (LRs) for these AOs are given below:
• Sweden (#34) (x)
• Finland/Northern Russia (#35) with land regions:
Northern Finland/Norway (#88)
Southern Finland (89#)
Murmansk (#90)
Archangel (x)
DNE (Do Not Enter) Arctic (x)
• Poland/Baltic (#36) with land regions:
Estonia, with north eastern Latvia (#93)
Lithuania, with south western Latvia (#94)
Western Poland (#95)
Eastern Poland (#96)
• Balkans (#37) with land regions:
Hungary (#97)
Rumania (99#)
Yugoslavia (x)
Bulgaria (x)
• Central Western USSR (#38) with land regions:
Leningrad (#101)
Vitebsk (#102)
Smolensk (#103)
• Southwestern USSR (#39) with land regions:
Kiev (#104)
Kharkov (#105)
Crimea (#106)
• Central European USSR (#40) with land regions:
Vologda (#107)
Moscow (#108)
Voronezh (#109)
• Southeastern European USSR (#41) with land regions:
Rostov (#110)
Stalingrad (#111)
Caucasus (#112)
• Turkey (#42) (x)

3.3 Sea Area Groups (SAGs) (x)

3.4 Land Regions
Lands regions dominate game play decisions and most tactical decision making.

3.5 Sea Areas (x)

See the attached map graphic for a break down of individual hexes in each land region.

[Shannon V. OKeets]

November 14, 2021 Status Report for Matrix Games’ MWIF Forum

This is the latest I’ve ever been with a monthly status report - sorry. I had to buy a new car in the beginning of the month which wasn’t easy to do.

Product Releases
Release version 04.03.01.00 was posted as a Hot Patch in mid November. That version fixes some problems were reported in October’s hot patch (version 04.03.00.00). Hopefully we can make it available as a public beta later in November with the goal of replacing the current official update version before December.

Bugs
Aside from the couple of bugs fixed for newly created problems with 04.03.00.00, I didn’t work on other bugs in October. The troubles with the NEI oil to Japan was one of the two major bugs that got fixed.

Adding a new section of code expressly for sending NEI oil resources to Japan (and the Commonwealth) took a lot of time. That decision was made after me fumbling around trying to patch the existing code where satisfying all the trade agreements was being done in one large complex mess of code. The NEI oil trade agreements are now processed in a manner similar to the processing of the US to Japan trade agreement. That is, they are performed before and separate from assigning resources to fulfill other trade agreements.

Missing Optional Rules & Half Map Scenarios
Nothing new in October.

AI Opponent (AIO)
Continuing development of the AI Opponent for playing the USSR in the Barbarossa scenario, I worked on the branching logic. At every point in the sequence of play where the program asks a player to made a decision, I have to add new code to branch to AI Opponent routines if the decision maker is the AIO. There are over 100 of these points in the sequence of play. Most of them involve presenting a form to the player/decision maker, and the rest are where the player is moving units around on the map.

Those involving forms are easiest to find, since I just look for the places in the code where a form is displayed - if it also requires the player to make a choice. When the decision maker is the AIO, the form is not displayed. Instead the code branches to an AI decision maker routine to set the requisite variable values comparable to what a human player accomplishes by selecting buttons, etc.

So far I have inserted branching logic in 80+ places in the code for the AIO making decisions. These code changes have no effect on the other modes of play (e.g., Solitaire, NetPlay) since in all cases the branching logic first checks for the AIGame variable being True. The couple dozen remaining places where I need to insert code are for the subphases of land combat and air-to-air combat, plus all the digression decisions. I should be able to finish that task next week.

Of course, once all the branching logic has been coded, then I need to add code for the AIO to actually make reasonable decisions. I’ve done a few of those (e.g., the USSR always chooses a Land action in Barbarossa). But there are over a 100 that need to be finished. Note that for the AIO playing the USSR in Barbarossa, there are never any decisions involving naval units. The AIO is simply going to ignore the naval units in that scenario.

[Shannon V. OKeets]

December 16, 2021 Status Report for Matrix Games’ MWIF Forum

Product Releases
Release version 04.04.00.00 was posted as a Hot Patch in late November. That version was followed by
Hot Patch 04.04.00.01 in early December. A public beta (version 04.04.01.00) will be made available some time before Christmas.

This is a short monthly report (late as usual). However, I have written a four page year end summary which I will post January 1st 2022.

Bugs
Aside from the couple of minor items, I didn’t work on bugs in November. Instead I focused on the AI Opponent code.

Missing Optional Rules & Half Map Scenarios
Nothing new in November.

AI Opponent (AIO)
I created a detailed project plan, with schedule, for completing the AI Opponent playing the USSR in the Barbarossa scenario. In November the actual code changes continued to be on the branching logic. By early December, I finished inserting all the branching logic.

Then I moved on to writing the decision making logic for “hard coded” decisions. These include: going first (always), asking for a reroll (always), and port attack decisions. Once I finish the hard coded decisions (4 remain to be done) and what to do with surprise points (3 remain to be done), I’ll return to writing the code for the parser so scripts written in LAIO (Language for the AI Opponent) can be processed.

[Shannon V. OKeets]

Note that there are two attachments. One is in this post and the second is on the next post.


World in Flames Progress in 2021

Product Releases

In 2021, product development was exclusively focused on making changes to the World in Flames executable code. Auxiliary tasks, involving data files and documentation, were completed over a decade ago. All changes to data and text in 2021 were cosmetic (e.g., spelling corrections). Presently the World in Flames source code is more than 508,000 lines, not including the 4 auxiliary libraries.

Code changes go through a 5 step sequence (in order):
1. Alpha testing (done by the programmer).
2. Beta testing done by the beta testers.
3. Hot patches, posted to the World in Flames forum. These are usually just a replacement of the executable (MWIF.exe).
4. Public betas, made available in the Slitherine/Matrix Games World in Flames members site. A public beta contains the complete World in Flames product and is available as a download for customers.
5. Master updates, accessible by all owners of the game using the Update button on the opening World in Flames screen. Each master update contains the complete World in Flames product and is what a customer receives when he purchases the game as a digital download file. It’s also what the customer receives on the Player Manuals insert disk when he purchases a physical copy of the game.

Master Updates for Customers
No master updates were created in 2021. Release version 4.4.1.0 is expected to be a new master update in January 2022.

Public Betas for World in Flames Members
Version 4.4.0.0 in early December.

Hot Patches for World in Flames Forum Members
Five new Hot Patches were posted to the World in Flames forum: versions 4.2.2.0, 4.2.3.2, 4.3.0.0, 4.3.1.0, and 4.4.1.0.

Beta Testers Private FTP Site
Forty-two new versions were uploaded to the beta tester FTP site for beta testing:
4.2.1.: 7, 8 and 9
4.2.2.: 1/2/3/4/5/6/7/9/10/11/12/13
4.2.3.: 0/1/3/5/7
4.3.0.: 1/3/5/7/9
4.3.1.: 1/3/5/7
4.4.0.: 1/3

As indicated by the above counts, roughly 4 new versions were made available to the beta testers/customers each month. There is a time lag of a week or two following a version being made available to the beta testers, before a comparable version is posted as a hot patch for the customers. That allows the beta testers to put the new version through its paces, checking to see that changes perform as expected. Public betas receive even more testing. While in past years we were posting two or three new public betas per year, in 2021 the work on the AI Opponent code reduced the time available for adding optional rules and investigating bugs.

Writing Code

Code changes can be broadly broken into four activities:
1 Adding the half map scenarios and optional rules.
2 NetPlay mode of play.
3 Fixing reported bugs.
4 AI Opponent mode of play.

Half Map Scenarios

World in Flames contains 11 scenarios. 9 of those were included in the original release of the product - November 2013. The 2 missing scenarios are the half map scenarios. While most of the work to complete these has been done, the rules involving the Transfer Pool, where naval units belonging to both sides are “off map” and capable of engaging in combat there, present major coding difficulties. Crucial rule systems (for example, the sequence of play for resolving a naval combat) need to be extensively revised before these scenarios will be playable.

Missing Optional Rules

There are 81 optional rules listed for MWIF. At the beginning of 2021, 57 of those had been coded. During 2021, 5 more optional rules were added to the game:
V-weapons,
A Bombs,
City Based Volunteers
Isolated Reorganization Limits
Kamikazes

Work on adding more optional rules was halted in the spring of 2021, to focus on the AI Opponent mode of play. Nine optional rules currently remain on the list to be coded, with the priorities shown below based on feedback from customers and beta testers:
1. Flying Bombs
2. USSR Japan Compulsory Peace
3. Guards Banner Armies
4. Naval Supply Units
5. Limited Aircraft Interception
6. Hitler’s War
7. Partisan HQs
8. Recruitment Limits
9. Rough Seas

Three other optional rules may be worth the effort to code, but it isn’t clear that players would ever use them (based on feedback from existing customers):
• Ukraine - very expensive for a player to create with marginal benefit.
• Japanese Command Conflict - makes Japanese production very difficult.
• Convoys In Flames - numerous details including new unit types and additional naval combat subphases need to be added..

The last seven optional rules have been set aside for various reasons:
• Frogmen - negligible effect on game play.
• Surprised ZOCs - too dramatic an effect on game play.
• Bounce Combat - too difficult to code, especially for NetPlay.
• Enroute Interception - too difficult to code.
• Oil Tankers - would make routing resources even more difficult.
• Naval Offensive Chit - too difficult to code (additional die rerolls), especially for NetPlay.
• Intelligence - too difficult (almost impossible) to code.

As an example of how a new optional rule gets added, Isolated Reorganization Limits at first generated extremely long calculation times (minutes) for determining supply. Supply needs to be frequently recalculated during land movement. For instance, when Germany invades the USSR, changes in hex control and supply lines force supply to be recalculated.

The time to recalculate supply has to be kept to under 5 seconds in the worst cases and to less that a tenth of a second for normal land movement. To achieve those goals, the distance to a supply source for isolated units was changed from unlimited to a maximum path of 10 hexes. This eliminated repetitious, long, and useless search times through the width and breadth of the USSR and Africa.

NetPlay

I have been playing MWIF using NetPlay for the past 5 years. On average, I play between 15 and 20 hours a week. This constitutes ‘alpha’ testing. As bugs are discovered, I work on fixing them. My 6 opponents have been from around the world: Australia, the United States, Canada, and Spain.

NetPlay, with a Skype connection between the two players, enables the game to be played as if the players were in the same room and playing over the board. Actually it is much better than playing over the board. Here are some examples of how MWIF is easier to play than playing over the board:
1. MWIF enforces the rules, avoiding tedious discussions about what is and what isn’t permitted.
2. MWIF automatically advances the game correctly through the sequence of play.
3. MWIF performs all calculations for all types of combat.
4. MWIF determines supply for all units.
5. MWIF identifies and displays a selectable list of air units that can move in each phase/subhase of air missions.
6. MWIF identifies and displays a selectable list of HQs, air units, and naval units that can reorganize units during the final reorganization phase.
7. MWIF finds all the disorganized units that need oil to be reorganized and corresponding available sources of oil during the use oil phase..

Most recently I have been playing against an old friend in Philadelphia - in mid-October we started our seventh NetPlay game. In October this year, we finished our sixth NetPlay game - all 36 turns of Global War - which took us just under 4 months real time. That game generated 27,679,321 Game Record Logs (GRLs). A GRL is generated each time a player makes a decision (e.g., moves a unit). These are sent over the internet from one player’s computer to the other player’s computer, using the Slitherine/Matrix Games Private NetPlay Server. The GRLs synchronize the two computers’ game data, so the game state displayed to both players is identical.

My point here is that in our last game, MWIF successfully generated, sent, and received over 27 million GRLs over the internet. I feel confident in stating that the NetPlay code is now solid.

The NetPlay mode of play is limited to two players. But customers have devised ways to have more than 2 players play MWIF remotely, typically having 4 players involved. They accomplish this by using the MWIF solitaire mode of play and sending saved game files back and forth to all the players. When quick decisions have to be made, they use various internet communication methods.

The most popular method for quick replies appears to be the Slitherine/Matrix forum. The person currently ‘in charge’ of the game makes the decisions and moves units for his side, consulting his allies. If a decision is needed by the other side (“Are you intercepting the moving naval units?”), he posts a query to the forum and receives an instant reply, which he implements on the copy of the game he is running. The person “in charge” is the team leader for the phasing side. When the phasing side changes, so does the person “in charge”. Customers have been using this system for over 6 years with some of the opposing groups on their fourth (or more) game.

Reported Bugs

There are three sources of reported bugs: (1) the World in Flames forum (mostly reported in the Tech Support sub-forum), (2) beta testers, and (3) emailed bug reports (Mad Except errors). The last are generated automatically by the World in Flames program when the Windows operating system generates a program exception. Those bug reports are sent to Slitherine/Matrix Games, which forwards them to me.

Bug reports are mostly spurious. Only about 20% are actually reports of the program behaving badly. The others are players not understanding the rules or running old versions of the code and encountering bugs that have been fixed years ago. Simply explaining the MWIF rules ‘solves’ the former difficulties, and having the player update their version of the program solves the latter.

For fixing ‘real’ bugs, an average of a half dozen or so code changes are made each month. Of those bugs, many were caused by recent changes to code, such as by adding optional rules. Then there are the situations which occur very rarely. Some of those are so rare, they are simply ignored. But most are dealt with by modifying the code. Two of the more bothersome bugs that were fixed in 2021, and which took a lot of programming effort, were in the search routines: (1) determining which units are in supply, and (2) sending NEI oil resources as part of a trade agreement. In both cases the problem was the amount of time it took the program to perform the calculations - in unusual circumstance. These are discussed below.

Supply

My estimate is that supply works correctly 99.99% of the time, which means that when I go through the code trying to fix a supply bug, 99.99% of the code is correct. The trick is to ‘see’ the lines that are imperfect in the midst of all the correct code. To accomplish that I add hundreds of debug statements and then step through the code line by line until I find something that yields an incorrect result. All told, there are 20,000+ lines of code for calculating supply in MWIF.

To figure out problems in supply, I added dozens of timing snapshots. There are 23 steps to calculate supply for all the units on the map. First is identifying the primary supply sources for each country. Then the possible secondary sources are tested to see which ones can trace a path to a primary. That requires several steps since it’s best if a secondary can trace to a primary controlled by the same major power. Overland and overseas paths require the work to be done twice. Cooperating major powers, aligned minor countries, HQs functioning as primary supply sources for the impulse and turn, all add to the complexity.

Using the timing data, I was able to identify which major powers were taking a long time to find supply paths. Next I inserted more finely tuned timing snapshots to see if the problem was with individual secondary supply sources, and if overseas routes were the guilty parties. In a few instances, fixing one bug solved others. But that was unusual. My last set of fixes for supply were quite successful in reducing the time required to recalculate supply even under the most adverse circumstances.

NEI Trade Agreements

Satisfying trade agreements necessitates searching the map for available resources and then finding paths to possible destinations. If an overland path can be found, it is found quickly. Overseas path are more complex since there can be multiple demands on convoy pipelines to satisfy different trade agreements. Also limiting what resource can go to which major power and destination are special rules. The US Entry Options impose a dozen or so such restrictions. As US Entry options are chosen, resources and paths that were viable in a previous turn can become invalid - or vice-versa.

It wasn’t easy to have the program correctly resolve dozens of trade agreements, while satisfying the rules and letting players prioritize what goes where and control what happens to the resource when it arrives at its destination (e.g., save an oil point or use it in production). The NEI oil resources were particularly hard to get correct. This year I added a new section of code expressly for sending NEI oil resources to Japan (and the Commonwealth). That decision was made after numerous attempts trying to patch the existing code where satisfying all trade agreements was being done in a single mass of code.

The NEI oil trade agreements are now processed in a manner similar to the processing of the US to Japan trade agreement. That is, they are performed before and separate from assigning resources to fulfill other trade agreements. A side benefit of this separation was that satisfying the remaining trade agreements was simplified.

AI Opponent (AIO)

AI Opponent Design

Back in 2013 I assembled all my ideas for the AI Opponent design into a single tome. After reviewing it this year I brought it up-to-date, made it internally consistent (e.g., names and cross-references), and reduced it to 77 pages. For the AI Opponent playing the USSR in Barbarossa, I stripped away unnecessary sections and got it down to 44 pages. That reduction was possible since the USSR makes no declarations of war, alignments of minor countries, or cooperative decisions with other major powers. Also eliminated were all the decisions about naval operations. Basically, the AI Opponent for the USSR in Barbarossa ignores all naval units.

The design for the AIO consists of several parts:
1. Map - Geographic Breakdown
2. Decision makers’ task lists
3. Predefined decisions
4. Language for the AI Opponent (LAIO) scripts

Map - Geographic Breakdown

From the AIO’s point of view, the game map is broken down into Theaters of Operations, which are comprised of Sea Area Groups and Areas of Operation. Each Sea Area Group contains a set of specific sea areas. Each Area of Operation is broken down into Land Regions, which contain individual land hexes.

Thus, every all-sea hex on the map is in a sea area, which is in a sea area group, which is in a theater of operations. Similarly, every land hex on the map is in a land region, which is in an area of operations, which is in a theater of operations. Lands regions dominate AIO decision making, especially tactical decisions.

Theaters of Operations (TO)

There is one primary Theater of Operations in Barbarossa with a small portion of a second.
• Eastern Europe
• Western Europe

Sea Area Groups (SAG)

The USSR in Barbarossa does not need to reference sea area groups or sea areas.

Areas of Operations (AO)

The Barbarossa scenario uses one Area of Operations in Western Europe (Greater Germany) and within that AO just two land regions (Northern Germany and Austria/Czechoslovakia). Northern Germany includes East Prussia and the Danzig corridor through Poland, connecting East Prussia to the rest of Germany. Austria/Czechoslovakia contains the Czechoslovakian hexes that abut Eastern Poland. For the most part, the Western Europe TO is of minimal concern to the USSR.

Within the Eastern Europe TO there are 7 Areas of Operations used in Barbarossa. The land regions for these AOs are given below:
• AO Finland/Northern Russia with land regions:
Northern Finland/Norway
Southern Finland
Murmansk
• AO Poland/Baltic with land regions:
Estonia, with north eastern Latvia
Lithuania, with south western Latvia
Western Poland
Eastern Poland
• AO Balkans with land regions:
Hungary
Rumania
• AO Central Western USSR with land regions:
Leningrad
Vitebsk
Smolensk
• AO Southwestern USSR with land regions:
Kiev
Kharkov
Crimea
• AO Central European USSR with land regions:
Vologda
Moscow
Voronezh
• AO Southeastern European USSR with land regions:
Rostov
Stalingrad
Caucasus

See the attached map graphic for a break down of individual hexes in each land region. For the World in Flames European map, the data identifying which land hex belongs to which land region and the hierarchy of the TOs, AOs, SAGs, and LRs was completed over 4 years ago.

Decision Makers

Rather than use a single monolithic algorithm, the design for AIO splits decision making tasks into groups, by branch of service and geography. To facilitate thinking and analysis, the groups are labeled as Decision Makers (DMs). Each DM has an assigned list of decisions for which it is responsible. In essence, a DM is equivalent to a list of decisions.

The AIO has 6 global Decision Makers for each major power, and 11 other decision makers for TOs, AOs, SAGs, and LRs. Conceptually these are all the same. Each DM has a jurisdiction either by role and/or geography, a superior to whom they report (except for the Grand Strategist), and subordinates to whom they give assignments/ At the lowest level are combat units.

DMs assess the current game position within their defined area of control and report that assessment to their superior. Accumulated information is sent from the bottom of the hierarchy to the top. Then ‘assignments’ are sent from the top to the bottom. When making complex decisions, DMs run through a set of ‘rules’ to evaluate the risk and reward for each decision choice.

The highest level decision makers are:
• Grand Strategist
• Commander in Chief [not needed in Barbarossa]
• Foreign Liaison [not needed in Barbarossa]
• Manufacturing Council
• Joint Chiefs of Staff
• Special Operations (e.g., paradrops).

The hierarchy for the Army, with designated geographic responsibility is:
1. Army General Staff - global, reports to the JCS
2. Field Marshal - TO
3. Army Group Commander - AO
4. Commanding General - LR

The hierarchy for the Navy, with designated geographic responsibility is:
1. Admiralty - global, reports to the JCS
2. Rear Admiral - TO
3. Sea Area Commander - SAG
4. Fleet Admiral - SA

The hierarchy for the Air Force, with designated geographic responsibility is:
1. Air Force General Staff - global, reports to the JCS
2. Air Marshal - TO
3. Air Fleet Commander - AO

Within the code, the AIO logic branches to the appropriate decision maker for each decision. For example, when deciding which air unit in an air-to-air combat suffers an adverse result, the Air Fleet Commander decides (AFC decision #4). That’s because his frame of reference is the AO and he wants to optimize the next round of the air-to-air combat. If the result is a forced abort for a friendly air unit, then the Air Marshal (AM decision #2) decides where the air unit returns to base, since he might want to redeploy the air unit elsewhere in the TO, possibly outside the AFC’s AO. The attached spreadsheet identifies the decision maker for each decision the AIO makes.

Task List (see attached spreadsheet)

The spreadsheet lists the full sequence of play in the leftmost column. The second column shows the relevant section in the rules. The third column identifies who makes the decision. Sometimes it is made without input from the player (e.g., the end of turn die roll). In the fourth column is a short description of the task/decision, followed by the fifth column with an assigned task number. The remaining columns show how the AIO makes the decision, both as text and as a DM’s task number. The last two columns display current progress and status.

At every point in the sequence of play where the program asks a player to made a decision, there needs to be code to branch to an AI Opponent routine - when the decision maker is the AIO. There are 100+ of these points in the sequence of play. Most of them involve presenting a form to the player and the rest are where the player moves units on the map.

When the decision maker is the AIO, the form is not displayed. Instead the code branches to an AI decision maker routine to set the requisite variable values comparable to what a human player accomplishes by clicking on buttons, etc. For moving units on the map, the AIO primarily uses LAIO scripts, which are described in a following section.

All the branching logic for the AIO making decisions has been written. These code changes had no effect on the other modes of play (e.g., Solitaire, NetPlay) since in all cases the branching logic starts by checking for the mode of play being AI Opponent.

Of course, once all the branching logic has been coded, then more code needs to be added for the AIO to actually make reasonable decisions. Some of those have already been done (e.g., the USSR always chooses a Land action in Barbarossa). But there are almost 100 more that need to be finished. Note that for the AIO playing the USSR in Barbarossa, there are never any decisions involving naval units. The AIO simply ignores naval units in that scenario.

Predefined Decisions

Some of the easiest decisions for the AIO to make use predefined files. These are hard coded: a starting scrap list, original setup locations for naval units, and which air units at setup are assigned pilots. All of these predefined files have been created and fully tested.

LAIO Scripts

Rather than “hard code” how the AIO makes most decisions, I created a language in which ‘authors’ could write scripts that control AIO decisions. The language is LAIO (Language for the Artificial Intelligence Opponent). In 2008 I had LAIO defined for MWIF. Like other programming languages it has variables, branching logic, loops, functions, and procedures. The advantage of this structure is that a script can be modified using a simple text editor without having to revise the MWIF executable. In practice, this means different ideas for how the AIO makes decisions can be quickly evaluated in a diverse range of game positions.

To make LAIO work, the program needed a parser, which reads in a LAIO script and transforms it into variables, branching logic, etc. for use by the AIO Decision Makers (DMs). The parser is 90% complete and needs only a week to be finished. For complex decisions, a DM reads in and executes a LAIO script. The first place this is done is for setting up the USSR air and land units on the map. Those scripts have been written and are in testing. So is the script for setting up the reserve units when Germany declares war on the USSR.

Of crucial importance is the use of randomly generated numbers to vary how the AIO decides what to do. Sometimes it will do A, sometimes B, sometimes C, and so on. Keeping the AIO’s behavior variable prevents a human opponent from knowing for certain what the AIO will do. Using scripts, the AIO can easily branch to different processes to make a decision.

Having the AIO play the USSR in the Barbarossa scenario means being able to assign a combat value (CV) to each unit. My design for the AIO has CVs at its heart. They determine which air units should be assigned pilots. When a combat loss has to be taken, they determine which unit lives and which dies. Then they are also an integral part of the logic for deciding which units to build. The places where a unit’s CV is referenced is extensive. Calculating a CV for every unit type has been coded.

[Shannon V. OKeets]

Second attachment for the end of year status report.

[Shannon V. OKeets]

February 10, 2022 Status Report for Matrix Games’ MWIF Forum

Product Releases
A public beta (version 04.04.01.00) was made available in late January.

Bugs
I did almost no work on bugs in January. Perhaps I made a few cosmetic changes to form layouts.

Missing Optional Rules & Half Map Scenarios
Nothing new in January.

AI Opponent (AIO)
I completed the parser for decoding the LAIO scripts (which are simple ASCII files) into Delphi data structures. Most of these are now being ‘echoed’ back to the screen so I can check that the data structures correctly reflect the intent of the script. Once I have completed the code for echoing the data structures, I’ll move on to the third task for processing LAIO scripts. That is, to execute them for the game state changes in accordance to the script ‘instructions’.

Attached is a screen shot of the form I use when testing LAIO scripts. As each button on the left is executed, the echo of the decoded script appears in the two panels on the right. Which panel receives the next ‘echo’ alternates, so the before and after echos are always visible.

For the screenshot, I have merged several screenshots. The first 6 buttons on the left generate the 6 distinct panels shown.

[Shannon V. OKeets]

March 20, 2022 Status Report for Matrix Games’ MWIF Forum

Product Releases
Nothing new in February,

I have drifted into posting the monthly status report in the middle of the month instead of at the beginning. That will be true for April as well. Mostly that’s because I will be leaving for 3 weeks in Paris on Aril 19th and won’t be back home until May 9th. Then I’ll skip a month and start up again with a monthly status report for May/June on July 1st, or thereabouts.

Bugs
I did almost no work on bugs in February.

The only substantial change was to completely rewrite the code fulfilling the NEI Trade agreements. Rather than have those calculations part of the general routine to fulfill trade agreements, I removed all references to the NEI trade agreements from the normal processing and wrote a new routine that focuses on the 4 NEI oil resources that are the only resources which can be used for those trade agreements. It took a couple of passes but now it works correctly for both when the Netherlands is neutral, and after the Netherlands has been attacked (by Germany). A similar approach had been done for the US-Japan trade agreement more than 15 years ago.

Missing Optional Rules & Half Map Scenarios
Nothing new in February.

AI Opponent (AIO)
It took me a while but I now have the parser both decoding the LAIO scripts and echoing them back correctly, I am now working on the code to execute/process LAIO script so they make changes to the game state in accordance to the script ‘instructions’.

[Shannon V. OKeets]

April 19, 2022 Status Report for Matrix Games’ MWIF Forum

Product Releases
Nothing new in March,

I am leaving tonight for 3 weeks in Paris and won’t be back home until May 9th. Then I’ll skip posting a status report for a month and start up again with a monthly status report for May/June on June 1st, or thereabouts.

Bugs
I did almost no work on bugs in March.

Missing Optional Rules & Half Map Scenarios
Nothing new in March.

AI Opponent (AIO)
The program is now executing LAIO scripts. So far I have the AIO setting up the USSR air units and reserve units for Barbarossa. I’m currently working on having it set up the land units. It was a real rush to see the air units appaer on the map in the correct (according to the script) hexes.

[Shannon V. OKeets]

June 5, 2022 Status Report for Matrix Games’ MWIF Forum

Product Releases
Nothing new in May.

After 2+ weeks in France, we arrived back in Honolulu rather jet-lagged. Because there’s a 12 hour differential, the time in Paris is the same as the time in Honolulu, you just change AM to PM.

Bugs
I did no work on bugs in May.

Missing Optional Rules & Half Map Scenarios
Nothing new in May.

AI Opponent (AIO)
The program is now executing LAIO scripts, setting up the USSR air units and reserve units for Barbarossa. I’m still working on having the AIO set up the land units for Barbarossa. The logic for the land units is more complicated.

At Peter’s suggestion we decided to designate several groups of hexes in different regions as ‘locations’. For example, the Lithuania High (priority) location contains the hexes (45,46) (45,48) (46,48) (46,49) (47,48). As we process the land units that are randomly drawn to be set up, some of them will be placed in some of these hexes. Which type of units and in which hexes is determined by branching logic based on random numbers.

Other locations are Lith Med(ium), Eastern Poland High/Med/Low, Rumania High/Med, and Kiev High/Med/Low.

Here are the land units that the USSR has available.
HQ: 5(2)2 and 6(3)2
Armor: 3 corps; 9-5 elite, 8-6, 7-6
Mechanized: 3 corps; 8-5 elite, 7-5, 6-5; 1 out of 2 div: 2-5, 2-6
Artillery/AA/AT: 5 out of 6 div; 4-2 Art, 4-3 Art, 3-2 AT, 2-3 Light AA, 3-2 Light AA, 3-2 Heavy AA
Special: 3 corps; 2-5 Cav, 3-5 Cav, 5-4 Mtn;
Special: 2 div: 1 out of 2 Eng: 1-3, 1-4; 1 out of 2 Ski: 2-3, 1-4
Garrison 6 corps: 3-1, 4-1, 4-1, 5-1, 6-1 elite, 7-1 elite
Infantry 9 out of 11 corps: 4-4, 5-3 x 4, 5-3 elite, 5-4, 6-3, 6-3 elite, 6-4, 7-3; 2 div: 1-4, 2-3
Motorized 3 out of 5 corps: 4-5, 5-4, 5-5, 6-4, 7-4

The 2 other infantry corps and 2 other motorized corps arrive as reinforcements.

The LAIO script goes through all the units that are available (about half are randomly drawn) and places them in hexes within the various locations. What is different in the script logic is the need to create lists of units, sort the lists, and then select units from each list. Getting the LAIO parser to recognize these ‘new’ types of instructions is my immediate task.

[Shannon V. OKeets]

July 16, 2022 Status Report for Matrix Games’ MWIF Forum

Product Releases
Nothing new in June.

Bugs
I did a little work on bugs in June. Specifically, I fixed some problems that were caused by my new code for the AI Opponent. A second item was to correct a bug in NetPlay for the Axis executing Search and Seizure.

Missing Optional Rules & Half Map Scenarios
Nothing new in June.

AI Opponent (AIO)
In addition to the program executing LAIO scripts to set up the USSR air units and reserve units for Barbarossa, I now have it placing the USSR HQ, Armor, Mech, Cavalry, and Mountain units on the map. Last in the list of units to be set up are the Infantry, Garrison, and Motorized units. We know the hexes where we want to place them. What remains is randomizing which units occupy which hexes.

[Shannon V. OKeets]

August 13, 2022 Status Report for Matrix Games’ MWIF Forum

Product Releases
Nothing new in July.

Bugs
Nothing new in July.

Missing Optional Rules & Half Map Scenarios
Nothing new in July.

AI Opponent (AIO)
I finished having the AI Opponent code set up the USSR units for Barbarossa. To simplify the process I split the units into 6 groups. Each group has 3 to 6 different locations where the group’s units are placed. Which location is used depends on a random number, so 6 random numbers are drawn to determine the overall placement of the units. The diversity of setups isn’t as large as I would like, but that is due to the setup restrictions on the USSR player. 10 corps need to be placed near the border of Prussia/West Poland and another 10 near the border with Bessarabia.

The AIO only plays the USSR side of Barbarossa using the Standard Optional Rules list. You can check out what those optional rules are using the Start a New Game form where one of the buttons for choosing the optional rules is labeled Standard Set.

My intention is to have the program automatically choose the scenario and optional rules as soon as the player selects the AIO mode of play. Additionally, I’ll have the program take the human player’s name from the registration file for the game. Ideally, once a player selects the AIO mode of play, the game will complete the Start a New Game form information, set up the USSR units, and then switch over to the human player choosing which German units to scrap, setting up the German units, and starting the first turn. Basically, the human player will jump into playing the first impulse as the German player.

Right now I am working on have the program transition to the Scrap Units phase for the German player. After I get the program smoothly transitioning to the German/human player making decisions, I’ll let the beta testers run the AIO code a bunch of times. What I would like to get back from them is a lot of saved games after the German player has moved all his units, made all his attacks, and advanced the game to the 2nd impulse, where the AIO needs to decide where to move its units, make attacks, etc. Those saved games will provide me with data on a range of situations the AIO might encounter when it needs to decide about moving units and making attacks (if any) in the second impulse.

Towards that end, I have outlined the process the AIO will use to assess a game position. That will identify in which front line Land Regions, (the map has been broken into Land Regions), the AIO should defend as is, reinforce, retreat, or attack. Adjacent land regions will ‘know’ whether they are to provide the front line land regions with reinforcements, or help prepare a new line of defense,

I’ve attached a screenshot of one of the setup positions the AIO has chosen/calculated for the USSR.

AIO Setup 1.jpg (1.73 MiB) Viewed 2823 times

[Shannon V. OKeets]

September 10, 2022 Status Report for Matrix Games’ MWIF Forum

Product Releases
Nothing new in August. I expect to release a new version to the beta testers later today,

Bugs
Nothing new in August.

Missing Optional Rules & Half Map Scenarios
Nothing new in August.

AI Opponent (AIO)
As soon as the player selects the AIO mode of play, the program automatically chooses the scenario (Barbarossa) and optional rules (see the screenshot below) . It then lets the player enter a name for himself/herself. Once that is done, the program selects the AIO playing the USSR and the human playing the Germans.

Basically, once a player selects the AIO mode of play and enters a name for the human player, the game completes the Start a New Game form information, sets up the USSR units, and then switches over to the human player to: (1) choose which German units to scrap, (2) set up the German units, and (3) start the first turn.

First Germany and Italy declare war on the USSR (automatic and mandatory), to which the AIO replies by setting up the USSR reserve units - using a random number to vary which units go where. The human player then gets to choose which minor country to align (or neither) and place the units belonging to that country on the map.

Over the past month I have gotten through writing/testing the code for the AIO performing the non-phasing side decisions for the subphases of all the air missions. During the first impulse of the first turn, there isn’t a lot that the AIO can do with its air units, since the USSR is surprised by the Axis declarations of war.

So, right now, the human player gets to make the dscisions for the phasing side during the first impulse of the first turn, up to and including rail movement, land movement, and land combat declarations. The AIO still needs to decide about land combat choice (assault or blitz). I’ll work on that next - it shouldn’t be too difficult to finish.

I Later today I want to post the current version of the program to the beta testing FTP site so they can hammer away at the code I have written so far. What I would like to get back from them are saved games after the German player has moved all his units, made all his attacks, and advanced the game to the 2nd impulse, where the AIO is the Phasing Side and needs to decide where to move its units, make attacks, etc. Those saved games will provide me with data on a range of situations the AIO might encounter when it needs to decide about moving units and making attacks (if any) in the second impulse.

Here’s a screenshot of the optional rules the AIO uses in Barbarossa.

[Shannon V. OKeets]

October 5, 2022 Status Report for Matrix Games’ MWIF Forum

Product Releases
I released a new version (05.00.00.05) to the beta testers today. It contains the code for the AI Opponent to play the Barbarossa scenario as the USSR through to the beginning of the second impulse of the game. It also has the code for the new form on AIO statistics described below. Once the beta testers have had a week or so to work with the new version, we’ll make a public beta copy available to all players.

Bugs
I fixed a couple of problems with determining tertiary to secondary supply paths. The first bug would sometimes not even search for an overland path. Once I fixed that, I then had to eliminate an infinite loop where after finding one path, the program would keep searching for a ‘better’ path. The code looks correct now, and it performs supply searches faster. Of course I have (sadly) been wrong about this several times on previous occasions.

Missing Optional Rules & Half Map Scenarios
Nothing new in September.

AI Opponent (AIO)
I created a new form for the AI Opponent to ‘study’ the map. Basically, this is an accumulation of statistics about which units are in the land regions of the Barbarossa map. I have included a screenshot below.

The important information is in the left panel. The selected geographic area in the screenshot is the land region Rumania - indicated by the label in the top left column. Beneath the header line are statistics on the units in Rumania. Most of these are simple counts or sums. However, the most important numbers are the Total Combat Values for each side. While similar to the Total Combat Factors (of just the land units), the Total Combat Value includes air units and takes into consideration unit types and movement points. A simple example is that the Russian 5-4 infantry is more valuable than the 5-3 infantry, and both are more valuable than the 5-1 garrison. Because the garrison unit is cheaper to build, its unit type decreases its value in addition to its single movement point,

Comparing the Total Combat Factors for the two sides, it looks like the Axis is only slightly more powerful in Rumania: 39 to 26. The Total Combat Values show a different story, with the Axis having units present that are more than double in Combat Value compared to the USSR units in Rumania. Note that the mechanized and motorized Russian units shown on the map are outside of the Rumania land region - they are in the Kiev land region Other statistics can be derived from the data displayed. The average combat factors for the corps and divisions would be useful in assessing how strong a defensive line can be formed and how powerful an attack can be generated from 2 or 3 hexsides. Those numbers are 5.2/0.0 Allied and 3.8/2.5 Axis.

Describing the rest of the form, the Land Regions column lists all the land regions in Barbarossa. Similarly, the Theaters of Operation and Areas of Operation tables list those geographic areas for the scenario, The grouping of the land regions in the second column corresponds to the labels in the Areas of Operations table. For instance, Estonia/Latvia, Lithuania, Western Poland, and Eastern Poland (the third group of Land Regions) are in the Poland/Baltic Area of Operation (the third entry in the Areas of Operation column).

Clicking on a land region label displays the Cumulative Statistics for the land region, and simultaneously displays the counters of the units in the land region in the rightmost panel. Moving the cursor over a land unit counter updates the Unit Data panel in the lower right corner of the form. Clicking on an Area of Operation label does the same for all the units in the selected area of operation. Clicking on a Theater of Operation does likewise.

This is not a ‘polished’ form since I do not intend for players to use it extensively, if at all. Most players gather this information visually, just looking at the map. That option is not available to the AIO. Hence, I have written code for the AIO to gather statistics for use in its decision making. The AIO Statistics form serves a couple of purposes: (1) it lets me confirm that the statistics the AIO derives are accurate, and (2) it lets me figure out how I am going to have the AIO use these data to make decisions about moving units.

[Shannon V. OKeets]

November 4, 2022 Status Report for Matrix Games’ MWIF Forum

Product Releases
I expect to release a new version (05.00.00.06) as a hot patch for all customers tomorrow. It contains the code for the AI Opponent to play the Barbarossa scenario as the USSR up to the beginning of the second impulse of the game. It also has the code for the new form on AIO statistics that I described last month (see the forum post immediately above).

Bugs
There were (still) times when the program would get confused as to supply lines from tertiary supply sources to secondary supply sources. These could/would be corrected by saving and restoring the game. But doing so was a hassle. So I added code to the routine that displays the Supply Sources and Paths (accessible using the F8 key). Basically, this change executes the same code for determining supply that is used when a game is restored.

The bug was in trying to reuse the paths that were found the previous time supply was calculated. Those old paths could become invalid when the weather changed or other stuff happened in the game that affected supply paths. While reusing the paths previously calculated saves time, it did have this deleterious effect of sometimes being Wrong. I didn’t want to force the complete recalculation of supply every time a unit is moved on the map. So this change enables the player to force the complete recalculation of supply whenever he deems it appropriate - using the F8 key.

Missing Optional Rules & Half Map Scenarios
Nothing new in October.

AI Opponent (AIO)
Work on the AI Opponent for World in Flames continues with steady progress, although nothing spectacular. Below is one of the graphic diagrams I created to help me understand what the AIO ‘sees’ when it is done gathering statistics about a position. This is done prior to making its land moves in an impulse (there are multiple impulses per turn). I have set aside a half dozen saved game positions from a Global War scenario NetPlay game I played with Karl. While not based on the Barbarossa scenario, these reflect the Barbarossa attack and defense positions quite well.

Of those half dozen I have created diagrams for 3 of them. These let me decide how the AIO should use the statistics it has gathered to decide whether it should retreat, defend, or reinforce each land region. See the tables embedded in the diagram for what all the colors and symbols mean. When a land region is in Crisis, then the AIO should have units retreat from the land region - unless massive reinforcements are immediately available in an adjacent land region. When a land region is Safe, the AIO should consider sending any available reinforcements forward to an adjacent land region (i.e., westward).

Note that these are snapshots in time, which is what the AIO will use for making decisions. While an argument could be made for maintaining a history of statistics in the game and even projections for the future, I think that would be way too much analysis. Responding to the current situation should provide the AIO with “good enough” decision making.

I have moved on from the diagrams and I am now working on identifying front lines. So far I have calculated the data for each hex in a land region, as below (taken from my in-line comments in the code).

// ****************************************************************************
// Each hex in a land region has a FrontLineStatus.
//
// FrontLineStatus has 7 possible values:
// 1 = German land unit present.
// 2 = No land unit present, adjacent to a hex with a German land unit.
// 3 = German controlled hex, no land unit present or in any adjacent hex.
// 4 = No land unit present, adjacent to hexes with both German and Russian land units.
// 5 = Russian controlled hex, no land unit present or in any adjacent hex.
// 6 = No land unit present, adjacent to a hex with a Russian land unit.
// 7 = Russian land unit present.
//
// In addition, the 6 adjacent hexes are stored. If the adjacent hex is all-sea
// or not part of the scenario, then the column and row for the adjacent hex is
// stored as (-1, -1). That is also the hex value if the adjacent hex is
// unreachable through the hexside (e.g., all-sea without a straits hex, or
// lake hexside, or alpine hexside).
//
// Using the information on the adjacent hexes, it is possible to retrieve the
// FrontLineStatus on all ('viable') adjacent hexes.
//
// Other calculated data about each hex that's stored is:
// 1 - Whether there is a Corps unit present.
// 2 - How many land units are in the hex.
// 3 - The total combat factors in the hex.
// ****************************************************************************
FrontLineStatus: Byte;
Adj_Hexes: array [0..5] of TSmallPoint;
Corps_Present: Boolean;
Land_Unit_Count: Byte;
Total_CF: Integer;
// ****************************************************************************

The stuff about adjacent hexes could be figured out on the fly whenever it is needed. But I like doing the calculation once for each hex, storing it, and then being able retrieve it with a single simple call.

So, the potential front lines hexes are determined for both sides. This only needs to be done in land regions where both sides have land units present. From the USSR point of view, a land region has a group of hexes with FrontLineStatus of 7. If any of those hexes is adjacent to a hex with a FrontLineStatus (FLS) of 1, then it is obviously a front line hex. A second group has a FLS so 7 with an adjacent hex of FLS of 4.

Combined, these groups of hexes are then analyzed (by brute force search) to identify front line fragments. That is, hexes that are adjacent to other hexes in the group form a line fragment. Note that this is done for each land region. A line fragment is a ‘complete’ front line when it has two hexes, each of which is adjacent to another land region or to a sea area (the Baltic Sea or the Black Sea). The two hexes cannot be adjacent to the same land region/sea area. For clarity’s sake I am calling those hexes Endpoints.

At this point I need to finish writing the code to support the above analysis. Only by looking at examples from real games can I decide how to combine line fragments into a contiguous front line for each land region.

---

I am still looking for saved games from the early part of the Barbarossa attack. They can be from any mode of play (solitaire, head-to-head, NetPlay). If you have some please post them to the thread Planning Land Movement in the sub-forum AI Opponent Discussion.