MWIF Monthly Reports

[Shannon V. OKeets]

August 1, 2013 Status Report for Matrix Games’ MWIF Forum

Overview
Roughly speaking, on January 1st of this year the game was 98% done. Sometime in the spring, it reached 99% (when the code for Supply completed alpha testing and went into beta testing). Since then I’ve been working on the first decimal place, and as I write this I believe the game is 99.9% done. That is, I’m working on the second decimal place. Given that there are ~420,000 lines of code, 0.1% translates as 420 lines of code. That doesn’t convert directly to a specific number of bugs, but the current bug count under 100 seems about right. Now I just need to grind away at the remaining bugs.

As a footnote, this is the 8th anniversary of my monthly status reports on MWIF. By another accounting, I am starting my ~99th month of work on the game.

Accomplishments of July 2013

Hardware and Software
The open items for Theme Engine remain the same: minimizing the game generates a Mad Except error, trying to display detailed listings of file directories (i.e., the dates and stuff) when opening or saving a file does the same, and “rolling up a form” does too (the last occurs sporadically under Windows XP). Rolling up a form minimizes the form to the size of the form’s top bar.

Beta Testing
In July I released 5 new versions to the beta testers: 10.05.01 (26 fixes), 10.05.03 (11 fixes), 10.05.04 (22 fixes), 10.05.05 (10 fixes), and 11.00.00 (13 fixes). Version 10.05.02 was not given to the beta testers - I used it in alpha testing. The number of new versions and fixes (82) are about my average for this year.

Release 10.05.01 fixed all but 2 of the Naval Combat bugs, which need saved games for me to recreate them. The beta testers then found some more bugs in naval combat, which is par for the course. I’ve now developed a theory for complex phases of the game that when I cut the number of bugs in half, the beta testers bump it back up by half, and the cycle repeats: 32 => 16 =>24 => 12 => 18 => 9 ... The bugs in naval movement, naval combat, Vichy France creation, supply, and production planning were all like that.

Releases 10.05.02 and 10.05.04 fixed all but 3 Supply bugs, which were minor. As above, the beta testers have since found more for me to fix. It wasn’t until the 20th of the month that I managed to devote my time and effort exclusively to fixing NetPlay bugs. The NetPlay bugs remaining aren’t a big concern; half of them are new within the past few days and I’ve done a lot of work on 4 of the older ones (see the NetPlay section below for more details).

Here is a summary of my Master Task List (MTL) as of August 1st. My task list count stands at 95, up from 93 at the start of the month. At one point I had the bug count down to 72 - sigh. Recently I’ve been torn between finishing debugging NetPlay and knocking the bug count in the sequence of play back down below 40. Many of these bugs are recent (high numbers) - which means I haven’t really looked into fixing them.

NetPlay [9] {1594, 1859}, 1785, 1826, 1827, 2056, 2099, 2100, 2101, 2107

Sequence of Play [65]
Supply [11]: 1070, 1982, 1988, 2061, 2064, 2078, 2083, 2086, 2088, 2089, 2106
Setup Phases [1]: 2093
DOW [1]: 2094
Air Missions [8]: 1611, 1890, 1925, 1996, 2052, 2103, 2105, 2082
Naval Movement [1]: 1990
Naval Combat [4]: 1599, 1724, 874, 2104
Land Combat Declaration [1]: 1995
Reorganization [3]: 1855, 1856, 1896
Use Oil [2]: 2042, 2091
Production Planning [16]: 1107, {847, 961, 1347}, 326, 1644, 1671, 1825, 1862, 1863, 1864, 1893, 1895, 1973, 2006, 2014, 2020, 2084
Search Seizure [1]: 409
Conquest [2]: 1047, 2050
Vichy [5]: 1803, 1811, 2017, 2028, 2063
Surrender [2]: 2009, 2073
Liberation [3]: 891, 1919, 1980
Victory [1]: 2090
Overstacked Digression [2]: 1931, 2074
Final Reorganization [1]: 1733

Non-sequence of Play [21]
Detailed Map [7]: 1188, 142, 769,140, 1501, 2036, 1956
Player Interface [5]: 1901, 1920, 1922, 2048, 2077
Interactive Tutorial [1]: 2043
Game Save/Restore [5]: 695, 110, 118, 1778, 1907
Theme Engine [3]: {1050, 568}, {1513, 1467, 966, 1455, 1573, 1655}, 1928

Saved Games
Done, except for the bugs listed above.

Map, Units, and Scenarios
As I get additional unit writeups I add them to the collection.

Optional Rules
The optional rule Off-city Reinforcements appears to be bug-free at this point; a couple of months ago I wasn’t sure if it would be ready for the game’s initial release. There are 6 optional rules that are partially coded and which I doubt will be ready for the game’s initial release. But when they are finished, they will be sent to purchasers of the game as patches: City-Based Volunteers, Kamikazes, Naval Supply Units, Guards Banner Armies, Rough Seas, and the uncoded rules for special unit types in Convoys in Flames (i.e., German auxiliary cruisers, sub-hunters, specialized submarine types, tankers).

Game Engine
Other than fixing supply bugs, nothing has really changed regarding the game engine. I have no tasks related to this remaining.

Player Interface
Done, except for the bugs listed above. Like for the game engine, I have no tasks related to this remaining.

Internet - NetPlay
I spent a lot of July on NetPlay. As before, many of my corrections do not show up as bug fixes. In July the classic case of that was the end-of-turn phases. MWIF has 35 phases prior to the end of turn and 28 phases thereafter. This past month I was able to run a NetPlay game through all the end-of-turn phases, although that was with some optional rules turned off (e.g. Use Oil) and some of those phases are not planned for the game’s initial release (e.g., Intelligence, Ukraine). But still, all those phases completed and moved smoothly to the next phase in the sequence of play on both computers. I also debugged the start of new turn phases that are skipped for the first turn: Reinforcements, Lending, and Initiative/Moving First. This required a lot of work, with half the 60+ phases having some small problem that needed to be identified and corrected. On my task list this shows up as one bug ‘fixed’. Testing that code is now in the hands of the beta testers.

Somewhat annoying is that messing around with the code to implement NetPlay occasionally causes bugs to appear in the sequence of play for Solitaire mode, in phases/subphases that have been stable for months, sometimes years. These aren’t difficult to fix, but it feels like a blindside tackle at times.

I still have some combat bugs to fix for NetPlay in air-to-air, naval, and land combat. In all these cases the problems arise when assigning combat losses or other effects. Letting both players choose which units to destroy/damage/abort/shatter and presenting those choices to the decision player is what’s difficult. Sometimes one player chooses (e.g., naval surface combat), sometimes alternating players (e.g., naval air combat), and sometimes both (e.g., land combat where both sides take losses but fewer than they have units engaged in the combat). The combat phases have multiple subphases and the sequence of play loops back for either additional combats and/or additional rounds in the same combat. It’s just very complicated logic to keep both computers synchronized as these subphases are executed and the decision makers switch back and forth. If the code’s not perfect, it’s wrong.

Most of the phases with long subphase sequences have been or are close to being debugged for NetPlay. The only one not tested so far is the creation of Vichy France. Once I get the combat stuff working, I’ll start testing that.

PBEM
Nothing new.

Artificial Intelligence (AI)
Nothing new. But Peter S. is anxious to get back to work on this - as am I.

Player’s Manual and Rules as Coded (RAC)
Work continued in July (by others, with proofreading by me) on completing the final layouts for the Players Manual and Rules as Coded. Those are pretty much done at this point. There are some ad hoc details remaining, concerning artwork and finishing a professional index for the Players Manual. Did you know (I didn’t) that there are people who are professional indexers? Usually they are given a fixed number of pages for the index and develop one to satisfy that requirement. For MWIF I created a list of 400-500 key words for the Indexer to work from.

I still intend to post a few sample pages of the Players Manual to the World in Flames forum once it is ready for printing.

Tutorials and Training Videos
Nothing new on completing the training videos. I listened to a couple of them this past month and haven’t changed my mind about which are okay as is and which need to be re-recorded.

Historical Video, Music, and Sound Effects
Nothing new.

Web Site
Nothing new.

Marketing
Nothing new.

[Shannon V. OKeets]

September 1, 2013 Status Report for Matrix Games’ MWIF Forum

Note:
I’ll be traveling to Philadelphia in the last week of September for the second annual followup at Wills Eye Hospital for the surgery on my left eye’s melanoma. Next month’s status report will most likely be a day or two late.

Accomplishments of August 2013

Hardware and Software
I purchased replacement headphones for completing the recording of the training videos. Lovely Hawaiian salt air had dissolved all the thin plastic elements in my old ones. Complementing that purchase, I upgraded my copy of the Camtasia software from version 5 to 8.1; Camtasia is for recording a video of an executing program with audio voice-over.

The three open items for Theme Engine remain the same.

Beta Testing
In August I released 4 new versions to the beta testers: 11.00.01 (18 fixes), 11.00.02 (29 fixes), 11.00.03 (1 fix), and 11.00.04 (10 fixes). Release 11.00.03 fixed a fatal bug that was preventing the beta testers from testing new games. The numbers of new versions and fixes (58) are below my averages. That’s because of the time I spent on the final preparation of the printed material and redoing a couple of the training videos. The former are on the critical path for releasing the game. For the latter, I wanted to re-familiarize myself with the process, since I still have 3 training videos left to do, and the last time I did one was four years ago.

I cleaned up a couple dozen odds and ends in the world of existing bugs, but spent the bulk of my debugging time on NetPlay. I now have all 8 air missions executing correctly in NetPlay. More on that below.

Here is a summary of my Master Task List (MTL) as of September 1st. My task list count stands at 86, down from 95 at the start of the month. However, there are another 17 posts from the beta testers I haven’t checked into yet. Bugs can be corrected quickly (as per the 47 fixes for the first two new versions this month), or slowly, like the last 5 days I’ve spent working on the Naval Combat bug(s) in NetPlay. Grind, grind, grind.

NetPlay [6] 1785, 1826, 2056, 2099, 2100, 2101

