|
Shannon V. OKeets -> RE: When? (4/2/2011 12:39:18 AM)
|
April 1, 2011 Status Report for Matrix Games’ MWIF Forum
Accomplishments of March 2011
Project Management
I monitored all the threads in the MWIF World in Flames forum daily.
There are 83 bugs remaining in the sequence of play. I had the count down to a low of 81 a couple of times this past month but I haven’t been able to crack 80 yet.
Rolf did some work on the LAIO parser (see the section on AI below). Mitchell has had some pressing matters in his home life and was unable to spend time on MWIF in March.
Hardware and Software
I purchased an upgrade to CorelDraw so I can run it under Win 7. I don’t use this graphics package as much as I use to, but it still is my primary tool for creating and maintaining graphics for help files (e.g., unit status indicators).
The only open item with Theme Engine concerns the scroll bars for the detailed map. At some point I want to fix that so all the scroll bars in the game are identical, but that’s no big deal.
Beta Testing
I released versions 8.00.02 (20 fixes), 8.00.03 (17 fixes), 8.00.04 (11 fixes), 8.00.05 (2 fixes), 8.00.06 (14 fixes), 8.00.07 (14 fixes), 8.00.08 (5 fixes), and 8.01.00 (20 fixes) to the beta testers last month. This totals 8 new versions and 103 fixes, which is slightly below my average number of fixes for a month. There was no version 8.00.01. Every so often I modify the format for saved games and have to skip a version number as far as the beta testers are concerned.
Obviously versions 8.00.05 and 8.00.08 fixed major problems that I had created in the previous version - hence the immediate release of a new patch the next day. I changed the numbering to 8.01.00 because the number of patches was growing too large.
The breakdown by “the date the bug was first reported” is:
2006 - 3
2007 - 0
2008 - 0
2009 - 16
2010 - 22
2011 January - 14
2011 February - 15
2011 March - 13
A quick summary would be: 1/4 from prior to 1020, 1/4 from 2010, and ½ from the first 3 months of this year. What I take from the above statistics is that I’ve cleaned up thousands of old bugs but new ones keep appearing. This reflects the ability of the beta testers to go through the sequence of play more often/faster (because there are fewer problems), which enables them to encounter situations they hadn’t seen previously.
I focused on the naval movement bugs this past month and reduced them to zero - several times (the beta testers keep me honest). So, I believe that all the code related to moving naval units is now bug-free (I’m always the optimistic programmer). There are 13 naval combat bugs and 28 having to do with routing resources overseas. The other half are scattered about in different places in the sequence of play.
In reviewing the 103 fixes for the past month about 2/3rds related to either naval movement or naval combat. Naval air combat is very complex and a bear to debug because of all the possibilities. Especially troublesome has been aborting air and naval units from the different places in the combat where that can occur (see the Players Manual section 8.4.5.4 Air Movement which is appended to the end of this report). These days my main difficulty with the other bugs scattered throughout the sequence of play is recreating them so I can figure out what is going wrong. I have 300+ saved games that let me test individual phases and subphases in the sequence of play, but things that happen rarely (e.g., Turkish units moving into Greece, conquest, surrender, and liberation of major powers) are not in my quiver of saved games.
Fatal crashes are rare, perhaps a half dozen in the past month, and I was able to fix almost all of those immediately.
Saved Games
Saving and restoring games is stable. I continue to make small changes to the saved game format as I find a need for additional variables to keep track of the game state.
Map and Units
Rob and Adam continue to send me new and/or updated naval and land unit writeups, respectively.
Scenarios and Optional Rules
I made half the sea areas illegal to enter for the half-map scenarios. For instance, when playing Fascist Tide (the war in Europe) entering the Indian and Pacific Oceans is not permitted. Orm has been testing Fascist Tide and there have been several things I needed to fix related to the special rules for half map scenarios. Orm is also testing head-to-head/hotseat play. There isn’t a lot to that from a programming point of view. Mostly, the program needs to display a form/message that says to switch to the other player/side.
MWIF Game Engine and CWIF Conversion
I added more information to the Main form's prompt message when it is possible to move naval units (cost in movement points and range for using safest route). More importantly, I revised the code for the internal record formats on which sea areas/ports the units-in-hand can move into. 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. The summary of naval movement that is appended to the end of this report (taken from the Players Manual 8.4.5.3 Naval Movement) should explain why I felt a strong need to make the code as easy to understand as possible.
The main effect on game play of the naval changes 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 and ‘dare' 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).
Player Interface
I enhanced the Drop Off Units forms to clarify 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.
I modified the Select Units form so it includes filters for movement points and range. For example, this lets you examine a large stack of naval units and quickly select just those with 6 movement points. I also increased the size of the form so more units are visible.
I updated and improved the unit status indicators. The main change was to clarify when a unit was receiving HQ support and/or engineer support. I also updated the help page for status indicators, including the graphics which were about a year out-of-date.
Internet - NetPlay
NetPlay is still in Mitchell’s hands.
PBEM
Nothing new.
Artificial Intelligence (AI)
I changed the fundamental data structure for the map so it can hold additional information on the geographical breakdown for the AIO. 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 Theater of Operation, Area of Operation, Land Region, and Sea Area Group files 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. The AIO uses this data to ‘understand’ the map.
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 newly added geographical data, the AIO can 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.
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. Peter is maintaining the data for those files, but Patrice has volunteered to do the hard task: entering a LR ID # for each land hex on the map (~20,000). I got this started by entering the data for Iceland (whoop-de-do!). I did that so I could test that the software found the correct LR name for each hex.
Peter continues to made excellent progress on the geographic breakdown for the AI Opponent with advice from Patrice and myself. To date, he has finished 8 of the 16 TOs: Western Europe, Eastern Europe (up to Siberia), Mediterranean, East Africa, West Africa, Middle East, South Asia (i.e., India), East Asia (i.e. China & Japan), and is working on Southeast Asia. The last includes the South China Sea, the Bismarck Sea, the Solomons, and the Marianas.
Rolf has made some progress on completing the parser for LAIO (Language for an Artificial Intelligence Opponent) scripts. That is slow going, which is understandable. There was a good reason why I stopped working on the parser where I did: the next step was really difficult.
Player’s Manual
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. There were also a couple of changes to bring RAC up-to-date with MWIF deviations/interpretations from/of Rules as Written (RAW).
Tutorials, Training Videos, and Context Sensitive Help
Nothing new.
Historical Video, Music, and Sound Effects
Nothing new.
Marketing
Nothing new.
Communications
Nothing new.
8.4.5.3 Naval Movement
Group Movement
If you want to move several units as a group, you can either select them using the Flyouts form (see section 8.4.6), the Naval Review Details form (see section 8.7.1.10), the Units in Hex form (see section 8.7.1.24), or using Ctrl-Left-Click in the unit’s start hex (see section 11.8). All the units you select have to have started the impulse in the same: (1) hex or (2) sea area and section box. Once you have selected a group of units, you move them the same way you move a single unit.
Default Path
The easiest way to move a unit is to “pick one up” and left click on a destination hex or sea area. The program finds the fastest path that avoids interception by enemy units to the destination. Here fastest means the path that requires the fewest movement points. Visually the unit appears to ‘jump’ from its original hex or sea area to the destination hex or sea area.
Precise Path
If you do not want to use the program’s chosen path, you can control which ports or sea areas units enter by holding down the Ctrl key and left clicking on each port or sea area in the path you want the units to traverse. In fact, you can combine these two methods. For instance you could use the Ctrl key and click on the first hex in the path and then release the Ctrl key and click on a final destination hex or sea area several hexes away.
Entering a precise path for naval movement should only be used if: (1) you are moving a group of naval units and want to drop some of them off in a sea area or port, or (2) you are moving into a port to pick up cargo. The disadvantage of using the Ctrl key for naval movement is that those moves cannot be undone.
Transporting Units
There are various combinations of naval units and transported cargo, many of which are only possible when playing with optional rules. See the following optional rules sections for those details:
• 9.2.1 Divisions
• 9.2.4 Frogmen
• 9.2.15 Carrier Planes
• 9.2.16 V-Weapons
• 9.2.17 Atomic Bombs
• 9.2.21 The Queens
• 9.2.27 Supply Units
• 9.5.3 Amphibious Rules
• 9.5.4 SCS Transport
Here are the possible combinations:
• Naval transports can carry 1 corps/army sized land unit, land based air unit, supply unit, or V-weapon.
• Naval transports can carry 2 ‘division’ sized units. For this rule, carrier air units and atomic bombs are considered division sized.
• The Queens can carry 1 corps/army sized infantry class unit.
• The Queens can carry 2 division sized infantry class units.
• Amphibious units can carry 1 corps/army sized infantry class unit.
• Amphibious units can carry 2 division sized infantry class units.
• Surface Combat Ships (e.g., battleships, cruisers) can carry 1 non-motorized division sized infantry class unit.
• Carriers can carry 1 or 2 carrier air units provided the summed air classes of the carrier air unit(s) is less than or equal to the carrier’s air class.
Units are typically loaded in port during the naval movement phase immediately before moving the naval units transporting them. However, it is possible to load cargo onto naval units by “passing through” a port. A third way to pick up cargo as part of the naval unit’s move is to: move a naval unit from a port into a sea area, have the naval unit end its movement in the sea area, and then pick up cargo from a coastal hex. Finally, carrier air units can be loaded onto carriers during the Setup, Reinforcements, and Air Rebase phases. Carrier air units can also change which carrier is transporting them when the carrier air unit returns from an air mission or naval air combat.
All cargo is unloaded when a naval unit ends its move in a port. The sole exception is for carrier air units aboard carriers, which are only unloaded during: (1) the Remove Air subphase of the Reinforcement phase, (2) the Air Rebase phase, and (3) when flying an air mission or in a naval air combat. To be clear about this: carriers are the only naval units that may carry cargo (i.e., carrier air units) while in port.
Enemy Interception of Naval Moves
If you enter a sea area where enemy units can intercept your moving units, enemy players with units capable of intercepting are immediately asked whether they want to intercept. Regardless of their answer, at that point no previously made naval moves can be undone. This follows the general rule that once an opponent has to make a decision, no moves made previously can be undone.
If the naval interception is not attempted or fails, you have the opportunity to decide whether to have all your units stop in the sea area, continue moving all your units, or have some of them stop and have others continue moving. If the interception succeeds, you decide whether to have all your units stop in the sea area or to fight through. If you decide to fight through and survive the combat, you have the opportunity to decide whether to have all your units stop in the sea area, continue moving all your units, or have some of them stop and have others continue moving.
Sometimes you enter an enemy sea area even though you could go around it, because you want to take the most direct route to your destination. Remember, the default route avoids sea areas where enemy units are capable of intercepting the moving units, so it is quite possible that the default route uses more range and movement points.
Undoing Moves
As long as you do not use the Ctrl key for moving units and do not enter sea areas where enemy units are capable of intercepting your moving units, you can undo naval moves freely. This includes undoing moves where units were loaded from a coastal hex. If you use the Ctrl key to move surface naval units (i.e., not submarines), then that move cannot be undone. However, other naval moves made before and after using the Ctrl key can be undone freely.
The important point is that once a naval interception is possible, no naval moves made previously can be undone.
Overstacking
MWIF usually permits overstacking in ports during the naval movement and return to base phases. However, during the return to base phases, overstacking naval units in minor ports is not permitted. If you attempt to move units into ports where overstacking, a warning message that the hex will be overstacked is displayed. At the end of these phases, all stacking limits are enforced by the program and units in excess of the stacking limits have to be destroyed by their owners.
Naval Movement - in detail
The rules for naval movement are quite complex, primarily because of the possibilities of loading cargo, dropping off units, and being intercepted by enemy forces. On top of that there may be limits imposed on the number of naval moves permitted during the naval movement phase. The following enumerates all these possibilities.
There are 5 places in the sequence of play where naval units can move:
A. Naval movement phase.
A.1 From a port to a sea area.
A.2 From a sea area to a port.
A.3 Within a sea area, to a lower section box.
B. Return to base phases, from a sea area to a port.
C. Forced rebase due to the control of a port changing sides (e.g., overrun , conquest), from a port to a port.
D. Forced or voluntary return to base from a naval combat, from a sea area to a port.
E. Return to base by French naval units at sea during the formation of Vichy France, from a sea area to a port.
• Only A uses naval activities, and even then only when the major power owning the naval units took a Combined action.
• Only A.1 and A.3 permit a naval unit to end its move in a sea area. All the others must end in a port.
• Only A.1 permits loading a unit in port at the start of a naval move. Cargo must start the impulse in the port.
• Only A.1, A.2, and B permit loading a unit in a port while “passing through”.
• Only A.1 and A.3 permit loading a unit at sea at the end of a naval move.
• Only A.1 permits dropping off naval units in a sea area (using Ctrl-Left-Click). However, this can only be done if there are sufficient naval activities available.
• A.1, A.2, B, C, and D all permit dropping off naval units in a port (using Ctrl-Left-Click). However, during A.1 and A.2 this can only be done if there are sufficient naval activities available.
• For all moves except A.3 and E the player can specify which sea areas and ports the units traverse (using Ctrl-Left-Click).
• All except A.3 and E can be intercepted by enemy units.
• All naval moves in progress can be cancelled, unless units in the moving stack were previously dropped off, or the moving stack entered a sea area where it could be intercepted (regardless of whether it was or not).
• All completed naval moves can be undone, unless units in the moving stack were previously dropped off, or since the move was completed, any moving stack entered a sea area where it could be intercepted (regardless of whether it was or not).
Resolving interceptions of naval movement has the following logic branches:
1. Interception not attempted
1.1 All units continue moving (future movement by the units cannot be cancelled).
1.2 All units stop in the sea area. Only possible during A.1, loading units from coastal hexes permitted.
1.3. Some units stop and others continue moving. During A.1 this is only possible if sufficient naval activities are available.
2. Interception attempted
2.1 Interception failed
2.1.1 All units continue moving (future movement by the units cannot be cancelled).
2.1.2 All units stop in the sea area. Only possible during A.1, loading units from coastal hexes permitted.
2.1.3. Some units stop and others continue moving. During A.1 this is only possible if sufficient naval activities are available.
2.2 Interception succeeded
2.2.1 All units stop in the sea area.
2.2.2 All units “fight through”.
2.2.2.1 All units destroyed in naval combat
2.2.2.2 Combat resolved to quiescence and some moving naval units survive.
2.2.2.2.1 All surviving units continue moving (future movement by the units cannot be cancelled).
2.2.2.1.2 All surviving units stop in the sea area. Only possible during A.1, loading units from coastal hexes permitted.
2.2.2.1.3. Some units stop and others continue moving. During A.1 this is only possible if sufficient naval activities are available.
8.4.5.4 Air Movement
Default and Precise Paths
The path that an air unit takes is immaterial, unless you are playing with the optional rule En-route Aircraft Interception.
Group Movement
Air units are always moved one unit at a time, although they may be carrying cargo.
Undoing Moves
Air unit moves can always be undone during the subphase in which they are moved, unless you are playing with the optional rule En-route Aircraft Interception.
Return to Base Moves
One convenience for returning air units to base is available on the popup unit menu. If you Right-Click on an air unit that needs to return to base, one of the popup menu items is “Return from Whence”. Clicking on that returns the air unit to the location from which it began the air mission. Exactly where in the sequence of play air units return to base is varied, as explained below.
Returning a land based air unit from an air mission to a land hex is simple. You select the unit and drop it on the hex where you want it to land. For carrier air units, a form is displayed that lets you select on which carrier you want to land the unit. If only one carrier is available, then the program lands the carrier air unit for you automatically. In situations where you have multiple carrier air units to land or if there are multiple carriers on which to land, then the displayed form lets you choose which carrier air unit lands on which carrier.
Returning from a naval air combat is similar but more complex. There are 5 points where an air unit might return to base from a naval air combat:
a aborted due to an air-to-air combat abort result,
b aborted due to its side aborting from the air-to-air combat,
c bomber aborted due to an AA fire abort result,
d "returns to base" after a naval (air) combat round, and
e entire side voluntarily aborts from a naval combat.
For the purpose of this discussion, there are 3 'kinds' of air units. What happens to each of them when they return to base differs depending on circumstances.
A Land based air units present in a sea area section box that was included in the combat.
a, c, e returns to base in a land hex and become disorganized.
b, d 'return' to the sea area section box they w in when the naval air combat began (organized status unaffected).
B Carrier air units (when playing with the optional rule Carrier Planes) were aboard a carrier that was included in the combat.
a, b, d 'return' to any undamaged carrier on which they can fit (organized status unaffected).
c can not occur.
e 'return' to any undamaged carrier on which they can fit (organized status unaffected). The carriers then abort.
C Temporary carrier air units (when not playing with the optional rule Carrier Planes) were generated automatically by the program for each undamaged carrier that was included in the combat.
a, b, d removed from the game; their carriers’ organized status is unaffected.
c can not occur.
e removed from the game; their carriers’ organized status is unaffected, but the carriers then abort.
|
|
|
|
