When?

[Joseignacio]

Anyway, obviously, this is something up to Steve to decide. There may be contractual matters, his own oipinion about the need itself or about wether he wants to work with a team or not, and also the matter of sharing his profits with more people.

He already said no, so unless he changes his mind, it's no...

[PaxMondo]

ORIGINAL: Red Prince

I don't think I was around for the last time this was suggested, but from where I stand, this would not actually help all that much in terms of "fixing the game" for final release.

As you may know, it's been a rough month for me. Recovering from pneumonia has cut the time I can put in from 9-13 hours daily down to 2-3 hours if I'm lucky. I've been using that trying to get work done on the test game I've been posting in the Global War AAR.

During September and October, after Steve's eye surgery, I was responsible for the tasks of collecting, organizing, and detailing the bugs reported by the beta-testers. From this, I created daily reports for Steve to review and work on. This task alone used up about 4-5 hours of my day, since we are also trying to implement a more efficient and structured system for eliminating the bugs that remain. In fact, new bugs reported in October were only half the number reported in September, so I think a lot of progress was made in that respect. From this experience (which I hope to take up again once I'm fully recovered), I can tell you that running MWiF as an "open beta" version would require a primary team 2 to 3 times the size of what we currently have. Steve would need someone to do the job I was doing (me, when recovered), and I would need several assistants myself.

It's a critical mass kind of thing. Mid-way through 2011, we were overwhelming Steve with bug reports, and he had to split his time between organizing them and programming. When I took over the organizational process, it allowed Steve to focus completely on programming, and that had a significant impact on the amount of work he could get done each day -- even while recovering from eye surgery and a kidney stone the size of Gibraltar. It is my belief (and Steve or Matrix may disagree with me here) that an open beta would put us back into the realm of an overwhelming workload, and that would be counter-productive.

So, whether it was Matrix or Steve who rejected the idea the last time around, it is my opinion (hopefully fairly educated) that this would be a Bad Idea.

I'm sorry if that disappoints you, but I want to be honest.

-Aaron

Having been a beta member for a number of game (different development houses), I would agree with your assessment completely. A Public beta at this time would consume so much resource to just track the input, that it would further delay the release of the game.

Public betas are very effective for "polishing" a product .... not for development. You use them later in the product cycle to track down those last few bugs that show up infrequently and/or unrepeatably (the worst type), so having a large pool of testers gets you data on them that you otherwise cannot collect.

[Shannon V. OKeets]

December 1, 2011 Status Report for Matrix Games’ MWIF Forum
Accomplishments of November 2011

Project Management
I monitored all the threads in the MWIF World in Flames forum daily.

Aaron’s bout with pneumonia has sidelined him from maintaining my task list, and from performing numerous other tasks he’s been doing to support MWIF development. Until his health improves, I am back to keeping track of my task list on my own.

But on the positive side, Rolf now has some time to help out with the programming. I just uploaded the current version of the source code for him to work with. Later today I’ll select some of the new bug reports from version 9.02.05 for him to fix.

My health is so-so, which is relatively good news. To prevent a reoccurrence of a kidney stone, I have rather dramatically changed my diet. One element of that is simply drinking 80 ounces of liquids every day, mostly water. But my food intake has also been overhauled. In general, I am unhappy with the dietary changes, but maybe after tweaking it for another month or so, I’ll be able to make it less drab. My eye still interferes with my ability to work long hours; I’m down from 8-10 per day to 6-8 per day (although still 7 days a week).

My long struggle with rewriting the Supply routines this month (detailed below), made me question whether my memory was fading. To check on that I decided to memorize the periodic table of elements. That went pretty fast. After 1 week I had learned the first 5 rows (72 elements). That was all I wanted to learn. Next year I might go back and reread the college chemistry book I bought ten years ago. Understanding the references to individual chemical elements better should make comprehending the text easier.

Hardware and Software
Delphi 2010 is still misbehaving. When time permits, I’ll submit a full report on what is wrong to Embarcadero (which currently owns Delphi).

The open items for Theme Engine remain unchanged: (1) scroll bars for the detailed map, and (2) its inability to display detailed listings of file directories (i.e., the dates and stuff when opening or saving a file). Neither of these is important.

At the end of the month I purchased an upgrade to the latest version of WordPerfect Office (it was on sale), which I use for all my writing, spreadsheet, and database work. I’ll try to find the time the install it once I finally beat the Supply routines into submission.

Beta Testing
I only released 1 new version to the beta testers this month: 9.03.00 and that only had 9 fixes. I spent the entire month working virtually exclusively on a rewrite of the Supply routines. On the plus side, the beta testers did not find a lot of new bugs. I need to sort through the bug report thread on version 9.02.05 to identify which ones are reports on new bugs and which are new reports on previously reported bugs.

Saved Games
The beta testers are CC’ing me on saved games they send to Aaron for testing and archival purposes. The save and restore code continues to work flawlessly, as it has for months now.

Map and Units
Rob and Jimm send in new and/or updated naval and land unit writeups from time to time. Aaron keeps the master files and sends me replacement files periodically.

Scenarios and Optional Rules
Nothing new.

Rule Precision
At the beginning of the month I had my rewrite of supply working correctly to:
• calculate primary supply sources for major powers (including cooperative major powers)
• calculate primary supply sources for minor countries (including their parent major powers)
• the above includes HQ supply for the turn and the impulse
• calculate secondary supply sources for major powers: HQs and aligned/conquered minor country capitals
• the above includes HQs belonging to cooperative major powers
• calculate HQ secondary supply sources for minor countries (including their parent major powers)
• all of the above could include overseas links using any of the related optional rules.

The problem was that it was taking too long. After a couple of days I was able to reduce the time from 9 minutes to 9 seconds. Presently it takes 5 seconds to execute the above list, regardless of which optional rules are being used. That is when starting from scratch. It should run effectively instantaneously when simply checking whether previous sources and paths are still valid.

I’ve since added the ability to have units trace to supply sources. That took me a couple of weeks to accomplish. The difficulty was that my design for data storage was flawed and I needed to go back and make substantial revisions. Ripping apart code when modifying data structures is particularly difficult. There was one typo I made where a TObject was defined as a TObjectTable. That caused the program to overwrite the executable code, resulting in bizarre fatal errors that occurred in different places at different times. A real nightmare to figure out. Every day I would get up and try to figure out what was going wrong. I did that for over a week before I finally ‘saw’ the error.

Currently I am whiling away the hours delving into why the overseas paths, which are correctly identified, are being stored as several long lists instead of one path per secondary supply source/unit. I found an index that was wrong late last night but making that change this morning only partially alleviated the program’s propensity to route Oslo supply for the Germans through the Med and South China Seas. At least the Allied supply paths are no longer being appended to the path. To repeat, the program finds the path from Oslo to the Baltic to Konigsberg, but then the process of storing that information in the data lists is messed up. It seems to be overwritten by Rommel’s supply route from North Africa and the Japanese HQ’s in China.

If no overseas paths are needed, all the code works - to the best of my knowledge. For instance, the Barbarossa scenario computes supply perfectly using the new routines. It executes the supply determination from scratch in a fraction of a second. But when I apply the heavy duty test using the Brute Force scenario, with the US fully in the war and units scattered all over the map, the overseas routines break down.

The supply code is separated into 4 modules:
• Supply Links, which defines most of the data structures and the routines for identifying supply sources.
• Supply Searches, which has the more complex algorithms for tracing supply from point A to point B.
• Sea Area Supply, which traces supply overseas and pieces together the supply connections from secondary supply source to departure port, first to the overseas path, and finally with the arrival port to primary supply source.
• Supply Sources and Paths, which is the form that displays the sources and paths for review.