Sequence of Play [58]
Supply [13]: 1070, 1982, 1988, 2061, 2064, 2078, 2083, 2086, 2088, 2089, 2106, 2128, 2130
DOW [1]: 2094
Air Missions [5]: 1611, 1890, 1925, 1996, 2117
Naval Movement [1]: 1990
Naval Combat [2]: 1724, 874
Land Movement [1]: 2118
Land Combat Declaration [1]: 1995
Use Oil [2]: 2042, 2091
Production Planning [21]: 1107, {847, 961, 1347}, 326, 1644, 1671, 1825, 1862, 1863, 1864, 1893, 1895, 1973, 2006, 2014, 2020, 2084, 2111, 2112, 2113, 2122, 2126
Search Seizure [1]: 409
Conquest [1]: 1047
Vichy [5]: 1803, 1811, 2017, 2028, 2063
Liberation [1]: 1919
Overstacked Digression [2]: 1931, 2074
Final Reorganization [1]: 1733

Non-sequence of Play [22]
Detailed Map [7]: 1188, 142, 769,140, 1501, 1956, 2121
Player Interface [5]: 1901, 1920, 1922, 2048, 2077
Interactive Tutorial [1]: 2043
Game Save/Restore [6]: 695, 110, 118, 1778, 1907, 2123
Theme Engine [3]: {1050, 568}, {1513, 1467, 966, 1455, 1573, 1655}, 1928

Saved Games
Done, except for the bugs listed above.

Map, Units, and Scenarios
As I get additional unit writeups I add them to the collection.

Optional Rules
Nothing new.

Game Engine
Other than fixing supply bugs, I have no remaining tasks related to this.

Player Interface
Done, except for the bugs listed above.

Internet - NetPlay
I spent at least half my time in August on NetPlay.

Debugging the NetPlay code is some of the most difficult programming I've ever had to do. I need to keep two images of the code in my head with each computer at different points in the code, with different values for their internal variables. And then I need to envision the actions by the two players causing messages (Game Record Logs) to be sent between the computers which change the status of variables. Besides the normal stuff of timers to control the transmission, receipt, queuing, and processing of messages between computers, I also have the program running timers in some phases waiting for players to make open-ended decisions about what should happen next. Currently I have 582 GRL record definitions for all the different actions that can happen during a game.

I finally got Port Attacks to work cleanly (a bug first reported in March), and I got air-to-air combat (first reported in February) finished as well. Port attacks have all the subphases of the other air missions as well as elements of naval combat (search numbers, excluding submarines, surprise points, and the naval combat results table). Air-to-air combat has 11 subphases with multiple rounds, and there can be multiple combats being resolved for any given air mission. Both of these have random assignments of which side makes decisions at various points in their processing. In NetPlay, having to disable one computer from taking any action while the other player decides what to do occurs a lot in the game. When it happens repeatedly while a complex form is visible on both computers, coding the process is extremely difficult. There are screenshots below showing the sequence of play for air-to-air combat and naval combat.

Naval combat is another bug first reported in February. Naval combat has 28 subphases and like air-to-air combat, there can be multiple rounds and multiple combats being resolved. This has been driving me nuts for the past 5 days. At the end of this report are some screenshots from debugging naval combat, port attacks, and air-to-air combat. The last two are bug free at this point.

In naval combat the program would get as far as the 10th subphase okay. When I put in debug messages to help me analyze the problems with going to the 11th subphase, the Axis computer would get stuck on the 3rd subphase. Because there are so many steps to recreate a problem, I thought I was doing something wrong with the mouse or keyboard on one of the two computers. Eventually I determined that it was merely the presence of the debug messages that was causing the program’s behavior to change. Tracking that down, I found that the timing loops would get out-of-sync if one computer took longer in responding to a debug message. Continuing backwards, I determined that the transition from subphase 0 to subphase 1 was where the real problem occurred. Fixing that, I was able to get the program to advance as far as the 6th subphase, where the Allied computer ran into trouble. As I write this I have gotten up to the 9th subphase (spending surprise points). I’m still trying to get back to the happy days earlier this week when my problems were in the 10th subphase.

While I hacked away at fixing the NetPlay code [picture me with a machete in the hot, humid jungles of Burma while mosquitoes feast on my exposed body parts], the beta testers (mosquitoes?) posted about 1 new bug a day. Mercifully, the importance of those keeps getting less and less, as far as actually playing the game. Some are critical; but some are about cosmetic stuff or "Gee, it would great if ...", which I dutifully record but am unlikely to do anything about for the initial release.

Most of the phases with long subphase sequences have been tested and debugged for NetPlay. The only one untested is the creation of Vichy France. I’ll have the beta testers start testing that next.

PBEM
Nothing new.

Artificial Intelligence (AI)
Nothing substantially new. Peter S. has been working on the strategic plans for Italy and I added a comment or three from time to time.

Player’s Manual and Rules as Coded (RAC)
These are at the printers. I’ll post some sample pages of the Players Manual to the World in Flames forum once I get permission to do so. By the way, the cover page for the Players Manual is my new desktop background.

Tutorials and Training Videos
I completed my review of the existing training videos, done in the summer of 2009 (four years ago). Of the 9 chapters that I completed that summer, 7 are still accurate:
2 Map basics (20 minutes, 27 seconds)
3 Unit basics (28:27)
4 Sequence of play (33:56)
5 Turns impulse, weather, and supply (25:28)
7 Starting and new game and setting up units (55:40)
8 Air movement and combat (23:43)
9 Land movement and combat (43:46)

This month I re-recorded chapters 1 and 6 which were woefully out-of-date. Chapter 1 is an Introduction to the training videos covering the Opening screen, with an overview of: (1) the picture & text and interactive tutorials, (2) the scenarios, and (3) restoring a saved game. It also examines the first page of the first tutorial: (1) general layout of the picture & text tutorial pages, (2) converting the board game to the computer, and (3) the unified world map. The new version runs 9 minutes and 13 seconds.

Chapter 6 covers the Main form, Information forms, Screen layouts, and Map views. My re-recording of this chapter increased the time from 46 minutes to 66 minutes, 5 seconds. The increase was primarily due to new material. From the Main form’s drop down menus two new forms are available: disabling phases by major powers and the supply sources and paths. Neither of those existed in 2009. Additional time was spent on the production planning form, which has been redesigned from top to bottom. It now provides a lot more information about resources, factories, convoy pipelines, and production/build points.

Disabling phases lets a player turn off some phases for major powers. For example, China rarely wants to perform port attacks or naval air missions, given its few precious air units. Rather than have the program cycle through China for those phases, requiring the player to click on the end-of-phase button, the program skips the phases completely for China if the player has disabled those phases. The main use of disabling phases is for CAP (Combat Air Patrol) for the eight air mission phases. CAP is rarely performed. When the Axis player is the phasing side, that results in up to 40 mouse clicks by the Allied player to end the CAP subphase in just one impulse - very annoying.

The supply sources and paths form didn’t exist in CWIF. I felt it was important to add this form for two reasons. First, new players can use this form to learn the supply rules. Seeing examples of all the supply sources for a major power and the paths that units trace to reach a primary supply source is the easiest way to understand how the system works. This also applies to all those board game players who have played the supply rules incorrectly for years (I know you’re out there). For experienced players, being able to find all the out-of-supply units for friendly and enemy major powers is nice. It’s also helpful to be able to see a report on opportunities for cutting enemy supply paths - and the vulnerabilities of your own.

I still need to record chapters 10, 11, and 12.

Chapter 10 Naval Review & Movement
10.1 Naval review
10.1.1 Units In Hex form
10.1.2 Flyouts form
10.1.3 Naval Review Details form
10.1.3.1 Plain display
10.1.3.2 Section display
10.1.3.3 Status display
10.1.3.4 Filters
10.1.3.5 Cycling through ports and sea areas
10.1.4 Double size global map
10.1.4.1 Sea area names
10.1.4.2 Working with the Units in Hex form
10.1.4.3 Working with the Flyouts form
10.1.4.4 Working with the Naval Review Details form
10.1.5 Naval Review Summary form
10.1.5.1 Filters
10.1.5.2 Working with the Naval Review Details form
10.1.5.3 Cycling through ports and sea areas
10.1.5.4 Saving and restoring displays
10.2 Selecting naval units for movement
10.2.1 Using the Select Units form
10.2.2 Using the Flyouts form
10.2.3 Using the Naval Review Details form
10.2.4 Using the Units In Hex form
10.3 Moving a group of naval units
10.3.1 To an adjacent sea area
10.3.2 To a distant sea area
10.3.3 Dropping off units: at sea & in port
10.3.4 Specifying a path of sea areas
10.4 Loading cargo
10.4.1 Starting in a port stacked with the cargo
10.4.2 Picking up cargo from a port when passing through
10.4.3 From a coastal hex upon arrival in a sea area
10.4.4 From a coastal hex prior to returning to port
10.5 Naval interception
10.5.1 Decision to try to intercept
10.5.2 Attempt to intercept
10.5.3 Decision to stop or fight through
10.5.4 Fighting through
10.5.5 Continuing movement after interception attempt and/or combat

Chapter 11 Naval Combat
11.1 Naval combat occurrences
11.1.1 Phasing side chooses
11.1.2 Non-phasing side chooses
11.1.3 Naval interception combat
11.1.4 Naval air support
11.2 Naval surface combat
11.2.1 Surprise points
11.2.2 Including units
11.2.3 Naval combat results
11.2.4 Multiple rounds
11.3 Naval air combat
11.3.1 Use of temporary carrier air units
11.3.2 Use of optional carrier air units
11.3.3 Air-to-air combat
11.3.4 Anti-aircraft fire
11.3.5 Air attack on surface ships
11.4 Naval submarine combat
11.4.1 Choosing combat type
11.4.2 Anti-submarine warfare (ASW) attack
11.4.3 Submarine attack on surface ships
11.5 Naval abort queue

Chapter 12 Production & Politics
Specifics will be the same as the material covered in the interactive tutorials #19 and #20.

Historical Video, Music, and Sound Effects
Nothing new.

Web Site
Nothing new.

Marketing
Nothing new.


Debugging NetPlay

There are 5 screenshots below. The last two show the sequence of play for air-to-air combat and naval combat. In those the flags indicate which major power is deciding in which subphase/sub-subphase. Tracking back to the top of a column and reading to the left, identifies the parent phase/subphase et al. For example, the air-to-air combat shown is for Ground Support, in the land combat ‘group’, in the land ‘stage’ of the sequence of play.

The other 3 screenshots are annotated debugging screenshots for naval combat, port attacks, and air-to-air combat (ground strike phase). Each of these has top and bottom panels, with the top for the GRLs sent and the bottom for GRLs received. The color of the screenshot indicates the viewing major power: blue for Commonwealth and grey for Germany. The horizontal red lines indicate when one side has completed sending a set of GRLs to the other side. The second number in each GRL is its “entry number”. These usually increment by one for each new GRL.

