Shannon V. OKeets
Posts: 22095
Joined: 5/19/2005
From: Honolulu, Hawaii
Status: offline
|
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.
 Attachment (1)
_____________________________
Steve
Perfection is an elusive goal.
|
Printable Version
RE: MWIF Monthly Reports - 
New Messages
No New Messages
Hot Topic w/ New Messages
Hot Topic w/o New Messages
Locked w/ New Messages
Locked w/o New Messages
Post New Thread