The file sizes for those modules are 2050, 2560, 2250, and 1210 respectively. At different times during the month those file sizes expanded and contracted as I made significant mods to the code. All-in-all it is 8,000 lines of code that includes a lot of tables, arrays, indices, pointers, and search algorithms.

You might think that the optional rules are what is causing problems, but they aren’t. At some point I will have to code the search for isolated units (infinite supply paths) which makes me worry about the time it might take to ‘prove’ that a unit is isolated. But since isolation comes up rarely and is usually caused by a unit being surrounded by enemy ZOCs, it shouldn’t be too difficult to get to it execute quickly.

The way the supply searches work is to view each hexagon as the central focal point of 7 hexagons. By computing and recording information on each of the 6 adjacent hexes and hexsides, these TSearchHexes enable the program to compute which of several possible destination hexes is closest and to ‘head’ in that direction. For instance, in the attached screenshot, the potential secondary supply source Tallinn needs to trace a rail path to a primary supply source before it can function as a secondary supply source. The program checks each adjacent hex and marks hexsides 0, 1, and 3 as impassable.

[See the all sea hex in the attached figure for hexside numbers. Hexside 0 is to the west and the other 5 hexsides are numbered clockwise from there. The easy way to remember this is that hexside 2 is at 2 o’clock, 3 at 3 o’clock, and 4 at 4 o’clock. With those in place, figuring out which hexsides are 0, 1, and 5 is easy.]

Of the other 3 hexsides, the program prefers hexside 3, since it uses a rail connection which does not expend one of the limited number of Basic Path Hexes available for a rail path. Then the program evaluates the six hexes adjacent to the new TSearchHex, (38, 49). Hexside 0 leads back to a hex already examined, so that hexside is non-viable. Hexside 1 is impassable. Through hexside 2 is an all-sea hex which is recorded in the TSearchHexes list as non-viable. Of the 3 remaining hexsides both 3 and 4 have rail connections. They are also both 3 hexes away from the nearest primary supply source. But hex (38, 50) is preferred because it is 3 hexes away from 2 primary supply sources (Leningrad and Pskov), while (39, 49) has only 1 primary supply source within 3 hexes (Pskov). The logic continues processing and the rail path reaches Leningrad without expending any Basic Path Hexes. That means it will be viable regardless of the weather conditions.

Here are some of my notes on finding rail paths (secondary to primary). To understand these notes you need to know that a secondary to primary overseas path is composed of 3 pieces: 2ndary to departure port, overseas path, and arrival port to primary. The two land pieces can use up to 3 Basic Path Hexes maximum, since the overseas piece always uses 1 BPH.

