|
Shannon V. OKeets -> RE: When? (1/2/2012 8:14:26 PM)
|
January 1, 2012 Status Report for Matrix Games’ MWIF Forum
Here is 2011 in review.
Accomplishments of 2011
Project Management
I monitored all the threads in the MWIF World in Flames forum daily.
I had two major health issues in 2011: surgery in August in Philadelphia for an ocular melanoma and surgery in October in Honolulu for a kidney stone. All-in-all I lost a couple of months of productive time due to those problems. My vision is still impaired, which limits the number of hours I can work on the computer each day to 6-8, down from 10-12.
Mitchell and Rolf joined the programming team at the beginning of the year. Mitchell had a serious health problem in July and was unable to work on MWIF thereafter, so we only had the benefit of his expertise for the first 6 months of 2011. During that time he did timing studies on why Theme Engine took so long to switch between major powers (3 seconds). Based on his analysis, he was able to reduce the elapsed time to effectively zero. With that accomplishment behind him, Mitchell turned his attention to NetPlay and completed refinements to NetPlayComTest, which will be included as part of the released MWIF product. NetPlayComTest lets players test their internet communications without having to run a MWIF game.
Rolf converted a couple dozen record types in the CWIF’s Windows Messaging code for communicating over the internet to MWIF’s Game Record Logs. Those record types were some of the most complex, which involve moving units. Rolf also did some work on the LAIO (Language for Artificial Intelligence Opponent) parser, which reads scripts written in LAIO. Later Rolf worked on fixing bugs in the sequence of play. His availability was limited, since he was holding down two other jobs at the time.
Hardware and Software
Delphi 2010 continued to misbehave badly during 2011. Delphi is the software development package I use to edit, compile, and link the source code into the executable program MWIF.exe. I successfully work around Delphi’s more serious problems but in the last quarter of 2011, it developed the nasty habit of simply not starting. After losing 5-6 days trying to figure out why the application wouldn’t start (when I clicked on the Delphi icon to run it, it went into an infinite loop trying to load a JPG). I finally found a writeup on the internet by someone who had had the same problem and documented a solution: remove the browsing history files created by Internet Explorer! That worked like a charm. Why the existence of those files should confuse the Delphi application baffles me; perhaps because Delphi executes a Java script when it starts up?
The open items for Theme Engine remain unchanged: (1) scroll bars for the detailed map, and (2) its inability to display detailed listings of file directories (i.e., the dates and stuff when opening or saving a file). In my opinion, neither of these is important. Theme Engine is the software library I use to transform all the forms and buttons into something other than the bland gray backgrounds and images that are the Microsoft defaults. Early in the year I converted the Main from standard Windows style to Theme Engine. So, aside from the just mentioned two problems, Theme Engine is now in use for all 160+ forms and runs cleanly under Win XP, Vista, and Win 7.
Beta Testing
I released 85 new versions of the program with 1144 fixes to the beta testers during 2011. The version numbers ran from 7.01.02 through 09.03.01. For most of the year I focused heavily on fixing bugs in the sequence of play, hence the large number of new versions and bug fixes. In November and December I devoted almost all my time to rewriting the routine for determining supply. In the last week of December I also worked on NetPlay. Both of these mini-projects required all of my focus just to keep straight in my head what the code was suppose to do and how it did it. I’ve compared the complexity of coding the supply for World in Flames to solving Rubik’s Cube blindfolded. As you can see below, for those two months I effectively stopped working on fixing bugs reported by the long-suffering beta testers.
Here is a breakdown by month of the new releases and fixes:
• January - 10 new versions and 168 fixes
• February - 7 new versions and 118 fixes
• March - 8 new versions and 103 fixes
• April - 9 new versions and 128 fixes
• May - 9 new versions and 115 fixes
• June - 10 new versions and 79 fixes
• July - 6 new versions and 109 fixes
• August - 5 new versions and 69 fixes; surgery for ocular melanoma.
• September - 9 new versions and 117 fixes: surgery for kidney stone.
• October - 10 new versions and 128 fixes
• November - 1 new version and 9 fixes; supply rewrite.
• December - 1 new version and 1 fix; supply rewrite.
Aaron took over my master task list of bugs in August. He converted the simple text file I had been using to a spreadsheet and did an excellent job of synthesizing the disparate files from beta tester posts, saved games, and MadExcept reports, into a coherent mass. He prefaced the name of each file with MTL xxxx where xxxx was the Master Task List number for the bug. Working from his spreadsheet (which he updated daily) I was able to read about each bug, find the associated saved game, and reproduce the problem. In my opinion, the work he did on this offset the reduced number of hours I was able to work after my eye surgery, so my productivity remained about the same. Unfortunately, he came down with pneumonia in early November, after which I was once again left to my own devices. I learned from what he did and now use his system for naming files. However, maintaining the spreadsheet would take me more time than I would gain by its use.
Rob W. ran a complete set of tests on land movement for all unit types in all hex and hexside terrain types, under all weather conditions. That was hundreds of cases. I corrected the only bug he found in calculating land movement costs: when moving from a desert hex to an all lake hexside during snow.
Then Rob went through all the US Entry Options and US Entry Actions to make sure the code functioned correctly. As any experienced WIF player would expect, several questions about rule interpretations arose. After adjudication, Rob ended up identifying about a dozen bugs that needed to be fixed; only a couple of which concerned US Entry Actions. What was really impressive about Rob’s work here was getting the game to the point where each of these could be tested. He now has a saved game for each of them so he can determine whether my corrections work or not. I have fixed most of those bugs, with only a couple lingering on my task list.
Lastly, Rob ran a thorough set of Vichy tests: creating, playing, and collapsing Vichy France. I was able to fix some of them as he reported them but his final list in November added 17 new items to my task list.
I made good progress on Head2Head (a.k.a., HotSeat) play with the help of Orm. I believe that mode of play now executes cleanly.
As of today 132 of the 152 phases/subphases/sub-subphases/digressions that constitute the sequence of play are bug-free. In fact, during 2011 I was able to reduce all but a half dozen of those to zero bugs outstanding. Sadly, fuller testing revealed more bugs. The most recalcitrant areas were: Supply, Naval Combat, Production Planning, Conquest, and Vichy.
I’ve fixed all but one of the bugs concerning nested digressions. This last bug is when a naval unit aborts from a naval combat and is intercepted before it reaches port. Other than that, I have the 7 digressions working as intended, with normal processing of the sequence of play interrupted by a digression, or a series of nested digressions, and ultimately returning to the point in the sequence of play where the first digression occurred.
Most of the beta tester bug reports in the last half of the year arose from: (1) rigorous testing of how the program performs under a variety of obscure circumstances, and (2) going over the rules with a fine tooth comb. See the section on Rules Precision below for some examples of the modifications I made to fix bugs.
In July (I think) I added code to enable the beta testers to change many of the optional rule settings on-the-fly. This will not be part of the released product but it gives the beta testers another tool when setting up saved games for testing how the game performs with various optional rules On/Off.
Saved Games
Saving and restoring games was stable throughout the year. I added the name of the current major power to the label for automatically saved games during 10 additional phases. This makes it possible to restore a game to a more precise point in the sequence of play.
Michael created 5 Fast Start saved games. Many people like to jump into a new computer game as soon as it is installed, picking up the rules as they go. To facilitate this, MWIF comes with Fast Start saved games for 5 of the most commonly played scenarios: Barbarossa, Guadalcanal, Fascist Tide, Global War, and Missed the Bus. All the Fast Start games use the solitaire mode of play and the Novice set of optional rules. The Fast Start games begin at the first major decision of the scenario. For instance, Barbarossa starts with Germany deciding whether to align Hungary or Finland.
Starting in August, Aaron began building a large library of saved games for testing the numerous phases in the sequence of play. Of course this is complicated by the number of different scenarios and optional rules, as well as modes of play (e.g., solitaire, head-to-head, NetPlay). But with the help of many other beta testers, he generated a large library of saved games. From my perspective, the best part of this are the saved games related to specific bugs. Those let me immediately reproduce bugs so I can both fix them and prove to myself that my changes work.
Map and Units
The data and graphics for the map and units were mostly unchanged in 2011. I added a graphic to visually indicate when captured red factories are not producing. I still need to figure out how to indicate visually that a factory has lost a production point. There was a small data correction for a couple of City Based Volunteer units.
Throughout 2011 Rob continued to create new and update old naval unit writeups. For the land unit writeups both Adam and Jimm returned to work and did a batch of new writeups. In early summer, Aaron took over responsibility for maintaining the master files for all the unit writeups , which meant less work for me.
Scenarios
Barbarossa
I added code so the legal sea areas for this scenario are limited to the Black, Baltic, and Arctic Seas. I made an adjustment to the Production form to handle the fact lend leasing air units isn’t permitted.
Fascist Tide and Day of Infamy
These are the two half-map scenarios. For each scenario I made half the sea areas illegal to enter. For instance, when playing Fascist Tide (the war in Europe), entering the Indian and Pacific Oceans is not permitted. I also made corrections for the rules uniquely associated with the half map scenarios. In particular, I intend to use the Azanian Sea (for Fascist Tide) and the Eastern Med (for Day of Infamy) as holding areas for the “Transfer Pool”. This way when a naval combat has to occur in the Transfer Pool, the players will be able to see the units therein just as for any other naval combat.
The victory cities for these scenarios are now correct and so are the lists of which countries are legal. I fixed a couple of bugs when setting up Day of Infamy: New Caledonia now goes to Free France and Vichy France gets French Polynesia and aligns Madagascar. Japan is then able to align Madagascar as long as Madagascar is controlled by Vichy France. What was so difficult about getting this code correct (almost a full day) was that Vichy France doesn't officially exist in the scenario. I still need to add code for the external/European event of Germany collapsing Vichy France so it occurs at a fixed point in the game.
Optional Rules
Partisans
I fixed a few bugs related to setting up partisan units behind enemy lines after all the major powers have been set up. This subphase of Setup was tricky to code. Annoyingly, it has to perform a preparatory check to see if there is enough room for the units to be placed on the map. If, prior to placing the partisans on the map, the enemy player positions his units well, he can sometimes cover all possible placement locations with zones of control. That results in zero partisan units being capable of setting up.
Warlords
I fixed all reported bugs related to Warlords.
Off City Reinforcements and Territorials
I did quite a bit of work to fix bugs in the intersection of these two optional rules. Both are now bug free.
7 Unfinished Optional Rules for Initial Release
I worked on 7 incompletely coded optional rules that I want to include in the first release. To accommodate the associated rules I added 4 subphases to naval combat: Voluntary Abort by Walther Submarines, Kamikazes, and 2 ASW Pre-fire Attack subphases. All 7 of these optional rules still need work. They are listed below.
Convoys in Flames
This is difficult to code because it has so many pieces. I’ve added the code for the +2 penalty when trying to intercept auxiliary cruisers. That was a bear to get correct because of the complexity of search roll modifiers and search numbers. I changed the production form selection of repaired Auxiliary Cruisers so which one is repaired is randomly selected. In all other cases, the player can choose which naval unit to repair.
City Based Volunteers
I made some progress on City Based Volunteers.
Unlimited Breakdown
I made some preliminary changes to support Unlimited Breakdown.
Kamikazes
This optional rule requires a tailored variation of the ubiquitous Unit Dialog form. For instance, when the Japanese player chooses whether his naval air bombers are flying as kamikazes, a Unit Dialog form appears listing all the bombers so the player can select which ones should wear head scarves.
Guard Banner Armies
This optional rule also needs a tailored Unit Dialog form so the player can select individual units for upgrades.
Rough Seas
No work done towards this in 2011.
Naval Supply Unit
No work done towards this in 2011.
Rules Precision (a.k.a. MWIF Game Engine and CWIF Conversion)
In the beginning of the year I spent a lot of time trying to debug the code for naval movement and naval combat. That became so tedious that I stepped back and revised the code for the internal record formats to determine into which sea areas/ports the units-in-hand can move. That is, once you select a group of naval units to be moved, the program has to check each hex the cursor moves over to determine if it is a viable destination. CWIF used the same record layouts for air rebases, all land unit moves, and all naval moves. I split those into 3 different record types (air, land, naval) since different information was needed for each record type. That let me clarify the names of the fields in each record so they explain the data better. The changes for the air and land moves had zero effect - since they effectively were just cosmetic. My main motivation was to make it easier to debug the naval movement code. I
The primary effect on game play of these changes to the naval movement code is that the program now assumes the player wants to avoid sea areas where the enemy can attempt to intercept the moving units, even if it takes more movement points. The player can always move directly to sea areas where the enemy can intercept thereby ‘daring' him to do so. If the enemy declines (or fails), the player can continue moving and perhaps reach his destination using fewer movement points and range.
I created a new ‘pool’: the Destroyed Units Pool. This is another off-map ‘location’ for units. It replaces the Destroyed Stack variable that I had been using. Besides maintaining standardization with all the other off-map pools, this addition makes it clear ‘where’ the unit currently resides. When players access the Pools form to review the units in the off-map pools, the Destroyed Pool is like all the others (e.g., Force Pool, Production Pools). At the end of the turn each player reviews his units in the Destroyed Units Pool and decides whether to scrap them or not.
Did some work on getting Search and Seizure to function. It can now identify when a search and seizure is possible and which major powers get to make those decisions. I still need to write new code to effect the results of search and seizure. Because that is closely related to Production Planning, I am waiting on coding the rest of S & S until I have PP bug-free.
I added some new code for the factory destruction phase. That was a little tricky because there are rarely occasions when a player wants to destroy his own blue factories. The two that come up are: France destroying a factory in Vichy France before Vichy France is declared, and the USSR destroying a factory in the Ukraine before Germany declares the Ukraine as a separate country. Most of the time the program ‘knows’ that destroying your own blue factories is senseless and can skip the phase completely.
At one point I had killed off most of the bugs related to creating Vichy France. In doing so I created a small new form so the Vichy France controller can allocate countries that were aligned or conquered by France to Axis major powers. But then Rob went through the rules about Vichy line by line and word by word. In November he found 17 more bugs related to Vichy, that are a lump in my task list.
As you can tell from the following, many of the ‘bugs’ reported by the beta testers in the last 4 months of the year were due to them either: (1) rigorously testing how the program performs under a variety of obscure circumstances, or (2) going through the rules with a fine tooth comb. I made changes for:
• Imposing a setup restriction on the Communist Chinese units so they have to be within 9 hexes of a Communist controlled city. This number of hexes is greater than what is stated in WIF FE because of the MWIF change in scale for China.
• Overrun naval units in iced-in ports, although having rolled well and being permitted to escape, are instead destroyed.
• Which major power decides about continuing to fight or abort from a naval combat is redetermined at the end of each round, and is decided by the major power on each side that has the most units still capable of fighting in the sea area.
• The WIF FE rules weren’t clear as what should happen when the Collapse of Vichy France causes Vichy France controlled minor countries to become owned by an Axis major power which has a unit present in the minor country. For instance, if Italy has a unit in Tunisia (which is controlled by Vichy France), then the rules state that Tunisia goes to Italy. But the rules say nothing about if there are both German and Italian units present. I decided to count the number of units and ‘give’ the country to the Axis major power with the most units present.
• Vichy France can be both hostile to and/or at war with Allied major powers. I revised the Relations form so those conditions are shown accurately.
• I fixed a bug in declaring Vichy France when non-French naval units are forced to rebase. This is the one place in the rules where ‘overrun’ naval units have to rebase to the nearest port, but can be intercepted when doing so. In all other cases the units either can not be intercepted, or else they have the freedom to choose any port within twice their range.
• I fixed a bug where liberating France while Vichy France still exists wasn’t converting all Metropolitan Vichy France hexes to French control.
• I fixed a bug so Vichy units can only move into hexes controlled by Vichy or by a country with which Vichy is at war.
• If France is liberated while Vichy France still exists, the major ports previously held by Vichy are undamaged when converted to French control. Usually when a major port changes control from one side to another, it becomes damaged. The problem this rule ‘interpretation’ avoids is having newly acquired French naval units overstacked in, say, Toulon.
• I added code so Vichy France can not build pilots or offensive chits.
• Minor country units are not permitted to enter the home country of another minor country on the same side unless Foreign Troop Commitment requirements have been met. That rule stops Hungarian units from entering Rumania, as one example. But in the case where the second minor country has been completely conquered, it seems that entry should be permitted. In one of the beta testers’ games the USSR had conquered Persia (which had been aligned to Japan) and then Italy aligned Iraq and had Iraqi units ready to enter and liberate Persia. Here the general rule would prohibit Iraqi units (minor country aligned to Italy) from entering Persia (minor country aligned to Japan, on the same side as Italy). But since Persia is completely conquered, it is now ‘owned’ by the USSR, with which Italy is at war, hence the Iraqi units are free to enter Persia. At least that is how I have coded it. My change is that if a minor country on your side has been completely conquered, then the FTC requirements no longer apply.
• Land units can now only be loaded on air transports if they are organized (Harry Rowland clarified this rule).
• I changed the code so when the US claims Greenland/Iceland/Northern Ireland, units belonging to other Allied countries therein are relocated to the nearest hex, rather than rebased. As part of claiming Northern Ireland, the US is permitted to place convoy reinforcements in Ireland - but not any other type of unit.
• I fixed a bug where the US was being permitted to DOW another major power after failing in an attempt to DOW a major power during the same impulse.
• When the US DOWs both Germany and Italy in the same impulse, two separate die rolls for US Entry are made. Furthermore, those die rolls and the associated mandatory movement of US Entry markers from the Entry Pool to the Tension Pool are made prior to the implementation of the optional movement of markers due to the automatic execution of US Entry Options. The automatic execution of US Entry Options only occurs if the US is at war with both Germany and Italy (or those countries have been completely conquered). This is another instance where Harry Rowland clarified the rule. There are a couple of more subtleties to this rule which are now coded correctly in MWIF.
• I implemented the following rule interpretation: Unit U is not permitted to fly to a naval combat sea area if:
(1) U's controlling major power is surprised by all the enemy units in the sea area, or
(2) all units friendly to U in the sea area are neutral or surprised [by all enemy units in the sea area].
• I fine tuned the code so land based air units that voluntarily abort from a naval air combat are handled differently from those that abort under any other circumstance. If they voluntarily abort from an air-to-air combat, then they return to the sea box section from which they entered the naval combat. If they otherwise abort, they must return to base (i.e., to a land hex) where they are disorganized.
• I removed the ability of land attacks being declared against a hex containing only enemy supply units.
• I enabled conducting ground strike and carpet bombing missions against a hex containing units with which you are not at war, if the hex is controlled by a country with which you are at war.
• AA units that fire during the ground support phase are not disorganized until after the Advance After Combat subphase.
• I fixed a bug where attacked partisan units were able to receive ground support from countries other than their controlling major power.
• I changed the test for conditions under which the Nazi-Soviet pact can be broken. Specifically, setting up or moving units within one of the countries listed for breaking the pact (e.g., Turkey, Sweden), no longer qualifies for breaking the pact, regardless of to whom the minor country is aligned. Basically, as long as the only units you move in the specified minor countries belong to the minor country itself, then the conditions for breaking the pact are not met. But if you move a unit from a different country into one of the listed minor countries, then the other side can break the pact. For example, if the USSR DOWs Turkey, which is then aligned to Germany, and Germany moves the Rumanian HQ into Turkey, then the USSR can break the pact. However, moving an Italian unit into Turkey would not affect the status of the pact, since Italian units are not controlled by Germany. This applies not only while setting up units, but throughout all phases of the game (e.g., including air units returning to base).
• When the US player has the option to move, or not to move, markers from the Entry Pools to the Tension Pools and there is more than one marker to be moved for an entry option, he has to either move all the markers for the entry option or none. The US player gets this choice when US Entry Options are made automatically after the US goes to war with Axis major powers.
• The requisite conditions have to be met before the US can occupy Greenland and Iceland even when that US Entry Option is ‘automatically’ selected due to the US going to war with both EuroAxis major powers.
• Allied units in Italy that count towards the conquest of Italy garrison value must be controlled by a country at war with Italy (clarification from Harry Rowland).
Failures in the CWIF code for determining supply was something I discovered within the first 15 minutes I had access to a copy of the game. That was a month before I became involved in this project. I ignored that bug, and other supply bugs, for over 6 years but finally bit the bullet and tackled rewriting supply in earnest on November 1st. Actually, I had done a significant portion of the ground work for the rewrite back in 2009, but there was a lot left to do. I won’t go into the gory details here but there are many rules concerning supply sources and paths that increase the level of difficulty in writing the code. In particular, differences between major powers and minor countries, and cooperation between countries was a pain. I have supply mostly working now and will hand it off to the beta testers this week. Still remaining is the problem of getting the program to update the supply status of all units instantaneously and continuously during the land and naval movement phases (i.e., after each unit is moved).
Player Interface
I created 6 new forms in 2011:
• Supply Sources and Paths. This identifies all the supply sources, primary and secondary, and shows how many units are being supplied by each. When you click on a supply source, the supplied units are shown in a list at the bottom of the form. For secondary supply sources, the supply path it uses to reach a primary is shown. Clicking on a unit image causes the supply path for the unit to appear. There is a special button for displaying all the units and secondary supply sources that are out of supply.
• Liberation. This tiny form simply asks a player if he wants to liberate, revert, or ‘neither’ when he controls the capital of a country that was on his side originally. The change here is to include the option to revert. Liberation of a minor country means it is aligned to its liberating major power. Reversion means it is aligned to the major power to whom it was originally aligned. If you do neither, then it is conquered by the major power controlling the capital. This is a ‘nag’ form, since if you choose neither, then you will be asked the same question again at the end of the next turn. I really dislike having ‘nag’ forms in the sequence of play but I couldn’t come up with another solution and remain true to WIF FE, where you can liberate/revert a minor country during any later turn if you so desire.
• US Entry Actions. This form is purely informational but I think compared to RAC it is a much cleaner presentation of the information. Hopefully having this accessible from within a game will make these concepts easier for new players to understand.
• Private NetPlay Forum. This form is used by players to find opponents for NetPlay (i.e., playing over the internet). It is only available to players who have purchased the game, and is accessed from the Opening MWIF screen. It is also used for each game session, letting players restart/join their game in progress.
• Keyboard and Mouse Commands Help.
• About the Current Game. This reports which scenario is being played, mode of play, and which players are playing. It is of minor importance for game play but is helpful for debugging purposes.
I substantially modified 7 existing forms:
• OverStacked. I revised where in the code checks for overstacking occur. When overstacking is detected, this form appears.
• Choose Naval Combat. The changes I made here give more emphasis to the list of sea areas. These modifications were part of a general revision of the form to fix a few bugs.
• Drop Off Units. The changes here clarified what happens when a group of naval units enters a port. It was easy to get confused when some of the naval units stopped in the port, while others in the moving group picked up cargo and continued moving.
• Select Units. The change was the addition of filters for movement points and range. For example, when examining a large stack of naval units, you can quickly select just those with 6 movement points. I also increased the size of the form so more units are visible.
• UnitData. This data summary panel now shows if a unit is flying a night mission and/or at extended range. This helps when returning air units to base after an air mission since now you know which ones flew at extended range. It also is of value when choosing targets in an air-to-air combat and for anti-aircraft fire.
• Status Indicators Help. This needed to be updated, especially the graphics, because it was a year out-of-date.
• Chat. CWIF had 3 forms for sending a message: Chat, New Message, and Recipients. I reduced that to a single form. The list of who receives a message isn’t very long, since is a maximum of 6 players in a game. The form now just has a checkbox for each player.
Within 9 minor forms I replaced a CWIF component for grids (TSimpleGrid) with one from the JEDI library (TJvStringGrid). The former was generating program crashes when the mouse wheel was touched while the grid was displayed. Visually there is no apparent difference. But TJvStringGrid does not crash the program, so the day I spent making the changes was well spent. I’ve now standardized on the use of TJvStringGrid throughout MWIF; it appears in 85 places.
I updated the Unit Status Indicators because there was a ‘hole’ in the design logic. Land based air units at sea during naval combat, which were not participating in the combat, were shown without any status indicator. I added a new value for these units to indicate that they are ‘flying’, even if they are not part of the naval combat. Another set of changes I made to the unit status indicators was to clarify when a unit was receiving HQ support and/or engineer support in a land combat. And to accompany the changes made to the UnitData panel mentioned above, I added indicators for units flying night missions and/or at extended range.
I added a couple of shortcut keys to access the US Entry Pools and US Entry Action forms. The third form in this group is the new US Entry Options form mentioned above. Together with the new section on US Entry that Aaron put together (see Players Manual below), these 3 forms should make it easier to learn this crucial game concept.
I imposed a restriction on moving land units so you are no longer able to partially move a unit, move a second unit, and then go back and continue moving the first unit. Doing this would violate the WIF rules. However, you are permitted to continue moving a stack of units that performed an overrun if you do so immediately after any overrun air and/or naval units have finished rebasing.
Internet - NetPlay
Rolf and I finished the conversion of CWIF’s Windows Messaging code for communicating over the internet to MWIF’s Game Record Logs. Rolf did a couple dozen, including some of the most difficult items which involve moving units. I did the final 80. The code now exclusively uses Game Record Logs and Indy10 (a Delphi software library that employs TCP/IP for internet communications).
The number of unique record types is around 400, one for each decision/event that occurs in the sequence of play. That number will probably increase slightly once we get heavily into testing NetPlay. For example, there are a bunch of optional rules which will need their own personal GRLs (e.g., Guard Banner Armies, Kamikazes, and Naval Supply Units). On average, each conversion required about 50 edits, spanning a dozen different modules. Making those 20,000 edits was spread out over several years, since I knew they would be onerous to do and had been chipping away at them off and on since way back when. With Rolf’s help I was able to finally finish them off.
The conversions to GRLs were essential for NetPlay and PBEM (that is: whenever more than 1 computer is being used). The most difficult were for moving units, especially naval moves, because of all the information required to keep track of exactly which units are moving through which hexes to reach their destination. Another reason behind creating the GRLs is that I am a firm believe in compartmentalized software. The GRLs isolate and completely remove NetPlay and Message Control code from all the details of how the game/simulation operates. NetPlay gets a simple string value with an identifier (ID number). It then sends it to its twin on another computer. That the game being played is World in Flames never impinges on the NetPlay code. To be clear about this, the code for NetPlay and the code for the game’s simulation of WW II are mutually exclusive.
As stated at the beginning of this report, Mitchell completed NetPlayComTest, version 2.0 which I then integrated into MWIF. It can be called either as a stand alone program or from within MWIF when a game is in progress. For those of you who don’t know, NetPlayComTest uses Indy10 to send and receive messages over the internet. It deals with all the issues of establishing communications between two or more computers. Then it permits the users to send messages back and forth. Its original purpose was to test the software for use by MWIF proper. But it will be included in the released product so players can test their communication links without having to run the game itself. If as a player you get NetPlayComTest to work for communicating between all the players in your game, then MWIF should run NetPlay without problems. Some of the issues it needed to deal with are IP addresses, port numbers, and firewalls - all that good stuff.
In December I added the ability of MWIF to access the Private MWIF NetPlay Forum. This forum is used by players to find opponents for NetPlay (i.e., playing over the internet). It is only available to players who have purchased the game. Access to the forum is via a button on the Opening MWIF screen. Besides finding opponents, it is used to start each game session, letting players restart/join their game in progress.
PBEM
Nothing new other than the decision to use the MultiPlayer++ system developed by Slitherine/Matrix Games for locating a PBEM opponent. This is the same underlying system used by the Private MWIF NetPlay Forum.
Artificial Intelligence (AI)
Peter finished the geographic breakdown for the AI Opponent. To go with that, I revised the documentation on the AIO command structure so each element of the geography has a corresponding decision maker. There are 16 Theaters of Operation (TOs) that span the global map. Within each TO there is a breakdown for naval units into Sea Area Groups (which contain individual Sea Areas) and for land units into Areas of Operations (which contain Land Regions).
I changed the fundamental map data structure to include information on the geographical breakdown. This should have zero effect on game play as far as human players are concerned. The change to the Terrain data adds a new field to each land hex to store the Land Region ID #. Along with this I added a new field to the Sea Area data to store the Sea Area Group ID #. And as the final pieces, I created simple files listing the Theaters of Operation, Areas of Operation, Land Regions, and Sea Area Groups which hold the details on each of those elements, including cross references. In practice, this means that the AI Opponent code can trace any land hex back to its LR, AO, and TO, and can trace an all-sea hex back to its sea area, SAG, and TO. In order to validate the new data I added a (debug) line under the Main form that shows and updates the TO, AO, LR, and SAG values as the cursor is scrolled across each hex.
The 16 TOs are: Western Europe, Eastern Europe (up to Siberia), Mediterranean, East Africa, West Africa, Middle East, North Asia (i.e., Siberia), South Asia (i.e., India), East Asia (i.e. China & Japan), Southeast Asia, Oceania (i.e., Australia), Pacific Ocean (central), Atlantic North America, Atlantic South America, Pacific North America, and Pacific South America. There are 126 AOs and 320 LRs. The major task remaining is to change the data file for the terrain, adding a digit to the end of the row of data for each land hex. There are 70,200 hexes, each of which has its own row of data. Mercifully, the all-sea hexes do not need to be edited (they use the default value).
The greatest advantage that a human player has over the AIO is the ability to literally ‘see’ the map. For the AIO it is just a bunch of incohesive data. Using the geographical data, the AIO can now assess the strength of the forces on both sides in a land region and decide whether to attack, maneuver, defend, or retreat. The same applies to AOs, SAGs, and TOs. This is my best attempt to mimic a human player simply looking at the map and making a quick assessment of the relative strengths of the two sides.
Another goal here was to provide a hierarchy of decision makers for strategic and operational decisions and a different decision maker for tactical decisions. For instance, decisions about convoy routes span multiple sea areas and are made higher up in the chain of command, while decisions concerning a specific naval combat are made by the Fleet Admiral responsible for the sea area in which the combat is taking place. Likewise army reinforcements are shipped off to various TOs, whose commander designates which AO gets them; the AO commander then designates a Land Region, whose Commanding General decides in which hex to place the new unit.
After completing the geographic breakdown of the entire global map (a massive task which required assessing all 70,200 hexes), Peter worked on the data structures for AIO strategic plans. I had already done some preliminary work on that. The goal is to design variables for holding all the information necessary to define a strategic plan for a major power. The 3 main elements are: (1) objectives to hold/take, (2) geographical areas to defend/attack, and (3) time lines for declarations of war/offensives, with accompanying production schedules.
Some of the strategic plan data defines conditions for when something should happen (e.g., when to start building garrison units). Defining data structures for conditionals is always difficult, but Peter and I already did some of that when we were working on setup scripts. It isn’t easy to take the amorphous advice provided by the forum members and render it into a rigidly structured outline for processing by a computer program. For instance, late in the year he was grinding out the precise conditions under which France should surrender.
Rolf made some progress on completing the parser for LAIO (Language for an Artificial Intelligence Opponent) scripts.
Rules as Coded (RAC)
I made a couple of changes to bring RAC up-to-date with MWIF deviations from Rules as Written (RAW). For instance, I added a description of the Naval Abort Queue. On August 1st I uploaded the final version (number 46!) of RAC for the Matrix Games Editor.
Player’s Manual
After querying forum members, Aaron wrote up a new subsection for section 3.4, Advice to Players: Understanding US Entry Options, Actions, and Pools. Composer99 provided the heart of this material. I made some final edits and now new players should have a better chance of understanding this crucial aspect of the game.
I added a subsection on Dropping Off Units to the Players Manual. That form is used for both dropping off units and, when in port, picking up cargo while passing through. I reviewed and updated section 10 of the Players Manual so it accurately lists all the RAC deviations from Rules as Written (RAW).
Aaron read through and made numerous changes/suggestions to the largest section of the Players Manual: 8 Players Interface. Equally important, he updated all the screenshots (~250) in the Players Manual. In many cases they had become woefully out of date.
The biggest editing changes Aaron made were for Production Planning. That form is very complex, since the tasks of fulfilling trade agreements, routing resources to factories, and saving oil/build points can potentially span the world map. Those are also critical tasks, since they directly affect production. Every player wants maximum control over these decisions, and a clear understanding of what is happening for his major powers, as well as for those commanded by other players.
What Aaron and I decided upon was to add a dozen or so small insert figures that are pieces of the overall Production Planning form. This means that when the text discusses, say, Filters for the resources and factories list, a little picture of the set of Filter radio buttons is shown. The overall effect is that it is much easier to understand the text by referring to the little figures instead of having to look back to a previous page and locate where the Filters are on the full-page form. I am now real happy with how this section reads, instead of being anxious about it being incoherent.
The beta testers were provided with the latest and greatest version of the Players Manual after Aaron’s revisions, and given the opportunity to make suggestions over a 2 week period. Aaron collected their comments and added another bunch of his own. While integrating that input into the draft, I read through all 400 pages of the Players Manual and made over 500 edits of my own. After typing in all these changes, on August 1st I uploaded the Players Manual with the up-to-date screenshots for the Matrix Games Editor.
I have a handful of small edits waiting the Matrix Games editor that I have accumulated since August 1st. There is only 1 glaring hole remaining in the text for the Players Manual: NetPlay instructions for starting, joining, and resuming a NetPlay game. There are a couple other bits associated with that too: chatting with other players and monitoring internet communication links.
Tutorials, Training Videos, and Context Sensitive Help
There is one missing screenshot for the Picture and Text Tutorials: Starting NetPlay game. The other 120+ pages are done and final.
This year I finished the design and code for the Interactive Tutorials. Each of the 10 tutorials will have a dozen or so ‘pages’ with 6 lines of instructions on the ‘front’ of each page and 7 lines of commentary on the ‘back’. The player can toggle between the front and back of each page, seeing either very terse instructions for entering keyboard and mouse commands, or commentary. The latter is the equivalent of a “voice over”. After performing the actions indicated by the instructions, the player clicks on the Next button to advance to the next page. I wrote a few sample pages to test the code and system design, but another 100+ pages of instructions with commentary need to be authored.
Throughout the year I made changes to the context sensitive help messages based on feedback from the beta testers. These are roughly 80% complete. The remaining 20% is not that difficult to do, since creating the missing content is done by cutting text from the Players Manual and pasting it into a TXT file.
I reviewed the training videos I made about 2 years ago. All 9 of the chapters I recorded have small discrepancies when compared with the current version of the game. But to my eye those are minor differences, and not worth re-recording an entire chapter. However, I need to redo chapter 6, since it references the production planning form and uses a completely out-of-date screenshot of that form. And chapter 9 also need to be redone because the Land Combat Resolution form has been substantially modified. But the other 7 chapters I think I’ll leave as is. I still have 3 more chapters to do: 10, 11, and 12, which cover naval movement, naval combat, and production & politics (i.e., declarations of war et al).
Here are the 12 chapters of the training videos.
Chapter 1 Introduction (4 minutes :10 seconds)
Chapter 2 Map Basics (20:27)
Chapter 3 Unit Basics (28:27)
Chapter 4 Sequence of Play (33:56)
Chapter 5 Turns, Impulses, Weather, & Supply (25:28)
Chapter 6 Main Form, Screen Layouts, & Map Views (46:31)
Chapter 7 Starting a New Game & Setting Up Units (55:40)
Chapter 8 Air Movement & Combat (23:43)
Chapter 9 Land Movement & Combat (43:46).
Chapter 10 Naval Movement (TBD)
Chapter 11 Naval Combat (TBD)
Chapter 12 Production & Politics (TBD)
Historical Video, Music, and Sound Effects
David Heath sent me the (nearly) complete set of music and sound effects files. I still need to insert ‘calls’ in the code to play these files at the appropriate points in the sequence of play. My design lets the player set how often the sound effects et al are played. That can range from never, to periodically, to always. Periodically would be something like: “every 10th time an armored vehicle moves play the sound effect.”
Marketing
Aaron worked with Sean Drummy of Matrix Games on updating the World in Flames screenshots displayed as part of the game’s description in Matrix Games’ list of products. Virtually all of them had been out-of-date.
|
|
|
|
