|
Shannon V. OKeets -> RE: MWIF Monthly Reports (2/4/2021 7:18:52 PM)
|
February 4, 2021 Status Report for Matrix Games’ MWIF Forum
Product Releases
No new Hot Patches last month. The most recent was in November: version 04.02.01.02. No new versions for the beta testers either. The numerous changes that I was making to the code for the AI Opponent generated compile errors. That meant that there were no decent executables for either customers or beta testers to use. Compile errors have calmed down recently, so I should be able to get something new out to everyone in the next couple of days.
Bugs
Two of my three sources of bug reports (posted in the Tech Support forum and from beta testers) were up-to-date as of the end of January. As for the third data stream (emailed bug reports), I have fallen behind once again.
I only made a few fixes for bugs during January.
Missing Optional Rules & Half Map Scenarios
I’ve been using the optional rule Isolated Units in my ~30 hours a week NetPlay game this year. The code change reducing the maximum path for finding supply from 50 hexes to 10 hexes is working without any noticeable delay in response time. With this rule in effect, having units wander far and wide behind enemy lines (especially in China) is a less effective tactic. They get isolated easily and if they then move, they become: disorganized, are immobile, weaker defensively, and easily destroyed.
I finished the code for V-Weapons. The code for A Bombs is mostly complete, except for actually dropping the A-Bomb. The program is still using the combat factors of the transporting air unit, instead of the 25 factors from the A-Bomb. Finishing that last step won’t take long. Before making the next hot patch available, I would like to get the optional rule Flying Bombs working as well.
My list for the remaining missing optional rules is unchanged - but I want to review it again based on feedback I have gotten from customers and beta testers:
1. Hitler’s War Rules as Coded 13.3.2
2. Guards Banner Armies Rules as Coded 22.4.14
3. Recruitment Limits Rules as Coded 4.2
4. Rough Seas Rules as Coded 22.4.6
5. USSR Japan Compulsory Peace Rules as Coded 13.7.3
6. Naval Supply Units Rules as Coded 22.4.13
7. Partisan HQs Rules as Coded 22.4.16
8. Limited Aircraft Interception Rules as Coded 14.2.1
AI Opponent (AIO)
I spent more than half my time in January working on the code for the AI Opponent. To start, I want to have the AIO, playing the USSR, capable of beginning the Barbarossa scenario. That entails scrapping units, deciding which air units receive pilots (or are NOT returned to the Force Pool when not using pilots), placing the units on the map, and calling out and placing the reserves on the map.
I finished the task of scrapping units. Basically the AIO will always scrap the same units. Because the scenario is only 5 turns long, building new units is not that important. This is especially true for units that take more than 2 turns to arrive. Those with a long production time will have to be built in the first or second turn, and even then they won’t arrive until the last turn. It is much simpler to just make hard and fast decisions for the AIO to scrap weaker units, with the benefit of knowing precisely (or nearly so) which units are available at the beginning of the scenario to be placed on the map. Spending USSR build points on militia units and land units that Germany destroys in the first few turns is a reasonable plan. To have the AIO actually scrap units was rather simple, since the code existed for reading in a list of units to be scrapped.
Even easier was deciding on a “saved setup” for the USSR in Barbarossa. Saved setups only address non-random units, such as named units (ships) and saved oil points. HQs also qualify for this category, but I did not want to commit the AIO to always placing the USSR HQs in the same hexes. Therefore, deciding on where the HQs set up will be part of the script for deciding where the randomly selected units are placed (e.g., infantry and cavalry). Here again, the code for reading in a saved setup already existed, so I just had the AIO read in a saved setup (that I created manually) and had MWIF apply it the same way it does other saved setups.
Having finished those code changes, which required new branching logic based on the decision maker being the AIO, I moved on to the script for setting up the USSR in Barbarossa. Back in 2009, Peter S. and I had worked on a script for setting up France at the beginning of the Global War scenario. Using that as a framework, I had a head start on the USSR setup script. Separately, we had also looked into how the USSR should defend against a Barbarossa attack. Towards that end, we broken the terrain over which the Barbarossa battle takes place into Theaters, Areas, and Land Regions. The latter two hex sets are subsets of the previous hex set. Peter had gone even farther into the analysis in 2015, identifying critical hexes within each land region that should be occupied by the AIO to achieve a decent defensive position. See the screenshot below, where orange tinged hexes are the most important and yellow tinged hexes slightly less important. White hexes are third in importance and hexes without any color are of lowest importance.
We have a pretty good idea of where the reserves should go, but the script will have several different sets of positions for them, and randomly choose which one to use. That is the same principle that we’ll use for setting up other units: random numbers will determine which of several equally good setups will be used. Except for the reserves, all the other units have to be placed on the map before the USSR/AIO knows where the German units will set up. Without knowing where the German units will be, the AIO can’t take “the enemy position” into consideration.
Lastly, I have returned to writing code for the parser. I never wanted to hard code how the AIO makes decisions, instead I wanted to enable an ‘author’ to write scripts for how the AIO decides stuff. To achieve that I needed to define a language in which the scripts would be written: LAIO (Language for the Artificial Intelligence Opponent). I had some experience creating programming languages back in the early 1980s, when I created a language for doctors to write how a patient responds to disease and treatment over time. That was for the American Board of Internal Medicine. They wanted a program that would simulate the changes in a patient’s condition over time starting from “the patient presents ...” with a certain illness, and then responding to a doctor’s decisions to run tests and administer treatments.
Around 2008 I had LAIO defined for MWIF. Like other programming languages it has variables, branching logic, loops, functions, and procedures. Writing the language definition was accomplished while I was vacationing in Europe and at other times when I was unable to write MWIF code. However, it was only a paper document. The real work is in writing the parser, which reads in a LAIO script and transforms it into variables, branching logic, etc. for use by the MWIF Pascal code.
As for so much of the AIO code, I had already written about half of the parser. This past month I went back over what I had already done (many mental cobwebs needed dusting). Not only do I now understand what I had previously written, I have also added code that completes some of the tasks I had “up next” on my AIO task list way back in 2010.
I expect to spend at least half of my time next month on the AIO parser.
[image]local://upfiles/16701/C8A5BD54934E4F30B8AAB6FFBEC8DC9E.jpg[/image]
|
|
|
|