1. When failing in a search for an overland rail path from a secondary supply source to a primary, the algorithm identifies all the ports it can reach. So when the search fails, the program stores all the ports the supply source could reach using 3 or less Basic Path Hexes (BPH). Those have the potential for being Departure Ports and are labeled ReachableDeparturePorts (for the given 2ndary supply source) and store the index into the list of port hexes. Also stored is the path used to reach the departure port (so it doesn't have to be recomputed later).

2. Searches for Arrival Ports are performed for a major power or a minor country if (and only if) the country has a secondary supply source that could not reach a primary using an overland route (a.k.a, the supply source is OOS 2ndary), but the supply source has to be able to reach a port. Japan almost always fulfills this criterion because of the captured capitals it controls in mainland Asia.

3. Assuming #2 has been satisfied, sea areas that can be used (i.e., not blocked by the enemy or other overseas supply rules) are then computed for the given major power/minor country. The list of possible Departure Ports is trimmed to only those which connect to the just computed viable sea areas.

4. The list of Failed Arrival Ports is initialized to all the departure ports that could be reached by any OOS 2ndary using 0 or 1 BPH (computed in step #1). We already know those ports can not reach a primary via an overland route using 3 or less BPHs.

5. The full list of ports is then processed looking for viable arrival ports, skipping those in the list of Failed Arrival Ports and those that are not adjacent to a sea area identified in step #3. Also, if an adjacent sea area has been marked with a BPH of 1, the port is skipped (see steps #7 and #8 below). Of course if the port fails any of the other conditions for being used in a supply path, it is also skipped.

6. Processing a potential Arrival Port consists of trying to find a rail path from the port to a primary supply source. If the search fails, then the searched hexes are reviewed, and any port in the search path that could be reached using 0 BPHs is added to the list of Failed Arrival Ports. We already know that these ports can not be connected to a primary using 3 or less BPHs.

7. When processing finds a path from an arrival port to a primary supply source, the adjacent sea area is marked with the number of BPHs used for that connection. The minimum is 1, which counts the overseas path arriving in the port.

8. Successful sea areas identified in #7 are immediately propagated to all other sea areas; which means that the BPH number is propagated. The paths for both the arrival port to primary and propagated sea areas are stored so they do not need to be recomputed.

9. The search for arrival ports continues until all ports have been examined.

10. After all the Arrival Ports have been found, the list of OOS 2ndary are checked to see if their Departure Ports connect to a sea area with a low enough BPH number to satisfy the total BPH limit (which depends on the HQ's hex's weather).

11. The full path for each OOS 2ndary that has succeeded in step #10 is pieced together using 3 links: 2ndary to departure port, overseas, and from arrival port to primary. The full path is stored for the 2ndary supply source.

The advantages of this algorithm are several:

A. HQs that are cut off from reaching a primary supply source overland are not examined if they are unable to reach any port. This is likely to occur quite often in the USSR and China. No searches need to be done for overseas paths for those units.

B. Secondary supply sources that can not reach a port that connects to a sea area identified in #3 do not require processing for overseas routes. For example, if Japan loses control of the sea areas around its home country, no overseas supply computations are necessary for Japan.

C. Ports that can be reached by OOS 2ndary are removed from the list of possible Arrival Ports. This has the advantage of not having the ports in, say, Egypt, trying to reach a primary supply source overland multiple times.

D. Failed searches for Arrival Ports can add numerous entries to the Failed Arrival Port list. For example, if a Chinese HQ, cut off from reaching a primary supply source overland, can reach a sea area (e.g., the HQ is in a coastal hex) then searching all the US and Commonwealth and USSR ports for railway paths to, say, Chungking, only needs to be done once for each rail network. If San Francisco fails as an Arrival Port, then the program knows to skip all the other ports that connect via rail to San Francisco. Each rail network is searched only once for all OOS 2ndary for a major power. Note that the search algorithm searches for ANY primary supply source for the major power. Hence, it is only executed once for ALL primary supply sources.

E. Once a sea area has been found with a BPH of 1, then all the ports adjacent to that sea area are skipped. This means that when a major power controls numerous ports on the same sea area, we only have to find one Arrival Port that connects to a primary at a cost of zero BPH.

F. The propagation of sea areas with a BPH of 1 can have strange, but valid, effects. When searching for an overseas path for Colombo, Ceylon, the program finds a path to Liverpool, ignoring the presence of all the primary supply sources in India. That’s because an overseas link to Liverpool was found earlier and is immediately available, without performing any additional searches.

Finding supply paths for units and tertiary supply sources is vastly simpler, since the maximum BPH is 4 and rail hexes xost the same as other hexes. Note that rail networks are dynamic, since the movement of units can cut supply path connections.

Player Interface
I did a lot of work on the Supply Sources and Path form this month. It now identifies all the supply sources, primary and secondary, and shows how many units are being supplied by each. When you click on a supply source, the actual units are shown in a list at the bottom of the form. For secondary supply sources, the supply path it uses to reach a primary is shown. Clicking on a unit image, causes the supply path for the unit to appear. At some point I want to add a button for displaying all the units that are out of supply: both secondary supply sources (which may include cities) and units.

Internet - NetPlay
Nothing new last month. My work on NetPlay is delayed until I can coordinate with other programmers at Matrix Games/Slitherine. They have a system that they are using for other games and if possible, I want to fit MWIF into the design they already have working. From my preliminary reading of what they have done, that may be feasible. No sense reinventing the wheel.

PBEM
Nothing new.

Artificial Intelligence (AI)
I finished checking the names for the Areas of Operation and Land Regions so they conform to the ‘standard’ I set up. The major task remaining is to change the data file for the terrain, adding a digit to the end of the row of data for each land hex. There are 70,200 hexes, each of which has its own row of data. Mercifully, the all-sea hexes do not need to be edited (they use the default value).

Player’s Manual
I have a handful of small edits waiting the Matrix Games editor. He should begin working on the Players Manual and the Rules as Coded documents this week.

Tutorials, Training Videos, and Context Sensitive Help
Nothing new.

Historical Video, Music, and Sound Effects
Nothing new.

Marketing
Nothing new.

Communications
Nothing new.

[npilgaard]

My long struggle with rewriting the Supply routines this month (detailed below), made me question whether my memory was fading. To check on that I decided to memorize the periodic table of elements. That went pretty fast. After 1 week I had learned the first 5 rows (72 elements).

Not to bad - at all! [;)]

Every day I would get up and try to figure out what was going wrong. I did that for over a week before I finally ‘saw’ the error.

I don't think I've ever 'met' anyone with such a degree of determination and commitment as is shown on this project! I've probably said so before, but I find it truly impressive!

[Crimguy]

I'm firmly convinced this is the cruelist thread in the world. I've been staring at this progress update for I don't know how many years.

I'm beginning to appreciate Steve Jobs "Surprise" keynotes. . .

[Red Prince]

It is not our aim to be cruel. That is just a little bonus we get by posting in this thread.

Just teasing you. I know how you feel, but this is the place to find updates. I'm sorry that it causes you any mental anguish.

[micheljq]

ORIGINAL: Shannon V. OKeets

December 1, 2011 Status Report for Matrix Games’ MWIF Forum

Beta Testing
I only released 1 new version to the beta testers this month: 9.03.00 and that only had 9 fixes. I spent the entire month working virtually exclusively on a rewrite of the Supply routines. On the plus side, the beta testers did not find a lot of new bugs. I need to sort through the bug report thread on version 9.02.05 to identify which ones are reports on new bugs and which are new reports on previously reported bugs.

If the beta testers did not find a lot of new bugs lately this is a very good sign.

[Centuur]

ORIGINAL: micheljq

ORIGINAL: Shannon V. OKeets

December 1, 2011 Status Report for Matrix Games’ MWIF Forum

Beta Testing
I only released 1 new version to the beta testers this month: 9.03.00 and that only had 9 fixes. I spent the entire month working virtually exclusively on a rewrite of the Supply routines. On the plus side, the beta testers did not find a lot of new bugs. I need to sort through the bug report thread on version 9.02.05 to identify which ones are reports on new bugs and which are new reports on previously reported bugs.

If the beta testers did not find a lot of new bugs lately this is a very good sign.

Yes, it is. However, it's only one month... Wait and see what happens during december/january...

[RJL5188]

i will admit...i have been waiting for this game for years ever since matrixgames was going to develop it...please take your time and make sure you release the best game u possibly can...but when this game is finished and released...it will be the BIGGEST...MOST COMPREHENSIVE GRAND STRATEGY WORLD WAR II COMPUTER WARGAME EVER RELEASED IN HUMAN HISTORY!!!!

this game will replace all other games in its class....take my word for it.

[JohnTargus]

Hmm,

I think this game will be a good one.... if only it ever came out. I don't think it should be released unfinished, no, but after the long years I've sat waiting for this one, you would think we would get at least a finished product by now. I know people are going to grumble about my complaining but seriously people, this one has been in production for a long time now. Years, what a decade, and I'm starting to think it will never get out.
Another year is passing and the only thing I can can think WIF will be is... vaporware......[:-][:-][:-][&:]

Sad, very sad indeed....

[macgregor]

I know this much; somewhere Harry Roland is smiling down on this. I find it fascinating to the degree matrix WIF has avoided trying to make a game based on wif -using whatever advantage the computer would offer to redesign it with more detailed combat and events, and instead, making wif; the boardgame experience on the pc. I'm hoping for a virtual beverage(coke no ice) and maybe some virtual non perils(though pistachios would probably make for better graphics with sound.)
[:D]

[Shannon V. OKeets]

January 1, 2012 Status Report for Matrix Games’ MWIF Forum

Here is 2011 in review.

Accomplishments of 2011

Project Management
I monitored all the threads in the MWIF World in Flames forum daily.

I had two major health issues in 2011: surgery in August in Philadelphia for an ocular melanoma and surgery in October in Honolulu for a kidney stone. All-in-all I lost a couple of months of productive time due to those problems. My vision is still impaired, which limits the number of hours I can work on the computer each day to 6-8, down from 10-12.

Mitchell and Rolf joined the programming team at the beginning of the year. Mitchell had a serious health problem in July and was unable to work on MWIF thereafter, so we only had the benefit of his expertise for the first 6 months of 2011. During that time he did timing studies on why Theme Engine took so long to switch between major powers (3 seconds). Based on his analysis, he was able to reduce the elapsed time to effectively zero. With that accomplishment behind him, Mitchell turned his attention to NetPlay and completed refinements to NetPlayComTest, which will be included as part of the released MWIF product. NetPlayComTest lets players test their internet communications without having to run a MWIF game.

Rolf converted a couple dozen record types in the CWIF’s Windows Messaging code for communicating over the internet to MWIF’s Game Record Logs. Those record types were some of the most complex, which involve moving units. Rolf also did some work on the LAIO (Language for Artificial Intelligence Opponent) parser, which reads scripts written in LAIO. Later Rolf worked on fixing bugs in the sequence of play. His availability was limited, since he was holding down two other jobs at the time.

Hardware and Software
Delphi 2010 continued to misbehave badly during 2011. Delphi is the software development package I use to edit, compile, and link the source code into the executable program MWIF.exe. I successfully work around Delphi’s more serious problems but in the last quarter of 2011, it developed the nasty habit of simply not starting. After losing 5-6 days trying to figure out why the application wouldn’t start (when I clicked on the Delphi icon to run it, it went into an infinite loop trying to load a JPG). I finally found a writeup on the internet by someone who had had the same problem and documented a solution: remove the browsing history files created by Internet Explorer! That worked like a charm. Why the existence of those files should confuse the Delphi application baffles me; perhaps because Delphi executes a Java script when it starts up?

The open items for Theme Engine remain unchanged: (1) scroll bars for the detailed map, and (2) its inability to display detailed listings of file directories (i.e., the dates and stuff when opening or saving a file). In my opinion, neither of these is important. Theme Engine is the software library I use to transform all the forms and buttons into something other than the bland gray backgrounds and images that are the Microsoft defaults. Early in the year I converted the Main from standard Windows style to Theme Engine. So, aside from the just mentioned two problems, Theme Engine is now in use for all 160+ forms and runs cleanly under Win XP, Vista, and Win 7.

Beta Testing
I released 85 new versions of the program with 1144 fixes to the beta testers during 2011. The version numbers ran from 7.01.02 through 09.03.01. For most of the year I focused heavily on fixing bugs in the sequence of play, hence the large number of new versions and bug fixes. In November and December I devoted almost all my time to rewriting the routine for determining supply. In the last week of December I also worked on NetPlay. Both of these mini-projects required all of my focus just to keep straight in my head what the code was suppose to do and how it did it. I’ve compared the complexity of coding the supply for World in Flames to solving Rubik’s Cube blindfolded. As you can see below, for those two months I effectively stopped working on fixing bugs reported by the long-suffering beta testers.

Here is a breakdown by month of the new releases and fixes:
• January - 10 new versions and 168 fixes
• February - 7 new versions and 118 fixes
• March - 8 new versions and 103 fixes
• April - 9 new versions and 128 fixes
• May - 9 new versions and 115 fixes
• June - 10 new versions and 79 fixes
• July - 6 new versions and 109 fixes
• August - 5 new versions and 69 fixes; surgery for ocular melanoma.
• September - 9 new versions and 117 fixes: surgery for kidney stone.
• October - 10 new versions and 128 fixes
• November - 1 new version and 9 fixes; supply rewrite.
• December - 1 new version and 1 fix; supply rewrite.

Aaron took over my master task list of bugs in August. He converted the simple text file I had been using to a spreadsheet and did an excellent job of synthesizing the disparate files from beta tester posts, saved games, and MadExcept reports, into a coherent mass. He prefaced the name of each file with MTL xxxx where xxxx was the Master Task List number for the bug. Working from his spreadsheet (which he updated daily) I was able to read about each bug, find the associated saved game, and reproduce the problem. In my opinion, the work he did on this offset the reduced number of hours I was able to work after my eye surgery, so my productivity remained about the same. Unfortunately, he came down with pneumonia in early November, after which I was once again left to my own devices. I learned from what he did and now use his system for naming files. However, maintaining the spreadsheet would take me more time than I would gain by its use.

Rob W. ran a complete set of tests on land movement for all unit types in all hex and hexside terrain types, under all weather conditions. That was hundreds of cases. I corrected the only bug he found in calculating land movement costs: when moving from a desert hex to an all lake hexside during snow.

Then Rob went through all the US Entry Options and US Entry Actions to make sure the code functioned correctly. As any experienced WIF player would expect, several questions about rule interpretations arose. After adjudication, Rob ended up identifying about a dozen bugs that needed to be fixed; only a couple of which concerned US Entry Actions. What was really impressive about Rob’s work here was getting the game to the point where each of these could be tested. He now has a saved game for each of them so he can determine whether my corrections work or not. I have fixed most of those bugs, with only a couple lingering on my task list.

Lastly, Rob ran a thorough set of Vichy tests: creating, playing, and collapsing Vichy France. I was able to fix some of them as he reported them but his final list in November added 17 new items to my task list.

I made good progress on Head2Head (a.k.a., HotSeat) play with the help of Orm. I believe that mode of play now executes cleanly.

As of today 132 of the 152 phases/subphases/sub-subphases/digressions that constitute the sequence of play are bug-free. In fact, during 2011 I was able to reduce all but a half dozen of those to zero bugs outstanding. Sadly, fuller testing revealed more bugs. The most recalcitrant areas were: Supply, Naval Combat, Production Planning, Conquest, and Vichy.

I’ve fixed all but one of the bugs concerning nested digressions. This last bug is when a naval unit aborts from a naval combat and is intercepted before it reaches port. Other than that, I have the 7 digressions working as intended, with normal processing of the sequence of play interrupted by a digression, or a series of nested digressions, and ultimately returning to the point in the sequence of play where the first digression occurred.

Most of the beta tester bug reports in the last half of the year arose from: (1) rigorous testing of how the program performs under a variety of obscure circumstances, and (2) going over the rules with a fine tooth comb. See the section on Rules Precision below for some examples of the modifications I made to fix bugs.

In July (I think) I added code to enable the beta testers to change many of the optional rule settings on-the-fly. This will not be part of the released product but it gives the beta testers another tool when setting up saved games for testing how the game performs with various optional rules On/Off.

Saved Games
Saving and restoring games was stable throughout the year. I added the name of the current major power to the label for automatically saved games during 10 additional phases. This makes it possible to restore a game to a more precise point in the sequence of play.

Michael created 5 Fast Start saved games. Many people like to jump into a new computer game as soon as it is installed, picking up the rules as they go. To facilitate this, MWIF comes with Fast Start saved games for 5 of the most commonly played scenarios: Barbarossa, Guadalcanal, Fascist Tide, Global War, and Missed the Bus. All the Fast Start games use the solitaire mode of play and the Novice set of optional rules. The Fast Start games begin at the first major decision of the scenario. For instance, Barbarossa starts with Germany deciding whether to align Hungary or Finland.

Starting in August, Aaron began building a large library of saved games for testing the numerous phases in the sequence of play. Of course this is complicated by the number of different scenarios and optional rules, as well as modes of play (e.g., solitaire, head-to-head, NetPlay). But with the help of many other beta testers, he generated a large library of saved games. From my perspective, the best part of this are the saved games related to specific bugs. Those let me immediately reproduce bugs so I can both fix them and prove to myself that my changes work.

Map and Units
The data and graphics for the map and units were mostly unchanged in 2011. I added a graphic to visually indicate when captured red factories are not producing. I still need to figure out how to indicate visually that a factory has lost a production point. There was a small data correction for a couple of City Based Volunteer units.

Throughout 2011 Rob continued to create new and update old naval unit writeups. For the land unit writeups both Adam and Jimm returned to work and did a batch of new writeups. In early summer, Aaron took over responsibility for maintaining the master files for all the unit writeups , which meant less work for me.

Scenarios
Barbarossa
I added code so the legal sea areas for this scenario are limited to the Black, Baltic, and Arctic Seas. I made an adjustment to the Production form to handle the fact lend leasing air units isn’t permitted.

Fascist Tide and Day of Infamy
These are the two half-map scenarios. For each scenario I made half the sea areas illegal to enter. For instance, when playing Fascist Tide (the war in Europe), entering the Indian and Pacific Oceans is not permitted. I also made corrections for the rules uniquely associated with the half map scenarios. In particular, I intend to use the Azanian Sea (for Fascist Tide) and the Eastern Med (for Day of Infamy) as holding areas for the “Transfer Pool”. This way when a naval combat has to occur in the Transfer Pool, the players will be able to see the units therein just as for any other naval combat.

The victory cities for these scenarios are now correct and so are the lists of which countries are legal. I fixed a couple of bugs when setting up Day of Infamy: New Caledonia now goes to Free France and Vichy France gets French Polynesia and aligns Madagascar. Japan is then able to align Madagascar as long as Madagascar is controlled by Vichy France. What was so difficult about getting this code correct (almost a full day) was that Vichy France doesn't officially exist in the scenario. I still need to add code for the external/European event of Germany collapsing Vichy France so it occurs at a fixed point in the game.

Optional Rules
Partisans
I fixed a few bugs related to setting up partisan units behind enemy lines after all the major powers have been set up. This subphase of Setup was tricky to code. Annoyingly, it has to perform a preparatory check to see if there is enough room for the units to be placed on the map. If, prior to placing the partisans on the map, the enemy player positions his units well, he can sometimes cover all possible placement locations with zones of control. That results in zero partisan units being capable of setting up.

Warlords
I fixed all reported bugs related to Warlords.

Off City Reinforcements and Territorials
I did quite a bit of work to fix bugs in the intersection of these two optional rules. Both are now bug free.

7 Unfinished Optional Rules for Initial Release
I worked on 7 incompletely coded optional rules that I want to include in the first release. To accommodate the associated rules I added 4 subphases to naval combat: Voluntary Abort by Walther Submarines, Kamikazes, and 2 ASW Pre-fire Attack subphases. All 7 of these optional rules still need work. They are listed below.

Convoys in Flames
This is difficult to code because it has so many pieces. I’ve added the code for the +2 penalty when trying to intercept auxiliary cruisers. That was a bear to get correct because of the complexity of search roll modifiers and search numbers. I changed the production form selection of repaired Auxiliary Cruisers so which one is repaired is randomly selected. In all other cases, the player can choose which naval unit to repair.

City Based Volunteers
I made some progress on City Based Volunteers.

Unlimited Breakdown
I made some preliminary changes to support Unlimited Breakdown.

Kamikazes
This optional rule requires a tailored variation of the ubiquitous Unit Dialog form. For instance, when the Japanese player chooses whether his naval air bombers are flying as kamikazes, a Unit Dialog form appears listing all the bombers so the player can select which ones should wear head scarves.

Guard Banner Armies
This optional rule also needs a tailored Unit Dialog form so the player can select individual units for upgrades.

Rough Seas
No work done towards this in 2011.

Naval Supply Unit
No work done towards this in 2011.

Rules Precision (a.k.a. MWIF Game Engine and CWIF Conversion)
In the beginning of the year I spent a lot of time trying to debug the code for naval movement and naval combat. That became so tedious that I stepped back and revised the code for the internal record formats to determine into which sea areas/ports the units-in-hand can move. That is, once you select a group of naval units to be moved, the program has to check each hex the cursor moves over to determine if it is a viable destination. CWIF used the same record layouts for air rebases, all land unit moves, and all naval moves. I split those into 3 different record types (air, land, naval) since different information was needed for each record type. That let me clarify the names of the fields in each record so they explain the data better. The changes for the air and land moves had zero effect - since they effectively were just cosmetic. My main motivation was to make it easier to debug the naval movement code. I

The primary effect on game play of these changes to the naval movement code is that the program now assumes the player wants to avoid sea areas where the enemy can attempt to intercept the moving units, even if it takes more movement points. The player can always move directly to sea areas where the enemy can intercept thereby ‘daring' him to do so. If the enemy declines (or fails), the player can continue moving and perhaps reach his destination using fewer movement points and range.

I created a new ‘pool’: the Destroyed Units Pool. This is another off-map ‘location’ for units. It replaces the Destroyed Stack variable that I had been using. Besides maintaining standardization with all the other off-map pools, this addition makes it clear ‘where’ the unit currently resides. When players access the Pools form to review the units in the off-map pools, the Destroyed Pool is like all the others (e.g., Force Pool, Production Pools). At the end of the turn each player reviews his units in the Destroyed Units Pool and decides whether to scrap them or not.

Did some work on getting Search and Seizure to function. It can now identify when a search and seizure is possible and which major powers get to make those decisions. I still need to write new code to effect the results of search and seizure. Because that is closely related to Production Planning, I am waiting on coding the rest of S & S until I have PP bug-free.

I added some new code for the factory destruction phase. That was a little tricky because there are rarely occasions when a player wants to destroy his own blue factories. The two that come up are: France destroying a factory in Vichy France before Vichy France is declared, and the USSR destroying a factory in the Ukraine before Germany declares the Ukraine as a separate country. Most of the time the program ‘knows’ that destroying your own blue factories is senseless and can skip the phase completely.

At one point I had killed off most of the bugs related to creating Vichy France. In doing so I created a small new form so the Vichy France controller can allocate countries that were aligned or conquered by France to Axis major powers. But then Rob went through the rules about Vichy line by line and word by word. In November he found 17 more bugs related to Vichy, that are a lump in my task list.

As you can tell from the following, many of the ‘bugs’ reported by the beta testers in the last 4 months of the year were due to them either: (1) rigorously testing how the program performs under a variety of obscure circumstances, or (2) going through the rules with a fine tooth comb. I made changes for:
• Imposing a setup restriction on the Communist Chinese units so they have to be within 9 hexes of a Communist controlled city. This number of hexes is greater than what is stated in WIF FE because of the MWIF change in scale for China.
• Overrun naval units in iced-in ports, although having rolled well and being permitted to escape, are instead destroyed.
• Which major power decides about continuing to fight or abort from a naval combat is redetermined at the end of each round, and is decided by the major power on each side that has the most units still capable of fighting in the sea area.
• The WIF FE rules weren’t clear as what should happen when the Collapse of Vichy France causes Vichy France controlled minor countries to become owned by an Axis major power which has a unit present in the minor country. For instance, if Italy has a unit in Tunisia (which is controlled by Vichy France), then the rules state that Tunisia goes to Italy. But the rules say nothing about if there are both German and Italian units present. I decided to count the number of units and ‘give’ the country to the Axis major power with the most units present.
• Vichy France can be both hostile to and/or at war with Allied major powers. I revised the Relations form so those conditions are shown accurately.
• I fixed a bug in declaring Vichy France when non-French naval units are forced to rebase. This is the one place in the rules where ‘overrun’ naval units have to rebase to the nearest port, but can be intercepted when doing so. In all other cases the units either can not be intercepted, or else they have the freedom to choose any port within twice their range.
• I fixed a bug where liberating France while Vichy France still exists wasn’t converting all Metropolitan Vichy France hexes to French control.
• I fixed a bug so Vichy units can only move into hexes controlled by Vichy or by a country with which Vichy is at war.
• If France is liberated while Vichy France still exists, the major ports previously held by Vichy are undamaged when converted to French control. Usually when a major port changes control from one side to another, it becomes damaged. The problem this rule ‘interpretation’ avoids is having newly acquired French naval units overstacked in, say, Toulon.
• I added code so Vichy France can not build pilots or offensive chits.
• Minor country units are not permitted to enter the home country of another minor country on the same side unless Foreign Troop Commitment requirements have been met. That rule stops Hungarian units from entering Rumania, as one example. But in the case where the second minor country has been completely conquered, it seems that entry should be permitted. In one of the beta testers’ games the USSR had conquered Persia (which had been aligned to Japan) and then Italy aligned Iraq and had Iraqi units ready to enter and liberate Persia. Here the general rule would prohibit Iraqi units (minor country aligned to Italy) from entering Persia (minor country aligned to Japan, on the same side as Italy). But since Persia is completely conquered, it is now ‘owned’ by the USSR, with which Italy is at war, hence the Iraqi units are free to enter Persia. At least that is how I have coded it. My change is that if a minor country on your side has been completely conquered, then the FTC requirements no longer apply.
• Land units can now only be loaded on air transports if they are organized (Harry Rowland clarified this rule).
• I changed the code so when the US claims Greenland/Iceland/Northern Ireland, units belonging to other Allied countries therein are relocated to the nearest hex, rather than rebased. As part of claiming Northern Ireland, the US is permitted to place convoy reinforcements in Ireland - but not any other type of unit.
• I fixed a bug where the US was being permitted to DOW another major power after failing in an attempt to DOW a major power during the same impulse.
• When the US DOWs both Germany and Italy in the same impulse, two separate die rolls for US Entry are made. Furthermore, those die rolls and the associated mandatory movement of US Entry markers from the Entry Pool to the Tension Pool are made prior to the implementation of the optional movement of markers due to the automatic execution of US Entry Options. The automatic execution of US Entry Options only occurs if the US is at war with both Germany and Italy (or those countries have been completely conquered). This is another instance where Harry Rowland clarified the rule. There are a couple of more subtleties to this rule which are now coded correctly in MWIF.
• I implemented the following rule interpretation: Unit U is not permitted to fly to a naval combat sea area if:
(1) U's controlling major power is surprised by all the enemy units in the sea area, or
(2) all units friendly to U in the sea area are neutral or surprised [by all enemy units in the sea area].
• I fine tuned the code so land based air units that voluntarily abort from a naval air combat are handled differently from those that abort under any other circumstance. If they voluntarily abort from an air-to-air combat, then they return to the sea box section from which they entered the naval combat. If they otherwise abort, they must return to base (i.e., to a land hex) where they are disorganized.
• I removed the ability of land attacks being declared against a hex containing only enemy supply units.
• I enabled conducting ground strike and carpet bombing missions against a hex containing units with which you are not at war, if the hex is controlled by a country with which you are at war.
• AA units that fire during the ground support phase are not disorganized until after the Advance After Combat subphase.
• I fixed a bug where attacked partisan units were able to receive ground support from countries other than their controlling major power.
• I changed the test for conditions under which the Nazi-Soviet pact can be broken. Specifically, setting up or moving units within one of the countries listed for breaking the pact (e.g., Turkey, Sweden), no longer qualifies for breaking the pact, regardless of to whom the minor country is aligned. Basically, as long as the only units you move in the specified minor countries belong to the minor country itself, then the conditions for breaking the pact are not met. But if you move a unit from a different country into one of the listed minor countries, then the other side can break the pact. For example, if the USSR DOWs Turkey, which is then aligned to Germany, and Germany moves the Rumanian HQ into Turkey, then the USSR can break the pact. However, moving an Italian unit into Turkey would not affect the status of the pact, since Italian units are not controlled by Germany. This applies not only while setting up units, but throughout all phases of the game (e.g., including air units returning to base).
• When the US player has the option to move, or not to move, markers from the Entry Pools to the Tension Pools and there is more than one marker to be moved for an entry option, he has to either move all the markers for the entry option or none. The US player gets this choice when US Entry Options are made automatically after the US goes to war with Axis major powers.
• The requisite conditions have to be met before the US can occupy Greenland and Iceland even when that US Entry Option is ‘automatically’ selected due to the US going to war with both EuroAxis major powers.
• Allied units in Italy that count towards the conquest of Italy garrison value must be controlled by a country at war with Italy (clarification from Harry Rowland).

Failures in the CWIF code for determining supply was something I discovered within the first 15 minutes I had access to a copy of the game. That was a month before I became involved in this project. I ignored that bug, and other supply bugs, for over 6 years but finally bit the bullet and tackled rewriting supply in earnest on November 1st. Actually, I had done a significant portion of the ground work for the rewrite back in 2009, but there was a lot left to do. I won’t go into the gory details here but there are many rules concerning supply sources and paths that increase the level of difficulty in writing the code. In particular, differences between major powers and minor countries, and cooperation between countries was a pain. I have supply mostly working now and will hand it off to the beta testers this week. Still remaining is the problem of getting the program to update the supply status of all units instantaneously and continuously during the land and naval movement phases (i.e., after each unit is moved).

Player Interface
I created 6 new forms in 2011:
• Supply Sources and Paths. This identifies all the supply sources, primary and secondary, and shows how many units are being supplied by each. When you click on a supply source, the supplied units are shown in a list at the bottom of the form. For secondary supply sources, the supply path it uses to reach a primary is shown. Clicking on a unit image causes the supply path for the unit to appear. There is a special button for displaying all the units and secondary supply sources that are out of supply.
• Liberation. This tiny form simply asks a player if he wants to liberate, revert, or ‘neither’ when he controls the capital of a country that was on his side originally. The change here is to include the option to revert. Liberation of a minor country means it is aligned to its liberating major power. Reversion means it is aligned to the major power to whom it was originally aligned. If you do neither, then it is conquered by the major power controlling the capital. This is a ‘nag’ form, since if you choose neither, then you will be asked the same question again at the end of the next turn. I really dislike having ‘nag’ forms in the sequence of play but I couldn’t come up with another solution and remain true to WIF FE, where you can liberate/revert a minor country during any later turn if you so desire.
• US Entry Actions. This form is purely informational but I think compared to RAC it is a much cleaner presentation of the information. Hopefully having this accessible from within a game will make these concepts easier for new players to understand.
• Private NetPlay Forum. This form is used by players to find opponents for NetPlay (i.e., playing over the internet). It is only available to players who have purchased the game, and is accessed from the Opening MWIF screen. It is also used for each game session, letting players restart/join their game in progress.
• Keyboard and Mouse Commands Help.
• About the Current Game. This reports which scenario is being played, mode of play, and which players are playing. It is of minor importance for game play but is helpful for debugging purposes.

I substantially modified 7 existing forms:
• OverStacked. I revised where in the code checks for overstacking occur. When overstacking is detected, this form appears.
• Choose Naval Combat. The changes I made here give more emphasis to the list of sea areas. These modifications were part of a general revision of the form to fix a few bugs.
• Drop Off Units. The changes here clarified what happens when a group of naval units enters a port. It was easy to get confused when some of the naval units stopped in the port, while others in the moving group picked up cargo and continued moving.
• Select Units. The change was the addition of filters for movement points and range. For example, when examining a large stack of naval units, you can quickly select just those with 6 movement points. I also increased the size of the form so more units are visible.
• UnitData. This data summary panel now shows if a unit is flying a night mission and/or at extended range. This helps when returning air units to base after an air mission since now you know which ones flew at extended range. It also is of value when choosing targets in an air-to-air combat and for anti-aircraft fire.
• Status Indicators Help. This needed to be updated, especially the graphics, because it was a year out-of-date.
• Chat. CWIF had 3 forms for sending a message: Chat, New Message, and Recipients. I reduced that to a single form. The list of who receives a message isn’t very long, since is a maximum of 6 players in a game. The form now just has a checkbox for each player.

Within 9 minor forms I replaced a CWIF component for grids (TSimpleGrid) with one from the JEDI library (TJvStringGrid). The former was generating program crashes when the mouse wheel was touched while the grid was displayed. Visually there is no apparent difference. But TJvStringGrid does not crash the program, so the day I spent making the changes was well spent. I’ve now standardized on the use of TJvStringGrid throughout MWIF; it appears in 85 places.

I updated the Unit Status Indicators because there was a ‘hole’ in the design logic. Land based air units at sea during naval combat, which were not participating in the combat, were shown without any status indicator. I added a new value for these units to indicate that they are ‘flying’, even if they are not part of the naval combat. Another set of changes I made to the unit status indicators was to clarify when a unit was receiving HQ support and/or engineer support in a land combat. And to accompany the changes made to the UnitData panel mentioned above, I added indicators for units flying night missions and/or at extended range.

I added a couple of shortcut keys to access the US Entry Pools and US Entry Action forms. The third form in this group is the new US Entry Options form mentioned above. Together with the new section on US Entry that Aaron put together (see Players Manual below), these 3 forms should make it easier to learn this crucial game concept.

I imposed a restriction on moving land units so you are no longer able to partially move a unit, move a second unit, and then go back and continue moving the first unit. Doing this would violate the WIF rules. However, you are permitted to continue moving a stack of units that performed an overrun if you do so immediately after any overrun air and/or naval units have finished rebasing.

Internet - NetPlay
Rolf and I finished the conversion of CWIF’s Windows Messaging code for communicating over the internet to MWIF’s Game Record Logs. Rolf did a couple dozen, including some of the most difficult items which involve moving units. I did the final 80. The code now exclusively uses Game Record Logs and Indy10 (a Delphi software library that employs TCP/IP for internet communications).

The number of unique record types is around 400, one for each decision/event that occurs in the sequence of play. That number will probably increase slightly once we get heavily into testing NetPlay. For example, there are a bunch of optional rules which will need their own personal GRLs (e.g., Guard Banner Armies, Kamikazes, and Naval Supply Units). On average, each conversion required about 50 edits, spanning a dozen different modules. Making those 20,000 edits was spread out over several years, since I knew they would be onerous to do and had been chipping away at them off and on since way back when. With Rolf’s help I was able to finally finish them off.

The conversions to GRLs were essential for NetPlay and PBEM (that is: whenever more than 1 computer is being used). The most difficult were for moving units, especially naval moves, because of all the information required to keep track of exactly which units are moving through which hexes to reach their destination. Another reason behind creating the GRLs is that I am a firm believe in compartmentalized software. The GRLs isolate and completely remove NetPlay and Message Control code from all the details of how the game/simulation operates. NetPlay gets a simple string value with an identifier (ID number). It then sends it to its twin on another computer. That the game being played is World in Flames never impinges on the NetPlay code. To be clear about this, the code for NetPlay and the code for the game’s simulation of WW II are mutually exclusive.

As stated at the beginning of this report, Mitchell completed NetPlayComTest, version 2.0 which I then integrated into MWIF. It can be called either as a stand alone program or from within MWIF when a game is in progress. For those of you who don’t know, NetPlayComTest uses Indy10 to send and receive messages over the internet. It deals with all the issues of establishing communications between two or more computers. Then it permits the users to send messages back and forth. Its original purpose was to test the software for use by MWIF proper. But it will be included in the released product so players can test their communication links without having to run the game itself. If as a player you get NetPlayComTest to work for communicating between all the players in your game, then MWIF should run NetPlay without problems. Some of the issues it needed to deal with are IP addresses, port numbers, and firewalls - all that good stuff.

In December I added the ability of MWIF to access the Private MWIF NetPlay Forum. This forum is used by players to find opponents for NetPlay (i.e., playing over the internet). It is only available to players who have purchased the game. Access to the forum is via a button on the Opening MWIF screen. Besides finding opponents, it is used to start each game session, letting players restart/join their game in progress.

PBEM
Nothing new other than the decision to use the MultiPlayer++ system developed by Slitherine/Matrix Games for locating a PBEM opponent. This is the same underlying system used by the Private MWIF NetPlay Forum.

Artificial Intelligence (AI)
Peter finished the geographic breakdown for the AI Opponent. To go with that, I revised the documentation on the AIO command structure so each element of the geography has a corresponding decision maker. There are 16 Theaters of Operation (TOs) that span the global map. Within each TO there is a breakdown for naval units into Sea Area Groups (which contain individual Sea Areas) and for land units into Areas of Operations (which contain Land Regions).

I changed the fundamental map data structure to include information on the geographical breakdown. This should have zero effect on game play as far as human players are concerned. The change to the Terrain data adds a new field to each land hex to store the Land Region ID #. Along with this I added a new field to the Sea Area data to store the Sea Area Group ID #. And as the final pieces, I created simple files listing the Theaters of Operation, Areas of Operation, Land Regions, and Sea Area Groups which hold the details on each of those elements, including cross references. In practice, this means that the AI Opponent code can trace any land hex back to its LR, AO, and TO, and can trace an all-sea hex back to its sea area, SAG, and TO. In order to validate the new data I added a (debug) line under the Main form that shows and updates the TO, AO, LR, and SAG values as the cursor is scrolled across each hex.

The 16 TOs are: Western Europe, Eastern Europe (up to Siberia), Mediterranean, East Africa, West Africa, Middle East, North Asia (i.e., Siberia), South Asia (i.e., India), East Asia (i.e. China & Japan), Southeast Asia, Oceania (i.e., Australia), Pacific Ocean (central), Atlantic North America, Atlantic South America, Pacific North America, and Pacific South America. There are 126 AOs and 320 LRs. The major task remaining is to change the data file for the terrain, adding a digit to the end of the row of data for each land hex. There are 70,200 hexes, each of which has its own row of data. Mercifully, the all-sea hexes do not need to be edited (they use the default value).

The greatest advantage that a human player has over the AIO is the ability to literally ‘see’ the map. For the AIO it is just a bunch of incohesive data. Using the geographical data, the AIO can now assess the strength of the forces on both sides in a land region and decide whether to attack, maneuver, defend, or retreat. The same applies to AOs, SAGs, and TOs. This is my best attempt to mimic a human player simply looking at the map and making a quick assessment of the relative strengths of the two sides.

Another goal here was to provide a hierarchy of decision makers for strategic and operational decisions and a different decision maker for tactical decisions. For instance, decisions about convoy routes span multiple sea areas and are made higher up in the chain of command, while decisions concerning a specific naval combat are made by the Fleet Admiral responsible for the sea area in which the combat is taking place. Likewise army reinforcements are shipped off to various TOs, whose commander designates which AO gets them; the AO commander then designates a Land Region, whose Commanding General decides in which hex to place the new unit.

After completing the geographic breakdown of the entire global map (a massive task which required assessing all 70,200 hexes), Peter worked on the data structures for AIO strategic plans. I had already done some preliminary work on that. The goal is to design variables for holding all the information necessary to define a strategic plan for a major power. The 3 main elements are: (1) objectives to hold/take, (2) geographical areas to defend/attack, and (3) time lines for declarations of war/offensives, with accompanying production schedules.

Some of the strategic plan data defines conditions for when something should happen (e.g., when to start building garrison units). Defining data structures for conditionals is always difficult, but Peter and I already did some of that when we were working on setup scripts. It isn’t easy to take the amorphous advice provided by the forum members and render it into a rigidly structured outline for processing by a computer program. For instance, late in the year he was grinding out the precise conditions under which France should surrender.

Rolf made some progress on completing the parser for LAIO (Language for an Artificial Intelligence Opponent) scripts.

Rules as Coded (RAC)
I made a couple of changes to bring RAC up-to-date with MWIF deviations from Rules as Written (RAW). For instance, I added a description of the Naval Abort Queue. On August 1st I uploaded the final version (number 46!) of RAC for the Matrix Games Editor.

Player’s Manual
After querying forum members, Aaron wrote up a new subsection for section 3.4, Advice to Players: Understanding US Entry Options, Actions, and Pools. Composer99 provided the heart of this material. I made some final edits and now new players should have a better chance of understanding this crucial aspect of the game.

I added a subsection on Dropping Off Units to the Players Manual. That form is used for both dropping off units and, when in port, picking up cargo while passing through. I reviewed and updated section 10 of the Players Manual so it accurately lists all the RAC deviations from Rules as Written (RAW).

Aaron read through and made numerous changes/suggestions to the largest section of the Players Manual: 8 Players Interface. Equally important, he updated all the screenshots (~250) in the Players Manual. In many cases they had become woefully out of date.

The biggest editing changes Aaron made were for Production Planning. That form is very complex, since the tasks of fulfilling trade agreements, routing resources to factories, and saving oil/build points can potentially span the world map. Those are also critical tasks, since they directly affect production. Every player wants maximum control over these decisions, and a clear understanding of what is happening for his major powers, as well as for those commanded by other players.

What Aaron and I decided upon was to add a dozen or so small insert figures that are pieces of the overall Production Planning form. This means that when the text discusses, say, Filters for the resources and factories list, a little picture of the set of Filter radio buttons is shown. The overall effect is that it is much easier to understand the text by referring to the little figures instead of having to look back to a previous page and locate where the Filters are on the full-page form. I am now real happy with how this section reads, instead of being anxious about it being incoherent.

The beta testers were provided with the latest and greatest version of the Players Manual after Aaron’s revisions, and given the opportunity to make suggestions over a 2 week period. Aaron collected their comments and added another bunch of his own. While integrating that input into the draft, I read through all 400 pages of the Players Manual and made over 500 edits of my own. After typing in all these changes, on August 1st I uploaded the Players Manual with the up-to-date screenshots for the Matrix Games Editor.

I have a handful of small edits waiting the Matrix Games editor that I have accumulated since August 1st. There is only 1 glaring hole remaining in the text for the Players Manual: NetPlay instructions for starting, joining, and resuming a NetPlay game. There are a couple other bits associated with that too: chatting with other players and monitoring internet communication links.

Tutorials, Training Videos, and Context Sensitive Help
There is one missing screenshot for the Picture and Text Tutorials: Starting NetPlay game. The other 120+ pages are done and final.

This year I finished the design and code for the Interactive Tutorials. Each of the 10 tutorials will have a dozen or so ‘pages’ with 6 lines of instructions on the ‘front’ of each page and 7 lines of commentary on the ‘back’. The player can toggle between the front and back of each page, seeing either very terse instructions for entering keyboard and mouse commands, or commentary. The latter is the equivalent of a “voice over”. After performing the actions indicated by the instructions, the player clicks on the Next button to advance to the next page. I wrote a few sample pages to test the code and system design, but another 100+ pages of instructions with commentary need to be authored.

Throughout the year I made changes to the context sensitive help messages based on feedback from the beta testers. These are roughly 80% complete. The remaining 20% is not that difficult to do, since creating the missing content is done by cutting text from the Players Manual and pasting it into a TXT file.

I reviewed the training videos I made about 2 years ago. All 9 of the chapters I recorded have small discrepancies when compared with the current version of the game. But to my eye those are minor differences, and not worth re-recording an entire chapter. However, I need to redo chapter 6, since it references the production planning form and uses a completely out-of-date screenshot of that form. And chapter 9 also need to be redone because the Land Combat Resolution form has been substantially modified. But the other 7 chapters I think I’ll leave as is. I still have 3 more chapters to do: 10, 11, and 12, which cover naval movement, naval combat, and production & politics (i.e., declarations of war et al).

Here are the 12 chapters of the training videos.
Chapter 1 Introduction (4 minutes :10 seconds)
Chapter 2 Map Basics (20:27)
Chapter 3 Unit Basics (28:27)
Chapter 4 Sequence of Play (33:56)
Chapter 5 Turns, Impulses, Weather, & Supply (25:28)
Chapter 6 Main Form, Screen Layouts, & Map Views (46:31)
Chapter 7 Starting a New Game & Setting Up Units (55:40)
Chapter 8 Air Movement & Combat (23:43)
Chapter 9 Land Movement & Combat (43:46).
Chapter 10 Naval Movement (TBD)
Chapter 11 Naval Combat (TBD)
Chapter 12 Production & Politics (TBD)

Historical Video, Music, and Sound Effects
David Heath sent me the (nearly) complete set of music and sound effects files. I still need to insert ‘calls’ in the code to play these files at the appropriate points in the sequence of play. My design lets the player set how often the sound effects et al are played. That can range from never, to periodically, to always. Periodically would be something like: “every 10th time an armored vehicle moves play the sound effect.”

Marketing
Aaron worked with Sean Drummy of Matrix Games on updating the World in Flames screenshots displayed as part of the game’s description in Matrix Games’ list of products. Virtually all of them had been out-of-date.

[composer99]

Looking good.

[brian brian]

movement on desert lake hexes in blizzards - nice catch! (among scores upon scores this year it sounds like)

[brian brian]

oh, and forgot .... destroying your own blue factories. you learn something new about WiF all the time, had never heard of / thought of such a move.

[Red Prince]

ORIGINAL: brian brian

oh, and forgot .... destroying your own blue factories. you learn something new about WiF all the time, had never heard of / thought of such a move.

We've been trying to figure out anything and everything that the rules seem to allow. Since this is a computer program, and there is no referee or "house rules" negotiations, we want to cover as many possibilities as we can.

Particularly when playing Solitaire, you can test out tons of crazy strategies that would probably never come up in a real game. For example, when I was testing to see if a completely conquered Minor which had its own "governed areas" (territories without cities, like the Azores or Galapagos Islands) ended up reverting those areas to Neutral status as "new" minors, I had situations set up which had Italy invade Mexico, France invading Argentina and Spain, and Japan invading Peru, among others. This test led to the fix that allowed those territories to become Neutral, but it also showed me a lot of possibilities that the rules don't really deal with -- since they are extremely unlikely to happen.

This is pretty much what Steve means by his "fine tooth comb" references. There is, in fact, a thread in the development forum specifically for these kinds of ideas to be posted, and many of them have been solved, once the realization that they needed a solution was made.

Jimm nearly worked himself into insanity getting all of the Italian conquest possibilities to play out correctly, and as Steve mentioned, Rob W. has worked extensively on several different projects which have resulted in clarifications and a more "complete" application of the RAW and RAC.

This work has been amazing and outstanding, and extremely valuable. Thank you for the time you put in. And all the other beta-testers, too, have done similar (sometimes tedious) tasks. There are just too many to mention them all.
[&o][&o][&o]

[Centuur]

I noticed this in the review:

"I added a graphic to visually indicate when captured red factories are not producing. I still need to figure out how to indicate visually that a factory has lost a production point"

I would suggest to use four kinds of graphics:

Factories capable of production: smoke out of the stacks.
Non producing red factories: no smoke out of the stacks.
Attacked factories with loss of production point: a yellow flame symbol on the non-smoking stack (yellow stands out of both blue and red). This indicates an succesfully attacked working factory which isn't destroyed, but has lost it's production capability for this turn, due to the damage done by the enemy attack. Imagine the firefighters and repair crews crowding over the place...
Destroyed/damaged factories: pile of rubble (in the right colour of course)...

Is that an idea?

Also: I've stumbled on the map on an empty square, indicating a railed out factory. I don't like the way that's looking (it isn't nice looking, and everything else on the map is so, so very good looking, that that white square is awful to my eyes...). Isn't it possible to indicate a railed away factory by using a white stack in such a square (since only the shell of the factory is still standing, and everything else what was in there has left)?

