|
Shannon V. OKeets -> RE: When? (1/1/2011 6:24:43 PM)
|
January 1, 2011 Status Report for Matrix Games’ MWIF Forum
Accomplishments of December 2010
Project Management
I monitored all the threads in the MWIF World in Flames forum daily.
I restructured by task list so the items needed to completely debug Solitaire play have highest priority. There are 169 bugs remaining for that and I am driving to fix them all by February 1st. Since there were 460+ at the high water mark this past summer, this is doable if I do not get distracted by other issues. To kill off 6 per day is my goal. Attached is my current spreadsheet on the bugs remaining [the bug counts don’t match because the spreadsheet contains items for the other modes of play].
The other big news is that Mitchell has volunteered to help with the MWIF programming. The MWIF code has a steep learning curve but he has overcome the first hurdles of installing/upgrading Delphi, Theme Engine, and the JEDI library. He can now recompile and link the MWIF source code to generate the MWIF.exe. That is not a minor achievement. You’ll find his summary of progress below in the section on NetPlay.
Hardware and Software
Mitchell is also doing detailed timing studies on why Theme Engine takes so long to switch between major powers. Once we have figured out where the time goes (lyrics from a 1960's song), we’ll be able to make changes. It is fruitless to make changes to Theme Engine and just hope they solve the problem.
I converted the Main menu from standard Windows style to Theme Engine. So, aside from the above problem, Theme Engine now runs cleanly under Win XP, Vista, and Win 7.
Beta Testing
I released versions 7.00.01 (6 fixes), 7.00.02 (20 fixes), 7.00.04 (14 fixes), 7.00.05 (21 fixes), 7.00.06 (6 fixes), 7.00.07 (14 fixes), 7.00.08 (10 fixes), 7.01.00 (11 fixes), and 7.01.01 (10 fixes), to the beta testers last month. This totals 9 new versions and 112 fixes, which is above average for both new versions and fixes. I changed the numbering to 7.01.00 because the patch count was getting pretty high for 7.00.
I removed all the calls to Scrap Unit Digression and added the new phase Scrap Destroyed Units so it precedes the Production phase. This had the unexpected benefit of maintaining a list of destroyed units for the turn that players can review. It only took a couple of minutes to add that list to the Pools form (where you can also view units in production, in construction, repair, scrapped, etc.).
I cleaned up all known bugs related to Stay-at-Sea and Sentry status. The later is a feature of the computer game which has a dual purpose: (1) skipping Sentry units when cycling through all the units that can move in a phase, and (2) during the stay at sea phases, those marked as Sentry automatically stay at sea.
I reduced the land movement bugs from 26 to 10. Some of these dated back to 2006. See the paragraphs on Player Interface below for more details.
Fatal errors are becoming more and more scarce and quickly corrected. I fixed a rather infamous one from CWIF that occurred during Vichy formation.
Saved Games
Saving and restoring games remains stable. I had to add a few more variables to the saved game format to handle changes to the player interface for land movement (see below).
Map and Units
Rob continues to send me updates of the naval unit writeups. Otherwise the data and graphics for the map and units are unchanged.
Scenarios and Optional Rules
I added code to handle specific rules for declarations of war in the Day of Infamy scenario.
MWIF Game Engine and CWIF Conversion
I reworked all the code and internal data related to transported units. Some of this involved renaming variables and functions so that I could read the code more easily. I did find redundant code and I cleaned up a lot of other stuff that was messy. One helpful change, purely cosmetic, concerned the 250+ references to TransportedBy being equal to nil or not. I changed “TransportedBy <> nil” to Aboard Transport and “TransportedBy = nil” to Not Aboard Transport. Removing the reverse negation really helps when reading the code. That is, in the CWIF code “not equal nil” implies the unit is aboard a transport, or more simply, ‘not’ implies ‘is’. It is very easy to misread logic sequences that contain what I am calling “reverse negation expressions”.
Another example of a CWIF reverse negation expression was the Ignore Notional Unit form. The defending player was asked if he wanted to ignore the notional unit in an invasion/paradrop. If you answered No, then the notional unit was added to the defending units: ‘no’ implies ‘add’. This past October (November?) I revised that form so the question now is “do you want to include the notional unit?”, so ‘yes’ implies ‘add’. It’s now named the Include Notional Unit form.
I also built an enumeration list of the possible relationships a unit might have in regard to transporting or being transported by another unit. CWIF used “if ... then ...” logic sequences to make these determinations (in hundreds of places). With the enumerated list, MWIF code replaces those with a single case statement based on TransType. Here are my in-line comments on the enumerated list values:
TransType is used to record the linkages between units that are transporting other units, transported by other units, or have recently unloaded from another unit.
• trtyIng1 - Self is currently transporting 1 unit.
• trtyIng2 - Self is currently transporting 2 units.
• trtyIng1U - Self is currently transporting 1 unit, but it had been transporting a second. Self is a non-carrier naval unit.
• trtyUnloaded1 - Self (a naval unit) unloaded 1 unit after moving.
• trtyUnloaded2 - Self (a naval unit) unloaded 2 units after moving.
• trtyBy1 - Self is currently transported by 1 unit.
• trtyBy2 - Self is currently transported by 2 air transports.
• trtyByR - Self is currently transported by a carrier & rebased from a different carrier in the AirRebase phase.
• trtyNormalUnload - Self unloaded from a naval transport that returned to port or Self unloaded from an air transport that was aborted in the Paradrop or AirTransport phases.
• trtyFromUnload - Self (a land unit) unloaded from a naval transport in the UnloadLandUnits phase.
• trtyFromInv - Self unloaded from a naval transport in the current or immediately previous Invasion phase.
• trtyFromAirRebase - Self (an air unit) unloaded from a naval transport or carrier in the AirRebase phase.
• trtyFromCarrier - Self is a carrier air unit either flying an air mission or engaged in a naval air combat.
□ In all the above cases the other units are stored in TransLink[1] and TransLink[2].
□ In the trtyBy2 case, TransLink[1] and TransLink[2] both have a TransType of trtyIng1, even though they are only carrying half of the transported unit.
□ In the trtyByR case, TransLink[1] is the current carrier and TransLink[2] is the carrier Self was aboard at the start of the phase.
□ In the trtyFrom and trtyNormalUnload cases, the TransLink[1] value is used to undo the move.
□ In the trtyFromInv case, the TransLink[1] value is used to determine from which section box the unit is invading.
□ In the trtyFromCarrier case, the TransLink[1] value is used when the player wants the carrier air unit to return to the carrier from which it started the mission.
What motivated me to spend a week making these changes was the difficulty in debugging the code related to undoing air and naval moves when transported units were involved. Picking units up from coastal hexes during naval movement was particularly complex. For example, in a single move, a transport could start empty in a port, go out to sea, then go through a different port and pick up a division and then go out to sea again, stop, and pick up a carrier air unit from a coastal hex. Then the player decides to cancel/undo the move - so the program logic has to be capable of getting all the units back to their correct starting points. As you can see from the above list, that is only one of the dozens of possible air and naval moves that require special code so the move can be correctly ‘undone’.
Once all the changes to the transported unit code were made, I was able to clean up ~10 bugs related to transported units painlessly, and in the sure knowledge that the changes weren’t going to mess up any of the other cases in the above enumerated list.
I revised the code for placing units in off-city hexes when that optional rule is in effect. This change was to accommodate more than 1 major power placing units during the Reinforcements phase. The CWIF code assumed there would only be 1 major power doing that at a time, but with NetPlay there could be as many as 6 major powers doing so simultaneously. Therefore, there needed to be separate variables for each major power instead of a single variable. This affected a lot of variables, especially in save and restore game. It is also why the version 07.00.03 was never uploaded. I made the new changes to GameSaveRestore for 07.00.04.
Player Interface
I added names to the Unit Data Panel, so transported units identify which unit(s) they are carrying and transported units identify by which unit(s) they are being carried.
I identified a dozen queries where the player may want to examine the map and other forms before answering the question. For example, when Germany is deciding whether to grant the USSR’s claim on the Finnish borderlands, checking the disposition of the USSR forces is a good idea. Instead of these queries being shown on a modal form (which freezes the player interface until the question is answered), they are now shown using a non-modal form, so the player can dilly dally about looking into every unit stack on the map before making these decisions (as he might infuriatingly do in an over-the-board game).
I added double-left-click to select all naval units in the Setup Tray. This is in lieu of Ctrl A for selecting all units. The units selected are those shown using the setup tray’s filter (e.g., just battleships). The purpose here is to enable a player to select a large number of naval units for placement without having to click on individual units. Selecting all air units is difficult to design and code because of the need to decide which units go to the reserve pool. And selecting all land units doesn't make a lot of sense because of stacking limitations. So, this feature is just for naval units.
I added a unit menu item “Return from Whence” for air units that fly missions. Clicking on this menu item returns the air unit to the hex or carrier from which it started the mission. This saves a lot of time if you simply want air units to go back to their original air base/carrier. That’s especially true when you have a lot of carrier air units returning from a naval air combat. In combination with the Selectable Units form, which lists all the air units returning to base, players can complete a return to base subphase quickly, without little effort.
I clarified the anti-aircraft results form by adding some more information. I decided when a person who has been an active beta tester for CWIF and MWIF (over 12 years) gets confused, it is time to change the displayed information.
Lastly, I made final decisions concerning the player interface for land movement and wrote new code for about half of them. These problems were identified early in my work on MWIF, in 2005 and early 2006. But I had a lot of other things that needed to be done first, so I have let them simmer for years. Occasionally the topics would surface again in the beta tester development forum, but they were very thorny issues and intricately interrelated. I am now confident that I have solutions for all of them and I am working on writing the code to implement them. The problems were:
1. Partial movement of a unit such that the unit has movement points remaining. This occurs when a stack overruns enemy units and still has movement points remaining. The stack’s move can be interrupted by a digression to rebase overrun units.
2. Undoing moves.
3. Friendly and enemy units whose supply status changes during the phase.
4. Overstacking.
Our primary goal is to make MWIF play like the board game. While the WIF FE rules impose rigid restrictions on what can and can not be done, in practice over-the-board players use looser rule interpretations. It is common practice to let a player “take back” several moves during the land movement phase, as long as nothing substantial has happened and everyone can agree on where the units started the phase. Likewise, swapping units between hexes that are fully stacked is usually permitted, as long as the overstacking is corrected by the end of the ‘step’. But enabling these abilities lends itself to potential abuse by players of MWIF. Hence the need to define exactly what is and is not permitted for the above 4 items. For details, see section 8.4.5.1 of the Players Manual, which is appended to the end of this report.
Internet - NetPlay
From Mitchell (edited by Steve):
Steve asked me to see what I could do to get NetPlay fleshed out sufficiently to start testing MWIF’s multi-player modes: NetPlay and PBEM. Being new to the project, this meant coming up to speed on the Delphi IDE, the Indy socket library, and the earlier version of NetPlayComTest. After much experimentation, I developed several interim NetPlayComTest versions and tested them in small group sessions, culminating at the end of the month with uploading NetPlayComTest version 1.2.0.0 for all the beta testers to test. Feedback from the beta testers running NetPlayComTest on a variety of network setups will enable me to validate a final version of NetPlayComTest. Then that code can be integrated into MWIF’s NetPlay. [Note that NetPlayComTest will be a stand alone executable for delivery with the released MWIF product, so players can test their internet communications without having to run a MWIF game.]
A key concept for NetPlay is that one or two of the players’ computers act as a server. NetPlay supports from two to six players, with one player on each side acting as Leader for that side. Each Leader’s computer can act as a server (in the network sense) for his side, and one Leader’s computer is the game’s Master server. The Master server keeps the master record of game state, marshals communication between players and sides, makes die rolls, etcetera. Which player’s computer acts as Master and/or Leader depends on the scenario played, the number of players, and possibly the stage the game is in. For example, one server is sufficient unless there are 4 or more players in the game.
Having a player’s computer act as the game server is a different architecture from what many online games employ, where there is usually one or more dedicated servers/machines that each player logs into. While this common approach scales well and so can support massively multi-player games, it lacks the kind of flexibility desired for MWIF. MWIF contains many features that will help make the speed of play comparable to WIF, the board game, but MWIF playing sessions are still likely to be protracted affairs. To maintain maximum flexibility in the event of lost connections, players having to log off and back on for various reasons, and so on, NetPlay is designed so that any player may act as the game Master and/or side Leader as the game progresses and players (or even all players on one side) leave and rejoin a game. This architecture is a challenge to implement programmatically but doable, and it should serve well for the style of play MWIF demands.
The state of NetPlay development as of 31 December 2010 is summed up in the functionality of the latest NetPlayComTest version: up to six computers on a LAN and/or the Internet can establish communication through NetPlay and use the link to send and receive message packets reliably for extended periods.
Steve had already set up a framework in MWIF for building the necessary message packets containing game state and event information, so adding the communication functions from the test utility should bring us very close to testing MWIF multi-player modes. The next steps in NetPlay development are:
1. Add a NetPlay setup dialog to allow entry of IP Addresses associated with each player and to keep track of which players are the game Master and Leaders, and who is playing which Major Power Group. This information will persist in an associated INI file that can also be used by MWIF.
2. Set up and attempt to establish connections automatically based on information read from the INI file.
3. Attempt to reestablish communication links if and/or when they are dropped.
4. Reassign computer roles of game Master and Leaders if players, or a whole side, drops out intentionally or unintentionally, temporarily or for the duration of that gaming session.
5. Add PBEM simulation, replacing TCP message transactions with programmatically generated email messages but using the same logical player framework outlined above.
6. Integrate everything back into the MWIF code base, replacing test messages with the Game Record Log messages, support for game re-synch from the Master, chat between players and among each side, etcetera.
Please let us know what you would like to see in the way of inter-player communication support.
PBEM
Once Mitchell gets the NetPlay communications working, he’ll do the same for the PBEM communications.
Artificial Intelligence (AI)
Nothing new.
Player’s Manual
I added new subsections in the Player Interface section, specifically addressing how to move land, naval, and air units. While the description of the keyboard and mouse commands is accurate and complete, it doesn’t really answer the questions new players are likely to have about how to “get things done”. I’ve appended the new subsection on moving land units to the end of this report. I still need to write similar subsections for moving naval and air units.
Tutorials, Training Videos, and Context Sensitive Help
Nothing new.
Historical Video, Music, and Sound Effects
Nothing new.
Marketing
Paul is now the administrator for the fan site.
Communications
Nothing new.
===========================
8.4.5.1 Land Movement
Left clicking on a selectable land unit during the land movement phase transfers it to the “moving stack”, which, if you are familiar with board war games, you can think of as “picking up a unit”. The cursor then displays the selected unit which is no longer shown in the hex it had been occupying. As you move the cursor over the map, the cursor superimposes a target symbol (circle inside a cross) onto the image of the moving unit to indicate a valid destination hex. For invalid hexes, a large X is superimposed. At the bottom of the Main form, a text message augments the cursor’s information. For example, for a valid destination hex, the number of movement points required to enter the hex is shown. If a destination is invalid, the text message explains why.
Default Path
The easiest way to move a unit is to “pick one up” and left click on a destination hex. The program finds the fastest path to the destination hex. Here fastest means the path that requires the fewest movement points. Although visually the unit appears to ‘jump’ from its original hex to the destination hex, in actuality the program moves the unit along the fastest path, just as if you had moved the unit one hex at a time.
Precise Path
If you do not want to use the program’s chosen path, you can control which hexes the unit enters by holding down the Ctrl key and left clicking on each hex in the path you want the unit 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 several hexes away. Entering a precise path for a unit is often done by the German player when advancing through Russia to make sure that control of every hex changes from the USSR to Germany.
Group Movement
If you want to move several units as a group (e.g., to conduct an overrun) you can either select them using the Flyouts form (see section 8.4.6), 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 hex. Once you have selected a group of units, you move them the same way you move a single unit.
Partial Movement and Overruns
You can move a unit to a preliminary destination hex and then pick it up again and move it to a final destination hex. In fact, this is what happens when you hold down the Ctrl key to enter a precise path. This ability is most important when you conduct an overrun. After the defending units have been destroyed, captured, or forced to rebase in an overrun hex, you can continue to move the overrunning units by picking them up again, provided they have movement points remaining. Because of the zones of control rules, for some overruns you may have to first use the Ctrl key to move your units to the hex adjacent to the hex you want to overrun and then pick them up again and click on the overrun hex.
Once you have completed moving a unit or stack of units and picked up a different unit, you can no longer go back to the first group and move them again. This is true even if the first group still has unused movement points. This is how MWIF implements the Rules As Coded rule: “You must finish moving the unit(s) you are moving before you can start moving another unit”.
Undoing Moves
MWIF is somewhat forgiving in that it usually permits you to undo your moves without regard to the order in which they occurred. For example, you can move unit A, then move unit B, and then go back and undo unit A’s move. Indeed, there is a menu item on the drop down Command menu of the Main form that lets you undo all moves. There are two important exceptions to this leniency.
1. Should you conduct an overrun, then all the moves you made prior to the overrun can no longer be undone. The overrun might even have been made by one of your allies, and occurred thousands of miles away. Regardless of where and what is overrun, as soon as an overrun is performed, all land moves made previously in the impulse become permanent and can not be undone.
2. Should an out-of-supply or isolated unit have its supply status improved (e.g., from out-of-supply to in-supply), then the program marks the unit with the Improved Supply Status as ISS. If an ISS unit moves, then all moves made prior to that action are ‘frozen’. That is, you are unable to Undo any previous moves unless you first Undo the ISS unit that moved. The reason for this rule is to prevent exploitation of the Undo move to circumvent the rules by, say, (1) moving a unit to provide supply to other units, (2) moving the newly in-supply units, and then (3) undoing move #1.
Overstacking
In general, units may not overstack during land movement. However, MWIF enables temporary overstacking, primarily to enable players to rearrange units in hexes that are fully stacked. A typical instance of this is when the French have 2 corps in every hex of the Maginot Line and want to switch which units are in which hexes. To facilitate this, MWIF permits units to be overstacked when a unit, or stack of units, ends its movement. But then the next unit or stack of units that moves has to correct the overstacking. In the case of two French corps, A and B, in Metz, and two more corps, C and D, in Strasbourg (adjacent to Metz), the player is permitted to move unit A to Strasbourg, even though that causes overstacking. But then his next move has to be to move unit A, C, or D out of Strasbourg, to eliminate the overstacking.
Temporary overstacking enables you to move a stack of units from behind your lines up to a hex in your front line (which becomes temporarily overstacked) and then continue moving by overrunning units in the enemy’s front line.
Another subtlety of land movement and overstacking is when an HQ or an engineer has been used to enable air units to overstack in a hex. Moving the HQ or engineer out of the hex would then cause the air units in the hex to be overstacked. MWIF permits this overstacking to occur, and permits it to remain in effect until the end of the land movement phase. So, if you move an HQ out of a hex, causing air units to be overstacked, later in the phase you can move another HQ (or an engineer) into the hex, thereby negating the overstacking. Failure to correct the overstacking by the end of the land movement phase means the owner of the air units has to chose which air unit(s) to destroy.
[image]local://upfiles/16701/5BE72B8AA3AB4DDDBB7AD79610078362.jpg[/image]
|
|
|
|