The first screenshot has black numbers on a yellow background to identify the order in which they were sent. So the naval combat screenshot (in blue) starts with [1] the Commonwealth receiving two GRLS from the Axis (#27093 and #27094) when the Axis player terminates naval movement for Germany and Italy. The Allied computer is always MasterMWIF and sends most of the GRLs ending phases/subphases and for rolling the dice. Here [2] it sends a Phase Done GRL (PhDo #27095) to change the phase to Naval Combat A (phasing side). Having determined that naval combat is possible, it then sends another PhDo (#27096) to change the subphase to Choose Sea Area. The Axis player [3] decides to initiate combat in the North Sea and selects which unit to use to initiate that combat (#27097). The process continues with GRLs being sent and received by both computers.

My annotations are mostly correct, but I was a little sloppy in places where perfect precision was irrelevant for debugging purposes. However, this degree of analysis is what is required to debug the NetPlay code. All of these screenshots are from the middle of August and I have since debugged the problems shown here. I should add that the code works correctly for the Solitaire and Head-to-head modes of play. It’s this jumping back and forth for who decides what when during NetPlay games that still has some flaws.

[Shannon V. OKeets]

Just a short note for this month.

In case you didn't hear already, the official release date for MWIF is November 7th.

I made my annual visit to Philadelphia following up on the treatment for the melanoma in my left eye. The cancer cells remain dead and are slowly being cleaned up by natural bodily processes. Its thickness has decreased from 5.1 mm in 2011, to 4.1 mm last year, and 3.4 mm this year. But the micro-radiation treatment has caused (20 months after the event) damage to other parts of that eye's retina. That's getting periodic injections to reduce the inflammation and other poor performance by the cells involved.

---

I finished recording the last 3 training videos while I was in Philly, but I still need to edit them to remove all my hems, haws, and long silences.

I put in the sound effects, music, and historical video clips last month.

For the month I uploaded for the beta testers versions 00.11.00.05, 00.11.00.06, and 00.11.01.00 through 00.11.00.08. That's 11 new versions with a total of 119 fixes. Not too bad considering the last version was uploaded on September 25 before I left for Philly for 5 days.

I'm working my way through the remaining bugs. Those number less than 50 as I write this.

[Shannon V. OKeets]

November 1, 2013 Status Report for Matrix Games’ MWIF Forum

The release date is still November 7th.

Hardware
I purchased two 30 inch monitors (Dell U3014) for my main system and they are just lovely. I am able to place the entire Interactive Delphi Environment (IDE, the source code and compiler stuff) on one screen. On the other I have a 40% vertical strip for my task list and the other 60% for an MWIF game-in-progress. This lets me select a bug to work on, fire up the game to recreate the problem, and examine/modify the code, all without having to open and close windows or scroll about madly in a tiny form.

Of my two old 24" monitors, my wife grabbed one for her Apple computer. So I have both a 24" and my wife’s 17" monitor sitting idle. Sometime in the first half of this month I’ll buy two more computer systems so I can start working on NetPlay for 4 players. I had to replace my graphics card to support two DVI cables for the 30" monitors and I replaced my keyboard & mouse because I had worn them out. The Ctrl and C keys on the keyboard were blank (I wore off the lettering) and the palm rest had a hole in it where my left hand rested. That was after only two years. I really like the Logitech wireless keyboard mouse combination, so I just bought the same thing again. Very little has changed, but the new one is much nicer than my old, heavily worn one.

I’ve also replaced my modem and router (8 years old) with a new modem/router. This virtually doubled the up and down speeds for my internet connection. The DSL line itself will be upgraded by the phone company in the next couple of days from 7 Mbps to 15 Mbps. I should replace my main computer too. It will be 4 years old next month and the salt air in Hawaii really does a job on plastics. It etches away at the metal bits too. But that will have to wait until 2014. I expect it to take at least 2 weeks for me to transfer all my files and software over to a new system. Presently I can’t afford that big a down time from my work.

Beta Testing
I have to be doubly sure about any changes I make from now on. I can’t afford to have modifications damage the existing, proven code. There is a never ending list of improvements possible, but I need to keep my eye on the ball and only do those which are important (for one reason or another). Frivolous little stuff doesn’t warrant risking the code base.

Marketing
Now it is up to you, dear reader, to answer the two crucial questions: (1) how big is the market for this niche product, and (2) how much do players like this Matrix version of World in Flames?

[Shannon V. OKeets]

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

Product Release
Releasing MWIF went relatively well. Shipping the manuals and maps got off to a rough start, but everything is shipping smoothly now. While I was expecting some diversity among players who bought the game, I was still rather naive about how wide the range was in three areas: computer systems, familiarity with computer wargames, and familiarity with World in Flames.

Customer computer systems at the low end are single monitor systems, some of them laptops or portables, as well as small home computer systems. Dusting things off to play MWIF appears to have happened in more than one case. There have also been reports of hauling a second monitor out of a closet, attic, basement, or garage. At the other end there are players who have very elaborate computer systems, including RAID and networked disk storage. Multiple computers are not uncommon, with the program being installed in more than one. To round out the range of systems, there are Mac and Unix boxes running MWIF in virtual machines (VM) with Windows as the VM operating system.

Some players have very little experience with computer wargames. They might come from a background of playing Risk, Axis and Allies, 3rd Reich, Advanced Squad Leader, or other board war games, including World in Flames. For these players there is a learning curve of simply downloading and installing the game. Dealing with disk drives, directories/folders, and other basics of the Windows operating system is not second nature to them. A whole new vocabulary needs to be absorbed. Then there are players who own multiple games from Matrix/Slitherine. They can jump ahead of other players in many ways. Their expectations exceed my knowledge of the Matrix/Slitherine gaming world/community. In these cases, I am the one who is learning new stuff.

Looking at the area of familiarity with World in Flames, even players who have a lot of experience with wargames can find MWIF strange because of the game design for simulating WW II. The simple concept of a turn is expanded to include impulses, phasing side, phases, and subphases. Instead of Axis and Allies, each major power operates as a quasi-independent entity. Having to choose an Action for each major power is easy to grasp in the abstract, but very hard to master in practice. Regardless of how it is viewed, learning WIF is a long process. Mercifully, a lot of that learning can be made enjoyable, by playing the game and acquiring various emotional bumps and bruises from trial and error. Some players who have extensive experience with WIF (e.g., grognards) place demands upon MWIF far beyond its ability to satisfy. The board game is 28 years old and has undergone dozens of revisions and enhancements over the years. In fact, that process continues to this day. What is the game World in Flames? The answers to that question are almost as numerous as the players who play it. MWIF is a computer program - it provides only a single answer, which rarely matches perfectly with all the other definitions of WIF.

The endpoints in these three areas generated a lot of questions, and answering them all has taken a lot of my time - given willingly, but reducing the time I have for other MWIF related tasks. Enabling players to get started playing MWIF has been a high priority for me. There are many possible stumbling blocks when using any new program, and MWIF is no exception. Despite me (and others) going to extreme lengths to help with the MWIF learning curve, (e.g., tutorials and manuals), players still have difficulties and questions early in their ownership. These can relate to their computer systems, their familiarity with computer wargames, and/or with their familiarity with World in Flames.

Oftentimes, these questions are reported as ‘bugs’, but after investigation turn out to be something other than defects in the MWIF code. No one knows that at first; only after delving into the details of a problem can they be separated into non-MWIF causes and MWIF bugs. Because players start with different expectations, communications can be difficult until a common understanding is achieved. Not that everyone is fully sated then, but at least the question of whether the unfulfilled expectation is a bug or not gets answered.

Bugs
The worst bugs in the first couple weeks were:
(1) Loading saved games, which was fixed by 1.0.1.0 (available on the day of release).
(2) Port attack anti-aircraft fire, which started as a NetPlay bug, but my fix for that transformed it into a Head-to-head bug, and my fix for that transformed it yet again into a Solitaire bug. Only with version 1.0.4.1 was I able to eliminate it completely.
(3) Accessing the NetPlay Seeking Opponent database, which still isn’t perfect but at least it is now understood and correctable. The problem is that Slitherine maintains a registry of customers with user names, passwords, and a list of games they own, by serial number. When accessing the Seeking Opponent database, the user name and password provided by MWIF has to match. If it doesn’t, then the message about being unable to access the Seeking Opponent database is generated. Meanwhile, MWIF maintains a user name and password associated with the player’s serial number on a local disk. When the player logs into the NetPlay forum, MWIF sends that information to the server. This saves the player from needing to type in his user name and password every time he enters the forum. The local disk file is NetPlayReg.txt, and the user name and password are the first two lines in that file. It’s possible to have a mismatch between the local disk file and the Slitherine master registry. The solution is to edit NetPlayReg.txt so the user name and password match those for the player in the Slitherine master registry.

There are a lot of things to fix. Many occur rarely but nonetheless are annoying to the player and even more so to me, since I get an emailed report from each player who runs into them. Every time I fix a bug, that means I will no longer get emails about it - a very strong motivation. Take for instance, the Seeking Opponent database problem. I probably received close to 200 emails about that, plus all the reports in the forums. The tide rolled in, and there I stood with just a small plastic pail with which to bail.

Other bugs have workarounds, and I am letting most of those slide for now. I knock off a couple a day, but I really give a higher priority to the Mad Except errors. Keeping track of everything reported takes a lot of my time. Once I reduce the numbers of items being reported, I’ll have more time for other code changes.

Customers
Without making a comprehensive survey, I know that MWIF is being played in: Canada, the United States, Brazil, Norway, Sweden, Finland, the United Kingdom, the Netherlands, Germany, France, Switzerland, Croatia, Italy, Spain, Russia, Japan, China, Thailand, Australia, and New Zealand. Truly a world at war.

[Shannon V. OKeets]

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

Product Support
I’m slowly coming around to a new definition of self: author of a recently released computer war game. As such, I am in communication with hundreds of players and I struggle to find the time to interact with them all. My wife pointed out that I am vastly outnumbered. Hence my terse replies or sometimes total silence: “everybody’s talking at me, can’t here a word they’re saying”. Actually it’s not bad, or even sad, but I wish I could maintain dialogues with more people.

I did finish the year keeping my one 2013 new year’s resolution: no trips to the emergency room. For 2014, I have the same resolution with the addendum: no new specialists. In December I added a dermatologist as the 7th in my medical support team (periodic 6 or 12 month visits): dentist, internist, cardiologist, urologist, optometrist for my good right eye, and retinal specialist for my bad left eye. The dermatologist removed a small basal cell carcinoma from my back: a 15 minute in and out visit with only a band-aid necessary afterwards.

Because the pressure to work on the game has abated somewhat, I’m taking a 70 minute walk to the beach every other day. I should be back to singing with the chorus weekly this month and hopefully will once again be delivering singing valentines come February. Maybe I’ll get out on the golf course in the spring.

I see my work as three general activities: answering questions about MWIF, investigating reported bugs, and fixing bugs. The first occupied a lot of my time in November and early December. By the end of the month, it had tapered off significantly. Investigating and fixing bugs both need more of my attention, but there are only so many hours in a day. What I do have set up and running well now is processing my 3 data streams: emails, World in Flames forum posts, and beta tester reports.

I log all my emails about the game into a spreadsheet. It might take me time to get around to each of them, but none of them is lost. Paul has been maintaining a second spreadsheet for me of the bugs reported in the Tech Support forum. That has been of tremendous assistance. We’ve developed a set of categories which I use to sort the bug reports so all those concerning similar topics are together. That let’s me identify duplicates. I use a similar system for the email spreadsheet. Besides helping me solve a group of problems in one sitting, it also gives me a feeling of being in control, replacing my earlier sense of having a pile of disparate issues to figure out.

Bugs
I’ve been releasing a new update on average once a week. Most likely that will continue for the next month. While I would like to have NetPlay running smoothly, I have a marked bias towards fixing the solitaire bugs. Partially that is because they are easier to fix, but primarily it’s because if the bug appears in solitaire, it is also certain to appear in NetPlay. The types of bugs in solitaire fall into two broad groups: obscure and newly created. The latter happen when I make a change to fix one bug and cause another. Two examples from the past week: leaving out the word ‘not’ in a line of code, which caused naval combat to fail, and using ‘or’ when ‘and’ was the correct boolean operator, which caused the anti-aircraft fire subphase to be skipped. Naval combat has 20,000 lines of code and anti-aircraft fire has at least 5,000 lines, but all of that was totally worthless because of two mis-thinks. Programming is either perfect or wrong.

AI Opponent
I’m not suppose to be working on this yet but I’ve found a necessary task that is undemanding and serves as a break from debugging. I take 20-40 minutes a day typing in the land region IDs for land hexes. All sea hexes already have their Sea Area IDs which can be used by the AIO when making decisions involving movement and control of all sea hexes. For the land hexes, Peter S. and myself have worked out 321 different land regions. Those are grouped into Areas of Operations, which are grouped in turn into Theater of Operations. But that information has to be communicated to the AIO so it can ‘think’ in terms of “defending western France from invasions”, or “advancing into the Ukraine.” To do that I am editing the TER data file, adding a land region ID to the end of each line of data: one line per hex. So far I’ve completed all of Europe, from Iceland to the Canary Islands, from Karelia to Suez. I’m going to do the USSR next, up to Sverdlovsk, which should be enough for the AIO to ‘play’ Barbarossa. There are a lot of hexes in the USSR and each one of them needs their own little Land Region ID number.

[Shannon V. OKeets]

February 1, 2014 Status Report for Matrix Games’ MWIF Forum

Product Support
I’m doing better about my health: making weekly chorus rehearsals (3 hours standing on the risers singing), I’m scheduled to sing in a quartet delivering valentines all day Valentine’s Day (from 9 AM to 9 PM), and I’m making it out to the golf driving range once a week. Muscle memory for these activities is slowly coming back after a hiatus of 4 years.

Most of my work is now down to two general activities: investigating reported bugs and fixing bugs. But as always, there’s never enough time in the day. The flow into my email inbox is now approaching something reasonable. In November it was 29.1 per day, in December 14.5, and for January 9.2. I still see a lot of duplicates for bugs reported - but it’s attenuated from roughly 70% duplicates down to 60%.

Bugs
I release a new update once a week. Most likely that will continue for the next month. Only small progress on NetPlay in January; February should be the breakthrough month for NetPlay. Within the first half of February, I also expect to be able to clean up the bugs in overseas Supply.

Missing Optional Rules & Half Map Scenarios
I want to make some progress on these in February. Obviously, bugs have a higher priority at the moment. However, when time permits, my preference is to whittle away at larger tasks, such as these, so they are not quite so monolithic when they rise to the top of my to-do list.

AI Opponent
This mostly dropped off my radar in January, but I expect to be able to get back to assigning Land Region IDs to Africa in February. One of the reasons I stopped was that I had achieved my first goal: assigning land regions to every hex in the European Theater of Operations, which means the basic data necessary for the AIO to play Barbarossa is in place. Getting the AIO to play both sides of Barbarossa will be the first ‘actual’ game for testing the AIO. Concurrent with that, we will be testing the scripts for setting up units in the other scenarios. There are a lot of scenarios and a lot of major powers, plus all the minor countries, so creating and testing the scripts for simply setting up units is a non-trivial task in coding the AIO.

Oh, as I have mentioned before and should repeat again now, Barbarossa, Guadalcanal, Global War, and Fascist Tide will be the scenarios we will primarily focus on for the AIO. These 4 scenarios are the ones most players want to play, so they sit at the forefront for the AIO to learn to play well.

[Shannon V. OKeets]

March 4, 2014 Status Report for Matrix Games’ MWIF Forum

Product Support
Two doctor visit/checkups yesterday - I passed the first one with my internist okay and the second doctor (retinal specialist) said the vision in my bad eye is getting better (20/50 now). On Valentine’s Day and the day before, I helped deliver singing valentines (I sang bass in the quartet). We did 8 deliveries each day and did slightly better this year: more than half of the recipients were in tears. Usually that happens early in the first of the two short songs we sing - the women love the romance of it all. But this wiped out two days for working on MWIF (8 hours plus 11 hours on the road).

I purchased two new computers in February and set them up for testing NetPlay on 4 machines. Most likely I won’t get to that until April though. Because the demolition of our kitchen and guest bathroom is scheduled to start the last week of March, I wanted to get the additional systems installed and checked out before chaos descends upon our apartment.

Bugs
My work continues to be investigating reported bugs and fixing bugs. But as always, there’s never enough time in the day. The flow into my email inbox is abating: down to 5/day, which is about half of what it was in January. As always, February was a short month, even more so with the loss of a couple days for singing and a couple days installing computers.

The goal of releasing a new update once a week wasn’t met. And there will probably be only 3 updates in March. The beta testers want more time for testing each release, primarily because of the problem with the unacceptable delay in response time for moving units introduced by version 1.1.5.0 (and corrected by 1.1.6.0). Supply occupied almost all my time in the last half of the month. Below is an “under the hood” discussion of Supply if you are interested in what the program is actually doing for all those CPU cycles.

NetPlay got some fixes in the beginning of February and I should be able to clean it up in the first half of March. That’s even given that I want to correct the few remaining bugs in recalculating supply while the code is fresh in my mind: (1) recalculating supply for secondary supply sources which had previously been using overseas supply, (2) territorial units belonging to a conquered minor country and controlled by the conqueror tracing supply to cities in their homeland, and (3) notional units tracing supply after the enemy units have ‘landed’ in their hex.

Missing Optional Rules & Half Map Scenarios
Unfortunately I made no progress on these in February. Obviously, bugs had, and have, a higher priority.

AI Opponent
This also got none of my attention in February. But as the saying goes: hope springs eternal. In this case for making progress in March on background preparation for the AIO.



Supply Calculations

There are 23 steps in calculating supply. All of them are executed when a game starts or is restored, when the weather changes, and when countries join/leave the war. At other times during game play, some of them are executed. Most often that is when the player moves units onto, off of, or about the map.

But once the original calculations have been run, the program is much faster doing supply ‘recalculations’. That’s because the program records the supply paths for every secondary supply source to a primary, every tertiary to a secondary/tertiary, and for every unit. Having the paths stored in memory let’s the program start the recalculation task by testing each previous path to see if it’s still valid. New searches are required only for old paths that fail.

Steps 1-4
The first step is to identify which countries might need supply. If the country is a governed area (i.e., doesn’t have any units) or is a neutral minor country, then it can be ignored for supply purposes. Then the sea areas are initialized in step #2 based on which optional rules are in effect. For instance, if Limited Overseas Supply is being used and a side (i.e., Axis or Allied) doesn’t have a convoy or transport in a sea area, then clearly the sea area cannot help transmit supply for that side. The next two steps are obvious: identify all the primary supply sources for major power and minor country units, followed by identifying potential secondary supply sources.

Steps 5-7
The fifth step is to attempt to find a rail path from potential secondary supply sources to primaries. That gets a little tricky. To begin with, the search is limited to overland paths and restricted to secondary supply sources controlled by a major power to its own primary supply sources. These paths are the best because when they are found, the secondary supply source can provide supply for all tertiary supply sources and units for the major power, cooperating major powers, and aligned minor countries. Internally these supply paths are referred to as Pure. If a secondary supply source cannot find a Pure path, then the search continues for a path to a primary supply source belonging to a cooperating major power. When found, these are labeled Coop paths. Simultaneously with searching for Coop paths, the algorithm looks for primary supply sources belonging to a minor country aligned to the major power controlling the secondary supply source. These are labeled Aligned paths. The fourth type of path is from a secondary supply source belonging to an aligned minor country to a primary supply source controlled by a cooperating major power: Mixed paths. There is one more type of path: Minor. These are from a secondary supply source belonging to the given major power or one of its aligned minors to a primary supply source for an aligned minor.

Some examples should help clarify the 5 types of paths: Pure (von Leeb to Berlin), Coop (von Leeb to Rome), Aligned (Mannerheim to Berlin), Mixed (Mannerheim to Rome), and Minor (Mannerheim to Helsinki). As mentioned above, Pure paths can be used by the given major power, cooperating major powers, and aligned minor countries. Coop paths can be used by the given major power and the given cooperating major power. Aligned paths can be used by the given major power and the aligned minor country. Mixed paths can only be used by the given major power. Lastly, Minor paths can only be used by units belonging to the given minor country. The last is the only type that cannot be used by the given major power.

The 6th step is to search for overland paths from secondary supply sources without a Pure path to see if they can be tertiary supply sources. First the search is limited to secondary supply sources with Pure paths back to a primary. If that fails for a secondary supply source, then another pass (step 7) is made that broadens the possible secondaries to include those with path types other than Pure. Any paths found in these searches are also labeled as Pure, Coop, Aligned, Mixed, or Minor. It is possible for secondary and tertiary supply sources to have more than one type of path. For instance, Mannerheim could have a Mixed path back to Rome only usable by German units and a Minor path back to Helsinki only usable by Finnish units. These situations occur rarely, but the program is thorough in checking for them all. Indeed, the program allocates memory for as many as 4 Coop paths and 20 Aligned paths for each potential secondary supply source. There is only one slot each for Pure and Mixed paths. Minor paths are stored in the Pure slot for the given minor country.

Steps 8-14
The 8th step identifies all the sea areas that can be used by major powers to trace supply to one of their own primary supply sources. This determination is performed by tracing FROM ports to the supply source. It only uses predefined ports for each major power rather than checking all the ports on the map. There are thousands of ports on the map (something over 5000 if I remember correctly). So, for Germany the list of ports is limited to those in Europe, omitting all the ports in the Americas, the Pacific, and most of the ports in Africa and Asia.

If a port can trace to a primary supply source, then the adjacent sea areas can be used for overseas supply. Furthermore, overseas supply can be propagated to include adjacent sea areas in an ever expanding network of sea areas. Of course, some sea areas are unusable, as determined in step #2. Other restrictions may apply to some major powers when trying to move between sea areas (e.g., Gibraltar and Suez may block supply). An example of propagation is that if Liverpool is a valid port for the Commonwealth (it almost always is) then both the Bay of Biscay and the Faeroes Gap can be used, assuming the other requisite conditions are met for those sea areas. And from there the North Sea, the Norwegian Sea, the Denmark Straits, the North Atlantic, etc. can also be valid sea areas. Once Cape St. Vincent becomes valid, Commonwealth units in Gibraltar will be in supply.

The 9th step checks for out-of-supply (OOS) secondary supply sources which can then use the newly available sea areas for overseas supply. To ascertain this, another search is necessary, from the OOS secondary supply sources TO a port that is adjacent to a valid sea area. These are rail paths so the search can theoretically be of infinite length.

The 10th and 11th steps are the same as the 8th and 9th except the search includes ALL ports, not just those hard coded for each major power. These steps are skipped under certain conditions (i.e., if the work done by steps #8 and #9 rendered them unnecessary).

The 12th an13th steps are the same as the 8th and 9th except the search is expanded FROM ports to secondary/tertiary supply sources. The 14th step is similar to the 13th with the 14th not limiting the destination supply sources to those controlled by the given major power. Because the 13th step might find Pure paths, those are done separately and first. The 14th step can only find non-Pure paths which are of lesser utility.

Steps 15-18
These steps are similar to those of steps #8 through #14 with the only change being that the search from tertiary to secondary is for secondary supply sources with a valid overseas path. That means that the tertiary to secondary search must be overland, since only one overseas link is permitted in a supply path.

Step 19
This is the first time the search is for paths from units themselves to supply sources.

Steps 20-22
These steps repeat the pattern for finding overseas paths, but for minor countries. Note that in almost all cases a minor country unit gets supply from supply sources belonging to its controlling major power.

Step 23
This final step is for minor country units that are still OOS after running step #19, in the hopes that they might find supply from their own cities because of the newly enabled sea areas in steps #20 through #22. This comes up from time to time. For example, Rumanians might need to use the Black Sea to find a path to primary supply in Bucharest.

Summary
Supply for MWIF was one of the 3 most difficult things to code. The others also involved sea areas: production planning routes and naval movement (with naval interceptions and naval interception combat). In general coding MWIF involved a lot of grunt work because of the sheer size of the map, the number of units, and the number of rules. There are thousands of lines of code just for setting up units on the map for each scenario based on the chosen optional rules. Then there was a lot of tedium counting pixels for displaying hexes and units on the map and positioning various visual elements on the 150+ forms. Mercifully, being clever wasn’t a precondition for the vast majority of the programming.

Still and all, supply is the only item that required optimization of execution to keep the CPU cycles to a minimum. To achieve that I needed to draw upon methods I learned back in the 1960's, 1970's, and 1980's when there was a limited amount of memory available and the CPU speed was pitiful. In 1985, the Atari 800 had 64 KB of RAM with only 32 KB available for an application; its CPU speed was 1.2 KHz. Today MWIF has over 1 GB of RAM available (it uses ~500MB) and CPU speeds measured in GHz. Those are improvements of a million times in both RAM and CPU speed. Doing calculations once and storing the results for fast retrieval is one tactic used by MWIF. Another is understanding the task in exquisite detail so efficiencies could be introduced based on certainties of which steps could be skipped under specific conditions.

I might need to revisit Supply another time or two if game situations push the existing code to use too many CPU cycles, making the response time too long. But writing that type of code is very unpleasant and is only undertaken when doing so is absolutely essential.

[Shannon V. OKeets]

April 3, 2014 Status Report for Matrix Games’ MWIF Forum

Product Support
I didn’t get much work done in the last half of March. Our chorus’ annual show was on the 22nd and we had either a rehearsal or a performance every day for the entire week before that. Meeting all those people (instead of hunkered down with my computers) I picked up a head code that wiped me out for 4 days the following week.

The demolition of our kitchen and guest bathroom started on the 27th which was preceded by several days of us needing to clear the decks for action. Progress on the remodeling is now going well, with a crew due to arrive this morning to haul all the wreckage away. Meanwhile the construction guys have been bringing in all the new stuff and storing it around and about our apartment: 7 new doors, a bathtub, a toilet, lumber, and plumbing fixtures. That collection joins the 30+ boxes holding the kitchen and bath cabinets that have been keeping us company for the past 11 months. The rough estimate is that things will be finished at the end of April, plus or minus a week.

Bugs
Erik and I decided to do a complete review of where we stand on fixing bugs.

It took almost a full week just bring my record keeping up-to-date. That meant going through all the posts in the Tech Support forum and adding any new items therein to my spreadsheet. The Tech Support spreadsheet was originally done by Paul, but I have substantially modified it, sorting it into rough categories (e.g., supply, production planning, land, air, naval). In the process I downloaded all the saved games provided in the Tech Support forum and assigned them file names to match the numbering system I have for the spreadsheet.

The second spreadsheet I maintain (emailed bug reports) only needed a modicum of editing to bring it up-to-date. Like the Tech Support spreadsheet, this one also has a set of associated saved games, to which I assign numbers. I now make a point of getting both spreadsheets current at least once a week.

My third source of bug reports is from the beta testers. I am both better and worse at processing their input. At times I make changes immediately in response to what they post in the private Development forum. That’s to fix new bugs in my currently in-development version of MWIF. But I am not as good at acquiring a complete record of the bugs they report - mainly because I fell so far behind when the game was released.

All the input streams of bug reports are rife with duplicates. Sometimes that a report is a duplicate isn’t obvious, so I end up with multiple entries in the spreadsheets. A sort of insidious problem is that once I correct a bug, I then have to go through all my record keeping and mark items as fixed.

The last step in my record keeping was to create a new Word Perfect text file with a one line entry for each problem. That summary is sorted by category, like the Tech Support spreadsheet, and merges all 3 bug report input sources. Based on the bug report numbers, I can tell at a glance their source: under 2500 are from the beta testers, 2500 to 2999 are from Tech Support, and 3000+ are from emails. This system lets me examine, for instance, all the bugs reports on Supply using the Summary file and then delve into the specifics looking at the descriptions in the Tech Support spreadsheet, an email, or a beta tester Development forum post.

Having completed a review of where we stood, the decision was made to prioritize Solitaire bugs ahead of NetPlay bugs. Furthermore, the Supply bugs were given pride of place, accompanied by critical bugs (i.e., those that were halting games and could not be worked around). Once all Supply bugs are fixed, we’ll move on the Production Planning followed by the Naval bugs (movement and combat).

Another change in our operations was to validate changes in the program using Open Beta versions. These are available to players who want the latest and greatest, but understand they come with the caveat that there might have been some new bugs introduced. So far we just did one of these: version 1.1.7.2. It has gone a week with no new bugs reported by the beta testers or other players who opted to test the version, so it will now be made available as an ‘official’ update.

I have been working on the next Open Beta in the meantime, fixing primarily supply bugs. There are still seven on my task list, 4 of which are unlikely to occur during most game play. See below for some visuals of my various records. We think that going forward, we should have a new version available every other week, with each version fixing all the known bugs in a ‘section’ of code plus those that halt game play. The first three ‘sections’ are: Supply, Production Planning, and Naval.

Missing Optional Rules & Half Map Scenarios
Unfortunately I made no progress on these in March.

AI Opponent
This got none of my attention in March.



The attached composite screenshot, from top to bottom, shows: Summary of supply bugs, Details of supply bugs (mostly from beta testers), Tech Support spreadsheet section on Supply bugs, and the remaining email bug reports from January which need to be investigated (those concerning supply have a status of Open - S). The summary form has Master Task List numbers colored green if a saved game is available to recreate the problem. That is a key piece of information and appears in all 4 lists. The items in pink are the ones I will work on next.

Note that the email spreadsheet has separate pages for each month and the entries generally have less information about the game-in-progress at the time the problem occurred (e.g., unknown mode of play, scenario, turn, phase, decision making major power, player action that generated the problem, etc). On the other hand, when a Mad Except has occurred, I do get the program version number and precisely where in the code the Exception occurred, with the call stack so I can trace back to all the calling routines. Sometimes that is enough, but many times I have too little information to go on to understand what happened. Far better are the beta tester and Tech Support reports which have saved games and instructions on how to reproduce the problem.

[Shannon V. OKeets]

May 2, 2014 Status Report for Matrix Games’ MWIF Forum

Product Support
Work continued on our kitchen and guest bathroom throughout the month of April. Currently it’s expected to be finished May 16th. With 2-4 workmen coming in and out 5 (or 6) days a week, from 8 AM to 4 PM, wielding various saws, drills, and hammers with great energy, plus their various conversations, it would be an understatement to say my programming environment for debugging has been less than ideal. Meanwhile it is paper plates and plastic forks for meals, with a lot of take-out and MTH (microwave-til-hot). My wife prepared 30+ dinner meals in advance of the invasion and froze them to see us through the duration. As one example of the poor working conditions, the week the electrician was here he turned power off to the apartment on 3 days, twice for over 3 hours. They also cut my internet connection several times.

The attached picture is a composite of what some of the wire runs looked like on the day the electric work passed inspection by the city. The two pictures show partial views of the wall between the kitchen and the living room. That is, the picture on the left has 5 wires running through the wall heading to the right. Those same wires are shown on the picture on the right, coming in from the left. In the right picture is the back of the electric panel, with the old solid cable connections being 3 at the top and 5 at the bottom. The new ones are the flexible cable connections: 2 at the top, 2 at the bottom, and the 5 on the left side. If you look at the ceiling, you can see how far the wall has been moved out to the left (the white popcorn ceiling on the far left use to be in the living room). The kitchen is now 10 inches bigger and the living room 10 inches smaller.

The change in the ceiling is also visible in the picture on the left, of the chase for the plumbing and dryer vent. The large opening in the wall is a pass through, where dishes can be passed from the kitchen to the living room, without having to walk around. The old dryer vent in the chase had a flexible plastic duct which had partially disintegrated over the past 40 years. The resulting opening to the outside (19 floors up) had been noticed by some birds, which had built a nest in the bottom of the chase. The new dryer vent duct is metal, with some sexy black tape used to bind sections of it together (the black tape is heat resistant since the duct is apt to get quite hot). In the left picture you can see the 5 wire runs going through the new wall into the chase, and out the left side to the new, furred out wall on the left. That concrete wall on the left is part of the building’s exterior (“do not do anything to that wall!”) and in order make room for the plumbing after we moved the clothes washer over against it, we had to fur out the wall 4 inches - making the usable kitchen space 4 inches smaller. All those wires are for: the dishwasher, clothes washer, garbage disposal, lighting strips (under the wall cabinets), and electric outlets (also under the wall cabinets). If you are curious how 5 wires became 6, the 6th is one of the bottom cables from the electric panel and it runs under the pass through.

We’re getting close to being done. Since those pictures were taken, all the dry wall has been installed, enclosing those wires etc. We also have half the tile work done for the floors and the shower surround. The base cabinets are in and the wall cabinets are suppose to be installed tomorrow (Saturday). Best of all, the clothes washer and dryer now work, so we don’t need to make trips to the laundromat any more. Next week should see the tile work finished, the countertops installed, and the bathroom wallpapered.

Bugs
I have kept my record keeping of reported bugs up-to-date, including those from: posts in the Tech Support forum, emailed bug reports (from when the program crashes), and from the beta testers.

Version 1.1.7.2 was released as an official update after a week or so as an Open Beta. The beta testers then tested versions 1.1.7.3 through 1.1.7.9, before we made version 1.1.8.0 available as a Public Beta. That had one serious error, which I fixed within a day, for version 1.1.8.2 (another Public Beta).

I’m currently working on version 1.1.8.4, fixing the last of the supply bugs (newly reported for version 1.1.8.2). That should be available next week as a Public Beta. The goal of generating this series of versions is to eliminate all known bugs relating to supply. Those bugs keep getting more and more obscure, but we want to kill them all off before moving on to fixing Production Planning bugs.

Here are a couple of the recent supply bugs fixed for version 1.1.8.4:
• Fixed a problem where capitals and HQs belonging to a minor country aligned to a major power (MP-1) were tracing overseas supply to primary supply sources belonging to major power (MP-2) that cooperated with MP-1 instead of to primary supply sources belonging to MP-1.
• Added code so the HQ of an aligned minor country which is using an overseas route to reach a primary supply source, can provide supply to units of its own country.

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

AI Opponent
Nothing new in April.

[Shannon V. OKeets]

June 2, 2014 Status Report for Matrix Games’ MWIF Forum

Product Support
Construction work on the kitchen and second bathroom was finished in May. New carpet is going to be installed in the second bedroom tomorrow morning and next week that room gets a custom made “closet system”. That will complete the renovations for the second bedroom, which my wife uses as a combination office and sewing room. She still uses the sewing machine we bought from Sears the day we got married (which will be 43 years ago come July). I don’t think they make parts for that steam engine model anymore.

It certainly is delightful to be able to code without incessant interruptions and construction noise 5-6 days a week.

Bugs
My record keeping of reported bugs remains up-to-date.

During the month there were many versions released to the beta testers and most of them were also made available as Open Betas. Version 1.1.9.2 is currently in the hands of Matrix Games to make available as an official update. That resolves almost all of the Supply bugs. I have a few additional ones for Supply that need my attention (I’ve fixed a couple of them since uploading 1.1.9.2). But those corrections won’t become available in an official release until first going through beta testing and Open Beta testing.

I’m presently working on version 1.2.0.0, which, besides including the last Supply bug fixes, is focused on correctly problems in Production Planning. I did take the time to fix a few bugs in the Conquest phase over the weekend. Those had to do with relocating units belonging to neutral major powers that were in a conquered country (e.g., Japanese units in Persia when the USSR conquers Persia, while not at war with Japan. Again, those changes need to go through additional testing before becoming available as an official release.

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

AI Opponent
Nothing new in May.

[Shannon V. OKeets]

July 2, 2014 Status Report for Matrix Games’ MWIF Forum

Bugs
My record keeping of reported bugs remains up-to-date.

Version 1.1.9.2 was released as an official update in June. Likewise, version 1.2.0.2 was made available as a public beta in June.

Version 1.2.0.6 is currently in the hands of the beta testers and if they do not report - before the end of today (Tuesday, July 2nd) - any new problems created by that version, I’ll upload version 1.2.0.7 (same as 1.2.0.6 but with debugging disabled) for Matrix Games to make available as a Public Beta. This process of having new versions go through testing by the beta testers, followed by a Public Beta, and only then an official release, takes more time, but avoids the mess created when a new version causes significant new problems. When a public beta performs well for about a week, it then becomes an official release.

Because this is a short week in the US (4th of July holiday on Friday), Matrix Games might not be able to make 1.2.0.7 available as a public beta before the weekend. If that happens, then I’ll do more work over the rest of this week and weekend with the result that the public beta version will be numbered 1.2.1.0 and made available early next week (e.g., July 7th - 9th).

This past month I worked almost exclusively on problems with Production and Production Planning. For the former, the issues were primarily with Saved Build Points. I had to go down to the fundamental ‘object’ definition of Build Points (two types: saved and newly created) and modify some of those methods/functions. At the start of Production the program goes through all the hexes containing saved build points and determines how many can be used in production. It’s possible to store 4 build points in a hex containing only a port (e.g., Plymouth), but only 1 saved build point can be recovered from that hex for use in each Production phase. What the program does is take the maximum number of usable saved build points from each hex and leaves any excess on the map. For this example, the number of saved build points in Plymouth would be reduced from 4 to 3 while the number of build points the Commonwealth would have available for production would be increased by 1.

The difficulty I had with getting all of this to work was that build points may be part of trade agreements. That necessitates calculating the number of build points for each major power at the start of the Production phase. If a major power doesn’t have enough build points to fulfill a trade agreement, then that has to be detected and recorded. In performing those calculations, the program removes build points from the map, which made the calculation of available build points wrong later in the Production phase. That is, only Germany, which was doing Production first, was able to recover saved build points. By the time other major powers got to do Production, their saved build points had already been removed from the map. The obvious solution was to record all saved build points at the beginning of the phase and use the recorded amounts later in the phase, instead of dynamically recalculating the number of saved build points for each major power. As often happens, these changes, which required new variables to be created, meant saved game files (GAM) had to store and retrieve values for new variables. More code had to be changed and tested. That was essential for games that are saved in the middle of the Production phase.

The hassle with Saved Build Points is typical of the problems I work on these days. After running a saved game that displays a problem, next I have to refresh my memory on all the pertinent rule particulars. Then I read through the corresponding code, and if nothing obvious jumps out at me, I run the saved game again with debug statements displayed in the relevant code segments. That lets me see what the program is doing. Having fault isolated the problem, I then need to devise a solution, code it, and test that is solves the problem. The testing is not just a single run of the saved game. There have to be other runs starting farther in advance in the sequence of play and continuing on to phases well past the point where the new code executes.

At this point I have no remaining bugs related to the Production phase (building Militia and convoys now work correctly under all circumstances). There are two or three Supply bugs that have been reported and confirmed by the beta testers as serious. I need to get to them next.

But before the Supply reports came in, I fixed some of the more egregious bugs in Production Planning. Those concerned: (1) players being able to use sea areas in overseas resource routes that were valid in a previous turn but no longer valid, (2) fulfilling overseas trade agreements which contained build points, (3) displaying overland resource routes in Barbarossa, and (4) sending the Japanese build point to the US.

I also got around to fixing the code for repairing Blue factories. There is still a problem with damaging and repairing Red factories, but I need some fresh saved games for figuring out what is going wrong with that section of code. For July, my task list is to fix the remaining Supply and Production Planning bugs, then move on to fixing the naval movement and combat bugs.

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

AI Opponent
Nothing new in June.

[Shannon V. OKeets]

August 1, 2014 Status Report for Matrix Games’ MWIF Forum

Bugs
My record keeping of reported bugs remains up-to-date.

Version 1.2.0.7 was released as an official update in June. Version 1.2.0.9, 1.2.0.10, and 1.2.0.11 were made available to the beta testers. The next version for beta testing will be 1.2.1.0, which will then be made available as a Public Beta after a few days of testing by the beta testers, and roughly a week later an official update.

I went back to working on Supply to clean up some bugs that hadn’t been caught in beta testing by the beta testers or in the public beta. Those bugs were mostly obscure, having to do with conquered territorial units tracing supply through secondary supply sources belonging to the major power that conquered the territorial unit’s country, and from there back to a primary supply source in the territorial unit’s home country. What’s unusual about that linkage, from the unit to the primary supply source, is that the secondary supply source itself is out-of-supply. There was also a bug related to secondary supply sources tracing overseas to a cooperating major power’s primary supply source. Most of the time HQs (and the capitals of conquered countries) can trace to their own primary supply sources, but there are situations where that’s impossible. So the overseas path to the cooperating major power’s primary supply source has to be used.

Most annoying was a typo in the form that displays Supply Sources and Paths that took me 4-5 days to figure out. The program was correctly going through all the intricacies of conquered territorial units’ supply but messing up when it came time to display that information. I was going nuts trying to find where in the code the complex logic and calculations were wrong, but all of that code was perfect - the fault was a couple of incorrect characters in a variable in the Supply Sources and Paths form.

For most of the rest of the month I worked on problems with Production Planning. As part of that, I fixed some bugs in the Use Oil phase. That phase sits between the Preliminary and Final Production Planning phases and because it can consume oil points, it’s execution in interwoven with the Production Planning phases. By cleaning up some of the Use Oil bugs, other bugs originally labeled as associated with Production Planning disappeared.

Aside from directly working on the code to fix bugs, I reviewed all the emailed bug reports received since the game was released. By looking closely at the screenshots (usually, but not always included) and the Mad Except reports on where in the code the program failed, I was able to categorize all the bug reports. That took me some time but was worthwhile for several reasons. First of all, I was able to eliminate some of those bug reports because I remembered having fixed them. Similarly, for some of the older ones, I was able to run saved games and determine that the bugs no longer existed. Lastly, this enabled me to have a absolutely complete list of all the bugs reported in each category. Supply, Use Oil, and Production Planning being the ones I was most concerned with this past month. Next month I should be done with Production Planning and have moved on to Naval Movement and Combat bugs.

As I went through all the reported bugs, from various sources, I would occasionally fix something that seemed to be causing major difficulties for some players. Those bugs were quite diverse, ranging from Declaration of War, to garrison counts against Partisans, to Militia reinforcements during Jan/Feb turns, and to Reforming units adjacent to neutral major powers. For some phases of the game, I try to resolve all reported bugs so those phases are ‘clean’. DOW is one such phase, and the various phases where units are placed on the map are others.

It’s still a hard fact that roughly half of the bug reports I investigate are not bugs. Some of them never were bugs, but many have simply been fixed between the time they were reported and when I finally got around to investigating them in detail. Although I try to locate and ‘clear’ all reports about a bug when I fix it, actually finding them all requires a lot of time and effort - oftentimes I just move on to fixing the next bug in my list. So some bugs that have been fixed remain on my task list until I find the time to investigate them weeks or months after I have fixed them.

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

AI Opponent
Nothing new in July.

[Shannon V. OKeets]

September 1, 2014 Status Report for Matrix Games’ MWIF Forum

Bugs
My record keeping of reported bugs is up-to-date.

Version 1.2.1.2 is in the process of being made available as a Public Beta. That should occur during the first week of September. A week or so later it should become an official release.

There are 71 changes to the code between the last official release (1.2.0.7) and 1.2.1.2. Those changes include a dozen or so fixes to Supply, mostly having to do with territorial units belonging to conquering major powers and tracing overseas supply routes to supply sources owned by cooperating major powers. As an example of the first: Ethiopian territorials controlled by Italy. An example of the second is Germany tracing supply across the Mediterranean using Italian secondary supply sources.

The vast majority of the changes for 1.2.1.2 were for Production Planning. In the original design, no consideration was made to changing the sources, routes, and destination for build points. That was a serious flaw in the design. I was able to patch the design so that the requisite data could be stored for default and override settings for build points. Then I modified the player interface for the Production Planning form so the player could assign values to those variables for build points: factory originating a build point, the route, and the destination. The major power providing a build point gets to set the originating factory while the major power receiving a build point is able to set the destination. Build points are always set as ‘Save’ in data storage, although they are transferred as available for production during the Production phase - provided the number of saved build points in a hex does not exceed the number that a player can use in a hex during a single turn. The 14th Video Tutorial (described below) gives examples of how to change the settings for build points.

Other changes to Production Planning ranged from rewriting poorly worded messages, eliminating spurious messages, and generally cleaning up the player interface so it runs faster and with less clutter. One modification was to replace Skip Major Power buttons with Switch Major Power buttons. The former cycled through all the major powers one at a time. The new implementation brings up a list of major powers that have yet to decide in the current phase, and lets the player select for which major power he next wants to make decisions. This replacement of Skip to Switch was made for six forms: Production Planning, Lending, Select Naval Combat, Align Minors, DOW on Majors, and DOW on Minors.

Next up, I want to fix a few odd bugs here and there, including some minor bugs in the Use Oil phase. Then I’ll move on to the naval bugs, including naval air combat. Once I get the worst of those corrected, I will be returning to NetPlay.

Right now about half of the NetPlay bugs concern naval movement and combat. So it is important to fix the naval bugs in Solitaire before trying to correct NetPlay. Debugging NetPlay is much more difficult that debugging Solitaire since NetPlay requires firing up two computers with the same version of the program and the same saved game. The same version of the program might seem like a trivial thing, but it means that every time I make a change to the code, I need to transfer the new version of the program to the second computer. That gets tedious really fast when making a change every 5 minutes or so.

Tutorial Videos
I created a 14th Video Tutorial: Production Planning, Practical Examples. The beta testers are looking it over and I expect it to be included with 1.2.1.2 when that becomes an official update. The new video runs 83 minutes and is quite large (591 MB). Here is a summary of what it covers:

• The tutorial gives the reasoning behind the placement of convoys for routing resources overseas to factories, where to save oil, and when to use oil for production versus reorganizing units (or saving it for future turns). The first five examples are from the setup phase for the Global War scenario. The six later examples are taken from saved games at different times in the prosecution of the war. The tutorial frequently uses the Production Planning Reference figure (found on page 231 in volume 2 of the Players Manual), the Production Multiples chart from the WIF FE Charts (accessible from the drop down Help menu), and the help pages for Unit Costs and Characteristics.

• China setup: Burma Road rules; routing resources through countries controlled by allies; using one oil point for reorganizing units without expending the oil point; bonuses to the Production Multiple for enemy actions.

• United States setup: Routing resources overseas; US-Japan trade agreement; saving oil; placing convoys on the map; the importance of US Entry Options for increasing the US Production Multiple.

• France setup: Working with too few resources; routing resources through neutral countries; routing a resource across the straits of Gibraltar; vulnerable convoys and front line resources; scarcity of oil.

• Germany setup: Getting Swedish resources to German factories; Narvik special rule; critical use of oil.

• Commonwealth setup: placing all 81 convoys on the map so that 22 factories are producing, 7 oil points are saved, and the 3 bonus production points are awarded for fulfilling the Food in Flames requirements.

• Example 1: Selecting which resource (non-oil) fulfills a trade agreement and setting its destination.

• Example 2: Changing the destination for an oil point received in trade.

• Example 3: Changing the destination for a build point received in trade.

• Example 4: Having Sao Paulo in Brazil provide build points to Free France in Gabon to fulfill a US-France trade agreement.

• Example 5: Changing a route for an oil point being sent in trade in order to make a convoy available to receive a 5th build point.

• Example 6: Specifying the factories which provide build points for trade agreements.

Missing Optional Rules & Half Map Scenarios
Nothing new in August

AI Opponent
Nothing new in August.

[Shannon V. OKeets]

October 3, 2014 Status Report for Matrix Games’ MWIF Forum

Project Management
Sorry for being so late with this monthly update. I’m still trying to juggle too many items.

I lost 7+ days in September due to construction in my living/dining room. After waiting for 4 years, we finally got our lanai (a.k.a. balcony) enclosed which adds 4.5 by 18 square feet to that large room (originally 18 feet by 28 feet). After putting in windows for the lanai, the old French doors and side windows had to be removed, then the ceiling popcorned (a weird texture effect) so it matches the rest of the living/dining room. We also had the room repainted while we were at it. The last bit was to recarpet the entire room, which meant taking out all the furniture and wedging it into other rooms. Once the new carpet was down, we then had to drag all the furniture back. On the plus side, I replaced my office furniture with 3 desks and a ‘hutch’. You can see a picture of that below.

Bugs
My record keeping of reported bugs is up-to-date.

Version 1.2.1.2 was made a Public Beta which revealed a few problems that needed to be fixed before it became an official release. Towards that end, we made 1.2.1.5 a Public Beta. As I write this, I see that 1.2.1.5 was just made available as an official release. That resolves most of the problems with production planning. It also includes a new tutorial video (#14): Production Planning Practical Examples. I have received a couple of newly reported bugs about Production Planning, and a couple about Supply, but none of those is a game stopper. So I have moved on to working on the naval bugs.

Both naval movement and naval combat had accumulated a bunch of bug reports and I have been working my way through investigating and fixing those. Some of them are rather obscure; for example:
Fixed a problem with a naval combat abort digression not returning to the naval movement phase once the digression was completed. The sequence that failed was: naval move, naval interception (succeeded), fight through, moving side’s search succeeds, both sides have a unit aborted, both continue to fight, both searches fail, non-phasing side’s aborted unit interception attempt (failed), both aborting units return to base, original moving units continue their move. The program now returns to the Naval Movement phase instead of remaining in a naval abort digression at the last step of that sequence.

I want to look into another dozen or so naval combat bugs before making version 1.2.2.x a Public Beta. Once that Public Beta is made available, you’ll know that I am back to working on NetPlay.

There aren’t actually many bugs related purely to NetPlay. Most of them seem to been related to the same bugs that appeared in Solitaire play. But there are a dozen or so that I know to be solely the province of NetPlay. That’s what I will be working on. The picture below shows how I have configured my office to enable running NetPlay on 4 computers simultaneously. Getting it to work for 2 players is the first goal. But making it viable for 6 players is the ultimate goal for NetPlay.

Fixing a few odd bugs here and there, including some minor bugs in the Use Oil phase should be part of the 1.2.2.x version. While that version is primarily focused on naval movement and combat, I want to fix a few reported bugs with air missions too, in particular, for long air-to-air combats.

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

AI Opponent
Nothing new in September.

[Shannon V. OKeets]

The above picture of my new office has a 6 foot desk on the left, a 4.5 by 4.5 desk in the corner, and a 4.5 by 5 foot desk on the right. There are two computers on the left desk: a decked-out Win8/Win7 system and a bare bones Win8 system. Once I get all the bugs under control, I upgrade my version of Delphi (the programming language in which MWIF is written) on the new/best computer. But I don't want to take the time to do that while there are still bugs to be fixed.

On the corner desk there is a portable with dedicated attached monitor, keyboard, and mouse. My current main system in on the right desk, with the two large monitors.

The hutch holds all the software manuals (behind closed doors). On top of the hutch are the binders holding the MWIF source code. The 7 on the far left hold the work to-date on the AI Opponent.

Only two of the computers are on the floor (the ones on the left). The desk on the right is large enough for me to place the computer and the universal power supply behind the monitors.

The only other items under the desks are the two rolling cabinets in the corner. They hold the WIF FE maps and counter sheets, among other items.


===

The picture in this post is of the enclosed lanai. We have moved the dining room table out on the lanai, on the left, and placed the piano in the corner on the right. I'll post more pictures of the living room next month. There are still some other windows to be replaced. That should take 5 working days and not interfere with me getting work done on MWIF. Although 4 of our rooms will be disrupted by construction. Hopefully that will all be minor.

[Shannon V. OKeets]

November 3, 2014 Status Report for Matrix Games’ MWIF Forum

Bugs
My record keeping of reported bugs is up-to-date.

Versions
Version 1.2.1.5 was made an official release early in October.

Version 1.2.2.8 was made a Public Beta late in October and it revealed a couple of problems that needed to be fixed before it became an official release. Towards that end, 1.2.3.2, which fixes the problems in 1.2.2.8, is about to be released as a Public Beta. If that looks solid after a week as a Public Beta, it will become an official release.

Version 1.2.3.2 primarily corrects bugs with naval movement and combat. There are a dozen or so other changes included. Despite my best intentions, I didn’t get to fixing some irritating bugs in air missions for solitaire play. That’s because it is time to move onto getting NetPlay to work. Indeed, some of the changes I made in the last week of October were for NetPlay. Those haven’t been completely tested, so they aren’t listed as changes for version 1.2.3.2.

So far I have been able to determine that some of the reported bugs on my list for NetPlay no longer occur. I also fixed a couple of NetPlay items with Initiative and Weather. In general, I expect to work on NetPlay bugs in the order that they occur in the sequence of play. I still have one logic branch for Who Moves First that doesn’t work correctly, but that is the last in the list of 16 possible branches - depending on rolls and rerolls for initiative, and the decision for whether the winning side wants to move first or not.

On the negative side, I have confirmed that 5 of the reported NetPlay bugs do occur, and I have saved games to reproduce them. But even getting that far in fixing a NetPlay bug takes a lot of time. For example, Port attacks with 2 Abort results correctly lets each side select which unit takes the abort result. But with 1 Destroyed, 1 Damage, and 3 Abort results, the program halts up after the Destroyed result is applied, instead of switching to let the defending side select the units to take the Damage result. And so it goes, each possible result in a port attack has to be tested. Once the code works for NetPlay, then we have to go back and make sure the code still works for Solitaire and Head-to-head play too.

With any luck, I should have NetPlay for two players cleaned up by the end of the month.

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

AI Opponent
Nothing new in October.

[Shannon V. OKeets]

December 3, 2014 Status Report for Matrix Games’ MWIF Forum

Versions
Version 1.2.3.2 was made an official release in late November.

I wasn’t able to clean up all the NetPlay bugs in November but I did make enormous progress on them. The plan is to let the beta testers work on testing version 1.3.0.0 for a week or so and then make version 1.3.0.x available as an open beta in mid-December. That will provide a couple of weeks over the holidays for public testing. We’ll fix any NetPlay problems encountered by players in that version in early January. An official release of a viable NetPlay version should be available in mid-January.

Bugs
My record keeping of reported bugs is up-to-date for emailed bug reports, but not for posts in the Tech Support forum.

I spent virtually all of November working on NetPlay bugs. So far I have fixed 53 NetPlay bugs reported in the Tech Support forum. There are only 6 remaining, but there are another 6 on my to-do list reported by the beta testers (or discovered by myself through alpha testing). That’s what I am working on presently.

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

AI Opponent
Nothing new in November.

[Shannon V. OKeets]

January 5, 2015 Status Report for Matrix Games’ MWIF Forum

Versions
Version 1.3.1.5 was made a Public Beta release just before Christmas.

I gave the beta testers a new version (1.3.2.0) yesterday and after they have a few days to work with it, it should become a Public Beta early next week,

It’s been a long time since the last official release but the fixes for NetPlay have annoyingly caused problems to occur in Solitaire mode in code that previously worked correctly. Nailing down a ‘clean’ version that improves the Solitaire mode of play has been very difficult while working on NetPlay bugs.

I wasn’t able to clean up all the NetPlay bugs in December (new ones kept being discovered). Once I get through the NetPlay problems reported by the beta testers, we’ll upload yet another a new public beta and fix any NetPlay problems encountered by players in that version. An official release of a viable NetPlay version should be available in mid-to-late January.

Bugs
My record keeping of reported bugs is up-to-date for emailed bug reports and for bugs reported by the beta testers in the private development forum. For posts in the Tech Support forum, my task list is incomplete; it’s sort of hit-and-miss: I worked on any NetPlay related bugs and anything that caused fatal errors. I’ll go through all the Tech Support posts over the next couple of days.

Just as I did in November, I spent virtually all of December working on NetPlay bugs. The beta testers reported another 20 NetPlay bugs during the month and I found an additional half dozen through my own (alpha) testing. Currently I have the NetPlay bug count down to 12. Half of them have to do with naval combat (deep in the list of naval combat subphases) and naval interception of overrun naval units (e.g., digressions during the Land Movement phase).

The remaining bugs reported are technical, related to logging into the NetPlay forum and maintaining the connection. Those are from over a year ago and I suspect that most of them no longer occur. For instance, I have found zero communication problems with NetPlay during my heavy testing of NetPlay over the past 3 months. But I still want to investigate all the reported NetPlay problems before deeming them ‘resolved’ and removing them from my task list.

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

AI Opponent
Nothing new in December.

===================
On the upside, my health is doing fine, with most of my doctor checkups now scheduled annually and no appointments until March. Starting in October I’ve been playing golf twice a week (walking the course) and losing ~2 pounds a month.

The construction for the remodeling of our condominium is now complete (as of December 23rd). It took 9 months to get that done: 9 weeks in the spring, 3 weeks in the summer, and 5 weeks in late fall. It is quite nice to not have workmen knocking on the door at 8:00 AM every weekday (and sometimes on Saturday), making a lot of noise and creating confusion, and staying until 4:00 PM. All that is left for us to do is to rehang our pictures.

The renovations for the master bedroom closet (floor to ceiling, 17 feet long) expanded its depth a couple of inches so we now have 22 inch deep shelves. At the top 13 inches of the closet, running 12 feet across, I have placed all my board games. There are ~120 of them, mostly from SPI (Strategy and Tactics magazines). In the front of that long expanse I have the nicer bookcase boxed games which indicate what genre is behind them. For instance, Bloody April is in front of the American Civil War games, Desert War in front of the WW II games, Napoleon at Bay in front of the Napoleonic games. It’s quite pleasant to have a place for everything and everything in its place.

[Shannon V. OKeets]

February 4, 2015 Status Report for Matrix Games’ MWIF Forum

Versions
Version 1.3.3.0 was made a Public Beta release in January. That version fixed several important bugs in the solitaire and head-to-head modes of play but was primarily concerned with getting a Public Beta version out to interested customers for testing NetPlay for Barbarossa. Under NetPlay, that version still has some known problems with naval operations. For the most part it should be able to play through the 5 turns of Barbarossa, provided naval combats are avoided.

I gave the beta testers new versions: 1.3.3.1, 1.3.3.2, and 1.3.3.3 during the month. For those versions I went back to fixing some small land combat resolution problems (primarily with the 1D10 CRT) and infrequent problems in air-to-air combat and air missions in general. For the last, multiple air mission attacks by different major powers was the most serious item that needed to be fixed.

I’m currently working on 1.3.3.4. For this version I am reviewing bugs reported with naval operations in solitaire mode, just to make sure that aspect of the game is clean. The idea here is that having cleaned up outstanding issues in land, air (e.g., air-to-air combat and anti-aircraft fore), and naval operations, I’ll be able to fix the remaining problems with naval operations in NetPlay.

Bugs
My record keeping of reported bugs is up-to-date for all three data streams: emailed bug reports, bugs reported by the beta testers in the private development forum, and bug reported in posts in the Tech Support forum. In January I was able to keep on top of those various reports much better than usual. Partially that is because the newer versions are much cleaner than their predecessors.

I might note here that both the beta testers and myself have encountered zero communication problems with NetPlay during our heavy testing of NetPlay.

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

AI Opponent
I took a couple of hours to review the Land Regions the AI Opponent will use when playing Barbarossa. The basic design for the AIO dealing with land and naval operations is to divide the world into 16 Theater of Operations (TOs), such as Western Europe, Eastern Europe, Mediterranean, Southeast Asia, etc. Within each TO there are varying number of Areas of Operation (AOs). The picture below shows four of the nine AOs in Eastern Europe: Central Western USSR, Southwestern USSR, Central European USSR, and Southeastern USSR.

Within each AO there are Land Regions. In the picture you can see the dotted lines that define the three land regions in the Southwestern USSR AO: Kiev, Kharkov, and Crimea. For Barbarossa, the AIO will use just the Eastern European TO, with some of its AOs excluded: Sweden, Turkey, and half of the Balkans.

All of the above work was done 2 or 3 years ago, with the vast majority of it done by Peter S.

In January Peter started to work on the formulae the AIO will need to set up the USSR at the start of the Barbarossa scenario. I was only able to spend a couple of hours helping him, but the beta testers have been reviewing and critiquing what he has done so far. The focus is on scrapping units and making decisions about which air units receive pilots (or the equivalent when not using the optional rule). For scrapping, we’ll just have several predefined scrap lists for the AIO to choose from. To assign pilots the process is more sophisticated.

What Peter has been working on is a formula for setting the absolute Combat Value (CV) for air units. Units with a higher CV will be given pilots before those with a lower CV. Obviously, for fighters the air-to-air factor is most important. How to differentiate based on other factors, such as range, is more subjective. But we want the AIO to have one formula for the absolute CV.

When choosing which units to build, the CV will be very important, but divided by the BP cost, so if everything else is equal, the AIO will build a 2 BP fighter before a 3 BP fighter. Similarly, when having to decide which unit to commit to a risky air-to-air combat, the AIO will prefer to send a less expensive unit.

But the relative CV for units is also situationally dependent. At times it will be better to send a more expensive fighter into a naval air engagement simply because it can reach a higher sea area section box. Clearly numerous other factors also influence those decisions.

Once the CV calculations are in place, the AIO will be able to assign pilots for each major power at the start of every scenario. Peter will then start work on deciding which units are assigned to each Land Region and then where those units should be placed within a land region. But that will just be for the USSR in Barbarossa.