Edit: I'm just curious: how are you indicating a damaged Major Port on the map?

[Red Prince]

Edit: I'm just curious: how are you indicating a damaged Major Port on the map?

Unfortunately, I don't have an image of it to show you, because I'm not using that option in my current game, but basically it is a surrounded by a red circle with a line through it . . . kind of like a "No Smoking" sign.

[Orm]

Edit: I'm just curious: how are you indicating a damaged Major Port on the map?

[Shannon V. OKeets]

ORIGINAL: Centuur

I noticed this in the review:

"I added a graphic to visually indicate when captured red factories are not producing. I still need to figure out how to indicate visually that a factory has lost a production point"

I would suggest to use four kinds of graphics:

Factories capable of production: smoke out of the stacks.
Non producing red factories: no smoke out of the stacks.
Attacked factories with loss of production point: a yellow flame symbol on the non-smoking stack (yellow stands out of both blue and red). This indicates an succesfully attacked working factory which isn't destroyed, but has lost it's production capability for this turn, due to the damage done by the enemy attack. Imagine the firefighters and repair crews crowding over the place...
Destroyed/damaged factories: pile of rubble (in the right colour of course)...

Is that an idea?

Also: I've stumbled on the map on an empty square, indicating a railed out factory. I don't like the way that's looking (it isn't nice looking, and everything else on the map is so, so very good looking, that that white square is awful to my eyes...). Isn't it possible to indicate a railed away factory by using a white stack in such a square (since only the shell of the factory is still standing, and everything else what was in there has left)?

Edit: I'm just curious: how are you indicating a damaged Major Port on the map?

You're on the right track. Destroyed factories are shown as Black - they can be repaired in some instances. I also use Green factories for those that are newly built (they can not be repaired when destroyed so they simply disappear if that happens). But playing with the color of the smoke is a possibility. Red versus Black, for instance.

These are tiny icons so nothing too subtle will work.