Shannon V. OKeets
Posts: 22095
Joined: 5/19/2005 From: Honolulu, Hawaii Status: offline
|
December 1, 2009 Status Report for Matrix Games’ MWIF Forum I. Project Management I still don’t know how long it will take me to fix all the bugs, but I continue to make progress on them. In November I focused 95% of my time on fixing bugs. For December, I will continue to work primarily on fixing bugs, with a small diversion to complete the LAIO parser. I spent several days revising my master task list. Besides redesigning how information is stored, I also grouped similar bug reports together. One major improvement is that the bugs are now listed in the order of the sequence of play. This lets me review, say, all the bugs reported concerning the Declaration of War phase, which has 9 subphases. Besides changing the order, I renumbered the current bugs starting with 100, so they are all 3 digits. My previous numbering had run over 2000, which I found discouraging to look at every day. Roughly, in the past 4 and ½ years I have fixed 1900 bugs that had the temerity to make it to my task list. Communications Mike (Players Manual) has progressed to beginning work editing the ‘big’ section (Section 8, Player Interface), but nothing new from Jim (sound effects), or Dave (music). I monitored all the threads in the MWIF World in Flames forum daily and uploaded versions 3.00.02, 3.00.03, 3.00.04, 3.00.05, and 3.00.06 for the beta testers. This exceeded my goal of a new version every week. Patrice continues to keep the map data up-to-date with small changes. This month he got some help from Orm and Alain, which is described below. Robert continues to do new naval unit writeups every week, while Alain and David maintain a similar pace on the Land Unit writeups. Michael has done a ton of testing on the sequence of play and, in combination with a half a dozen other beta testers, gifts me with a fresh set of bug reports for every new version I upload (their generosity knows no bounds). No communications with Harry Rowland or Chris Marinacci. Hardware and Software Development Tools I have decided that it is time to buy a new computer. The current one has served me well over the past 3 and a half years, but the salt air in Hawaii plays havoc with metallic elements. By now there are just too many things “not quite right”. I could provide a list of defects, but it would be boring to read. What I have started to do, and will finish in December, is make a detailed list of all the hardware and software in my current system and what I want in the new one. So far that is one page for hardware and a second for software, but it will probably be 6 pages total once I get everything identified precisely. When I was younger, I would configure a new system off the top of my head and then go buy it. But I’ve become aware these days I have a lot of ‘stuff’ on my system. I do not want to lose any capabilities, plus I have a couple of small items under ‘improvements’. Mostly I will be upgrading my software, with the big changes being to Windows 7, the latest Delphi, and the latest Theme Engine. The portable computer I bought last year runs under Vista, and I will stay that way. This will give me systems for testing both Vista and Windows 7. I expect to be able to test Windows XP under Windows 7 (can anyone confirm that for me)? I’ll purchase the new system in January and I’ve scheduled a week of misery getting it to perform as well as my current one. II. Sequence of Play Beta Testing I uploaded five new versions for the beta testers this month. Version 3.00.02 (18 changes) primarily fixed problems with naval movement. The rules for moving naval units is very complex with: limitations on which units can move together, activity limits sometimes imposed, restrictions on moving into some sea areas (e.g., through Gibraltar), dropping off units at sea/while moving through a port, loading units in a port/at sea/while passing through a port, possible naval interception, and resultant naval combat if an interception succeeds. Mixed into all of that are the naval moves that happen when aborting from a naval combat and naval units that are forced to rebase when overrun. The last can occur during the conquest phase and in several places when forming Vichy France. The code to enforce these rules while enabling the players to perform all legal actions is daunting to read, much less write and modify. The player interface design for naval movement has its own little tangle of interactions. Another change with this version was the addition of the optional rule Breaking the Nazi-Soviet Pact. That permits players to break the Nazi-Soviet more readily in 1941. Version 3.00.03 (10 changes) made “follow up” patches to naval movement. I added a trinary decision after naval interception if there are units still capable of moving. The third choice is for the player to drop off some units in the sea area (where the interception just took place) and have others continue moving. Note that this can happen whether the interception attempt succeeded or not. Also note that the dropped off units can load land units from coastal hexes. Once units have been dropped off, the remaining units need to have their maximum destinations redetermined since they may have dropped off slower units. Version 3.00.04 (19 changes) was mostly small changes. Some of these were eliminations of old bug reports that I could not reproduce. What happens is that I make corrections but do not necessarily update my task list in all the places where it should be updated. For example, if a beta tester emails me a bug report where the program crashed with a MadExcept error, I use the MadExcept report to locate the problem and fix the code. Linking that correction back to a specific bug report in the MWIF Development Forum isn’t always obvious. I also get a lot of duplicate bug reports (which is a good thing!). However, removing duplicate entries is time consuming and I begrudge the time when I am hot in the throes of getting code to work. Version 3.00.05 (25 changes) made the changes to invasion hexes which is described in the paragraphs below about the Map, and fixed several problems with placing units in the air reserve pool during setup. This version fixed bugs in the Support Minors phase and in the newish code for the Surrendering phase. Here I was taking advantage of my redesigned task list to fix all the bugs for selected phases of the game. Other improvements were the additions of new help messages in Help Content.txt for the 20 multiple use Unit Dialog forms (e.g., disposition of Vichy units). I guess the most momentous change with this version was the elimination of the Collapsing Vichy France ‘phase’ that was part of CWIF. Collapsing Vichy France is now a digression that occurs during the Axis rail or land movement phase. The advantage of having this as a digression is that the series of events that happen when Vichy collapses can be performed cleanly, and then the game returned to the place in the sequence of play where the collapse was initiated. Version 3.00.06 (19 changes) was a real hodgepodge of corrections. Rather than tackle a group of related bugs, or one ‘difficult’ bug, I simply investigated all the new bugs reported by the beta testers for the previous two releases. The result was I jumped around in the program hither and yon slathering on patching compound (no programmer should be without it). Test Script/Plan Nils has defined 7 sets of optional rules that can be used to encompass all the possible combinations thereof. What this means is that by creating saved games for each of the 7 sets, all the optional rule combinations can be tested. That is a lot easier than having 2 saved games (one with an optional rule ON and another for it OFF) for each of the 81 optional rules. Game Engine Redesign One major annoyance this month was the discovery that the sequence of play for the subphases of Land Combat Resolution was incorrect. I had published section 7 of the Players Manual early this year describing these subphases in gruesome detail, but no one had noticed the two serious errors. What now needs to be done is: (1) modify section 7 text - to me, this is the design specification for the sequence of play, (2) add two new subphases for Converting Shattereds to Retreats and Disorganizing Attacking Units following the Advance After Combat subphase, (3) modify the Land Combat Resolution form to reflect the changes, (4) take new screen shots of that form for the Players Manual, and (5) modify the accompanying text in the Players Manual, (6) modify the text in Help Content.txt, and (7) redo the chapter of the Training Videos on land movement and combat. As someone who has programmed for over 40 years, having the design specifications change after I have written the code and it is thoroughly debugged and documented, instantly infuriates me. I think I’ll go buy more chocolate. Nothing new on rewriting the supply routines. It’s now 4th in my task queue behind naval combat bugs, the land combat resolution modifications, and coding the redesigned system for routing resources to factories. Units, Map, and Scenarios Orm reviewed all the straits hexes on the map for legibility and Patrice changed the data so icons in the hex do not occlude the straits arrows. Alain reviewed the COA data file and located some spurious coastal hexes in the middle of the ocean. Those had no effect on game play and were a consequence of changes to the Scandinavian portion of the map several years ago (but I feel strongly that neatness counts in all software and data). Patrice searched for obscure coastal hexes which border on two or more sea areas but can only be invaded from one of the sea areas. Because the CWIF map data files did not identify these hexes, the program was permitting invasions from all adjacent sea areas if an invasion were possible from any one of them. I added a new field to a data file and Patrice made the necessary changes. Now the program ‘knows’ that the 2 hexes forming the border between Denmark and Germany are adjacent to both the North Sea and the Baltic sea but can only be invaded from one of them (it’s different for each hex). The above changes were all a consequence of Michael coming up with a clear way to present the information on which coastal hexes can be invaded from which sea areas. Previously the program displayed adjacent sea areas in a panel of the Main form as the cursor passed over coastal hexes. Now that panel also contains “(no invasion)” following the sea area name if invasion from the sea area into the hex under the cursor is not possible. I am extremely happy with this solution. Unless I am mistaken, new players will no longer have to struggle to figure out the rules for which hexes can be invaded. Not only does moving the cursor make that crystal clear, but after doing so over a bunch of hexes and seeing which ones can be invaded from which sea areas, a new player can figure out the rule himself - without reading any text at all! Robert Jenkins continues to generate new naval unit writeups and send me periodic updates of the master file. Alain sends me his current master copy of the land unit writeups when he gets new ones from David Hughes. As always, Patrice found a few more names to add to the map. Optional Rules I added a new optional rule that makes the Nazi-Soviet pact easier to break in 1941. It is a small change that was easy to code. Simply, the ratio of garrison strength needed to break the pact drops from 4:1 to 3:1 for the second half of 1941. ‘Stuffing’ the border with the confidence that Germany will be unable to break the pact is therefore more difficult for the USSR, and the attempt to do so runs the risk of having the Russian units overwhelmed in the first turn or two of Barbarossa. However, Germany isn’t given free rein to attack whenever it likes, and should the German player neglect his garrison on the border, he can still find himself unable to DOW the USSR until 1942. Saved Games Nothing major this month. Changes were required to add the new digression for collapsing Vichy France, but that was transparent to the beta testers. All previously saved games can still be restored. III. Player Interface I fixed a bunch of player interface bugs this month. The new ordering of my task list has them towards the top so they drew more of my attention than they typically do. When selecting what to work on, one question I ask is: “Is it easy to do?” Another is: “How long has this defect been festering?” Several of the interface bugs met one or both of those criteria. Oh, and the third question is: “How fatal is this bug?” I refer you to Billy Crystal’s monologue in The Princess Bride on different degrees of dead. IV. NetPlay Nothing new. V. PBEM Nothing new. VI. AI Opponent Peter started work on creating Common Functions for use in the AIO scripts. Most programmers will understand this terminology, and for those of you who don’t, these are fragments of code that are used in multiple LAIO scripts. By pulling them out and placing them in a separate file, they only have to be written (and debugged) once. Then they can be used by any script that needs the same logic. A couple of examples are: (1) determining whether there are any seaborne invasion threats when setting up minor country units, and (2) the same for paradrop threats. These functions are used when setting up the units for almost every minor country - that is, they are used in dozens of places. I scrimped some free time to work on the LAIO parser this month. At this point I have it close enough to being done that I hope to complete it in the first week of December. VII. Documentation Mike asked me to send him my current (unfinished) text on Sections 6 and 8 of the Players Manual, so I guess that is what he is working on now (153 pages in section 8 to date). The former has a lot of holes (PBEM and NetPlay forms). For the latter, (Player Interface), I have caught up to all the code that is finished. That is, if the code is written and working, then its documentation in the Players Manual is also finished. The main open items are for Production Planning (redesign of the system for routing resources to factories), and Breakdown/Reform units (requires implementing the optional rule for Unlimited Breakdown). As I get the code to work, I’ll supplement the documentation in the Players Manual. My goal here is to have zero concerns about documentation when the program nears completion. VIII. Learning Aids (tutorials, training video, embedded help text) Nothing new on the last 3 chapters of the training video: naval movement, naval combat, and production. I was about ready to author the chapter on naval movement, but that will have to wait until after I redo the chapter on Land Movement and Combat. As mentioned above, I added text in the context sensitive Help file for 20 more forms. Context sensitive help is nearly finished, with the exception of the PBEM and NetPlay forms which haven’t been completed. As before, the sequence is: write the code, create the form, take the screenshot, write the documentation in the Players Manual, and then copy that text into the Help Content.txt file. The last step is what appears on the screen when the player clicks on the ubiquitous Help button on the forms - a separate message for each of the 157 forms. IX. Glitz (historical video, sound effects, music, historical unit write-ups) No change from last month. The currently active authors for the unit writeups are Robert, Alain, and David. I am waiting on the sound effects from Jim and the music from Dave. X. Marketing No change from last month. Andy Johnson has retained the ownership of the MWIF fan site he started to set up before his new job prohibited him from working on it. If anyone is interested, send me an email or Personal Message (PM) - Andy is willing to transfer ownership to someone else. Remaining Tasks I Tasks requiring a small number of hours 1. Historical video Integrate these into the program (randomizing when they are shown). 2. Sound effects Awaiting Jim’s complete set of sound effects, after which I will integrate them into the program. 3. Music Awaiting Dave’s complete set of music, after which I will integrate them into the program. 4. Unit writeups I simply replace old master files with new ones when Rob and Alain send me updates. 5. Players Manual 8 of 12 sections are done. 6. Context sensitive help I clone the text from the Players Manual once that text has been written. 7. Auxiliary files These are starter sets for new players so they can jump right into playing the game without having to make a lot of preparatory decisions. Michael just volunteered to work on creating these. 8. Tutorials and training video The Training Video is 70% done. 9. Player Interface With the exception of the Standing Order forms for PBEM, I have finished the forms. 10. Optional Rules For the optional rules, I need to fix bugs and bring them up-to-date with rules changes since 2003. II Tasks requiring a medium number of hours 11. PBEM The technical task of sending and receiving emails from within the program hasn’t been coded. Work on the standalone program (running on a third party computer) to generate random numbers hasn’t begun. The large task here concerns the Standing Orders: defining and instantiating internal variables, then displaying them in the forms so players can review and revise them. 12. Sequence of Play There are still many bugs related to the sequence of play. III Tasks requiring a large number of hours 13. NetPlay There isn’t a lot to do directly related to NetPlay, but the underlying performance of the program in generating Game Record Log Entries has to be perfect. That’s because the GRLs are sent to each computer in a networked game to keep them up-to-date with the decisions of all players. I need to instantiate, with actual data, the form used to monitor internet communications while a game is in progress. 14. AI Opponent I need to finish writing the parser. Which will then leave the task of calibrating the rules’ performance so the AIO plays well.
_____________________________
Steve Perfection is an elusive goal.
|