|
Shannon V. OKeets -> RE: When? (1/2/2010 8:49:36 PM)
|
January 1, 2010 Status Report for Matrix Games’ MWIF Forum
Here is 2009 in review. See hardware and software below for progress in December 2009.
Accomplishments of 2009
Project Management
About mid-year I had a long conversation with David Heath and Erik Rutins. All of us want MWIF to be bug-free (to the best of our knowledge) before release. Presently there are too many bugs and I really don’t know how long it will take me to fix them all. Starting in August, I focused on fixing bugs roughly 90% of my time.
I revised my master task list so the bugs are 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. Roughly, in the past 4 and ½ years I have cleared ~2000 bugs from my task list.
I monitored all the threads in the MWIF World in Flames forum daily, generated weekly (later in the year monthly) status reports for David Heath and Erik Rutkins at Matrix, and posted monthly status reports to this forum on or around the first of every month. I try to answer every question posted in the forums, sent to me as a forum PM (personal message), or sent via email. I endeavor to assimilate and integrate different forum members’ viewpoints and opinions into MWIF.
Hardware and Software
I installed a telecommunications monitor program/tool (WireShark) on each of my computers to debug internet communications. I installed Camtasia, of which I then made immediate use, to produce Training Videos. As part of that activity, I purchased a microphone headset: Logitech, USB 2.0. Late in the year I bought a new printer, HP Color LaserJet CP2025, which has the ability to do two-sided printing - very useful for printing out source listings and desk checking code.
In December I bought a new computer. The previous one had served me well over the past 3 and a half years, but the salt air in Hawaii plays havoc with metallic elements. See below for details on the new system.
Installing the new hardware and transferring files from the old system to the new took about a week. What really devoured my time was installing the software and getting it to perform with the same efficiency as on my old system. Some of that was time spent training an old dog (me) new tricks. But then abysmal documentation and non-intuitive system designs can go a long way towards driving anyone mad (in both senses of the word). One of my personal sayings: “Time sure flies when you don’t know what you are doing”. I am still struggling with getting the Delphi 2010 Integrated Development Environment (IDE) to perform as well as the Delphi 2007 IDE did.
Altogether I spent over 3 weeks on purchasing and installing the new system (still a work in progress). Hence, very little was done to fix MWIF bugs. However, the payoff is that MWIF now runs under Win XP, Vista, and Win 7 - which is a very good thing for the long run.
The new keyboard and mouse make me feel like a grown-up. Why I didn’t discover the improvement in the quality of life available from using a professional keyboard and mouse earlier is a now great mystery to me. The double 24" monitors are a tremendous boon too. I actually have so much screen real estate that there are portions of the screen(s) unused most of the time. Most importantly, when running MWIF from the Delphi IDE/debugger, I can view MWIF, the IDE (i.e., source code listings), and still have room to see my task list (or the MWIF development forum, or bug reports, or my directory listings). I no longer waste a lot of time switching between which application is visible while I am working.
Processor
• Intel Core i7 @2.66 GHz CPU, 64 bit, Intel turbo mode,
• 4 CPU cores and 8 CPU threads,
• 8MB L3 cache
• Liquid cooled with 120MM Radiator which is entirely sealed
Memory
• DDR3-1333 (PC3 10666); double the bandwidth of DDR3; 64 bit
• 12 GB (2GB x 6) triple channel, upgradable to 24GB
Motherboard: Intel x58 chipset with South Bridge iCH10R and Socket 1366
Monitors: two ViewSonic VX2433wm (maximum resolution 1900 x 1080)
Graphics
• Nvidia GTS 250 with 1 GB GDDR3 memory
• Nvidia CUDA and Nvidia Physx
• 2 DVI-I connectors (these support both digital and analog connections)
Hard Drive: 1TB @7200 RPM with SATA II interface
Optical Drive:
• 22x DVDRW with double layer support
• 2nd Optical Drive: LG Electronics GH22NP20 22X IDE SecurDisc DVD+/- RW Internal Drive
Backup disk: 1.5 TB external hard drive Seagate FreeAgent Desk
Network: 10/100/1000 Mbps Ethernet port
Audio: Realtek high definition 8 channels
Keyboard and Mouse: Logitech Cordless Desktop Wave Pro
Expandability
• 4 x 5.25" drive bays, external (3 available)
• 1 x 3.5" drive bay, external (0 available)
• 7 x 3.5" drive bays, internal for hard drive (3 available)
• 3 x PCIe x 16 (2 available), Crossfire ready, SLI ready
• 2 x PCIe x 1 (1 available)
• 2 x PCI
Ports
• 8x USB 2.0 (2x on Front, 6x on rear)
• 2 x Front Audio Jacks
• 6x Rear Audio Jacks
• 1 x Optical S/PDIF Audio
• 2 x PS/2 (keyboard and mouse)
• 1 x eSATA 3Gb/s Port
• 1 x IEEE 1394a (FireWire)
• 1 x RJ-45 (Ethernet)
Other
• 700-watt power supply
• Dimensions: 17.75" H x 20.5" D x 8" W
Software (all of these are Win7 compatible)
• Microsoft Windows 7 Home Premium (64-bit)
• CodeGear RAD Studio: Delphi 2010
• Theme Engine 9.20
• JEDI Code Library, JCL 2.1.1
• JEDI Visual Component Library, JVCL 3.39
• GExperts for Delphi 1.33
• MadCollection 2.5.11.1 (version 3.0k)
Beta Testing
I released 51 new versions of the program to the beta testers during 2009. That is almost exactly a new version every week, which was my objective at the beginning of the year. The version numbers ran from 00.12.00 through 04.00.02.
Version 1.00.00 was the first to have the entire sequence of play converted into ‘pure’ phases with digressions handling places were the sequence of play ‘freezes’ while other events (e.g., forced rebasing of naval units, air units aborting from air-to-air combat, relocating units when Vichy France is declared) are processed. Version 2.00.00 was the first to contain the capability of testing NetPlay communication. Version 3.00.00 reflected a numbering change because of substantial modifications to the Naval Review Details, Naval Review Summary (NRS), and the data stored in the Screen Layout files (SLY files). Version 4.00.00 was the first created using Delphi 2010, which meant it was capable of running under Win XP, Vista, and Win 7 (native mode).
I have kept the official number of beta testers at ~30 during 2009. However, beta testers come and go depending on a host of things. Some disappear for months at a time and then reappear. Presently things are running smoothly, with the beta testers providing enough details for me to find and fix bugs quickly.
Robert Nebel and Jimm revised their set of Test Scripts to make sure MWIF performs in accordance with the Rules as Written for WIF FE. However, the beta testers have not found the scripts useful enough to make them part of their testing process. Perhaps someday that will happen. On the other hand, as long as the beta testers are finding bugs, I can’t complain.
Saved Games
All the code for saving and restoring games functions correctly (though there are a few reported bugs I haven’t investigated yet) and the ability to restore older games extends back to version 00.11.00.
Map and Units
Patrice continued his work to improve the accuracy, information, and aesthetics of the map. As always, many forum members contributed to this effort. Here are the important map changes during the course of 2009:
• The map data now includes the year each country entered the war (only needed for about 80 countries, not all 252). This enables the program to determine how long a country, that can received partisans, has been in a war at the start of each scenario.
• Most of the sea area section boxes were repositioned so all section boxes are on even numbered rows. This enables a very small detailed map to display all 10 section boxes for any chosen sea area.
• Long port names were abbreviated so they would fit on the Naval Review Summary form. The NRS form displays the names of ports as column headers but there isn’t a whole lot of room. I added another field to the NAM data file so alternative shortened names could be added for the ports. According to Alain’s count MWIF has 127 major ports and 427 minor ports = 554 named ports!
• 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.
• 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).
Patrice was also instrumental in maintaining the unit data:
• The naval unit data needed a new data field added to accommodate a weirdness in 4 of the 1300 naval units.
• There were some units from the 2007 counter sheets that had a couple modified numbers that we had missed.
• Alain (Caquineur) went through the data files, field by field, looking for inconsistencies (primarily internal cross references). He found a few odd bits here and there and Patrice made the corrections to the map and unit data files. For the most part this was buffing and polishing.
Geoff revised the naval unit bitmaps so they are centered better in the counter depiction. This isn’t as easy as it might seem since some units require two lines to display their names, leaving less room for the bitmap image of the ship. Even more time consuming is to make sure the unit depictions are correct for all 8 levels of zoom.
Patrice replaced the medium resolution silhouette bitmaps for the air units. These are also used when a carrier sends its air units into combat. The program generates an anonymous ‘temporary’ carrier air unit that is displayed using a silhouette. Previously we had 11 air unit silhouettes which were generic for each ‘type’ of air craft. They were pure black and white images and the program replaced the background color with the color for the controlling major power (or minor country). The disadvantage was that these could not be rendered using anti-aliasing, so the edges looked jagged. Patrice created new silhouettes for each major power, and for each minor country that has air units. There are ~70 of these bitmaps now. Furthermore he made the silhouettes country specific, instead of using the same fighter silhouette for all major powers.
Andy Johnson (#1 - unit writeups) coordinated the naval unit writeups for the first half of the year and Rob Jenkins took over when Andy had to return to working on his ranch full-time. During the entire year, Rob worked tirelessly generating an enormous number of naval unit writeups every week. Alain (Caquineur) worked on coordinating and editing the Land Unit writeups for several months, until his”real life” took him away from working on MWIF. There were many authors of both land and naval unit writeups, including new contributions from David Hughes and Adam.
Scenarios and Optional Rules
The data for all 11 scenarios is complete. I did work during the year on coding the victory conditions, which are different for the 4 scenarios that do not use the entire world map. There is still one rule left to code for the victory conditions in the Day of Infamy scenario.
However, I did not make any progress on: (1) adding a special post-setup subphase for placing partisan units on the map behind enemy lines (needed in 3 scenarios), (2) moving units in and out of the Transfer Pool for the 2 half-map scenarios, and (3) the special production rules for those same 2 scenarios.
Towards implementing new optional rules:
• I did more work on Convoys in Flames: ASW escorts, ASW carriers, and the special subs (e.g., snorkel).
• I completed the code for Blitz Bonus.
• I checked the code for SCS Transport and Amphibious Units (there were some changes to the rules since CWIF was coded). While doing this I broke the interdependence between the Amphibious and SCS Transport optional rules. You can now use neither, either, or both of these optional rules.
• There was a discussion in the forum on the optional rule for Compulsory Peace between the USSR and Japan. The resultant consensus will form the basis of MWIF’s implementation when I get a chance to write the actual code.
• 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.
• I moved about a dozen optional rules into a list of tasks that are not likely to get done until post release. It is not that I do not like these optional rules or have anything against them, other than they require me to spend time on them to make them functional.
• I added a governor to the creation of partisan units. My concern was that for new players, the number of partisans might get out of hand (e.g., no garrison means partisans arrive and there is a feedback loop so they breed like crazy). The governor works against an upper limit and when that many partisans are in a country, the probability of new arrivals gets cut in half. WIF FE effected a maximum of total partisans on the map of 15, since that’s how many counters there were. In MWIF there can be many more.
Michael Andersen provided revisions to the default scrap lists he had created last winter. This is part of my objective to enable new players to start a game quickly. Michael also created saved games for each of the scenarios, which lets players skip the “Start a New Game” process should they so desire. Other pieces of the “fast start” planning are the map views and screen layout files described next.
The beta testers created a complete library of map views that cover all 11 scenarios, and all the major powers in each scenario. There are ~400 map views total. These will appear to the purchasers of the game as part of the file “New Game.SLY”. That’s a screen layout (SLY) to be used when starting a new game
I still want to create variations on “New Game.SLY” for different monitor sizes and configurations. I have a list of default configurations so this shouldn’t be a lot of work to finish. Ideally, a player will have a New Game.SLY file for each scenario, which is tailored to his monitor(s) and lets him switch map views for each major power in that scenario.
MWIF Game Engine and CWIF Conversion
Paul and Nils sent me their final report for transforming the finite chit pool for US Entry into an infinite distribution. Without getting into the technical details, they used both a theoretical statistical analysis and a Monte Carlo simulation to affirm that their proposed changes will better model the way the finite chit pool works in WIF FE. I implemented their recommendations into the program code. We will include their formal report (an MSWord file) as part of the MWIF product, since it describes that part of the simulation in more detail that I want to put into the Players Manual. They have both given Matrix Games permission to do that.
I replaced the last remaining uses in CWIF of Windows style components with better components from the JV library.
I revamped the naval combat subphases and converted CWIF ‘phases’ to digressions for: naval interceptions, naval interception combats, and aborts from naval combats. Collapsing Vichy France is also 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 Vichy’s collapse was initiated. Overstacking is the last remaining CWIF ‘phase’ that needs to be converted into a digression.
I generated dozens of additional Game Record Log entries to support NetPlay/Indy10.
I rewrote most of the code for determining supply but I couldn’t find enough time to finish it this year. I need to tie together several pieces of that code and start displaying the results on the screen (using the new Supply Sources form) so I can check that it works correctly. The CWIF code for supply mostly works but does have some annoying (non-fatal) bugs that interfere with beta testing.
I fixed all the remaining problems with Declaring War, including the ability for a series of major powers to decide whether they want to align an attacked minor country up to the point that one of them says Yes or they all say No. In the area of game play, I fixed bugs with USSR Claims on Eastern Poland and the Baltic States and other US Entry chit draws that occur due to moving land units.
One major annoyance towards the end of the year was the discovery that the sequence of play for the subphases of Land Combat Resolution is incorrect. Currently there are 10 subphases in the Land Combat Resolution phase. After revising these there will be 12.
When converting from Delphi 2007 to Delphi 2010 I needed to either eliminate or replace many old routines from CWIF that originally were written to Win 98 (ye, gads!). There were a bunch of other changes related to transitioning from ASCII encoding for characters to Unicode. The later supports all the world’s cuneiforms, which ASCII did not. Now, about that translation of MWIF into Chinese, should we go with Mandarin or Cantonese?
Player Interface
I created 33 new forms in 2009:
• 3 more combat results table forms (naval, anti-aircraft, and ASW) and improved the land combat CRT so it matches all the others.
• A new form for selecting units from the Naval Combat Abort queue. Previously each unit was aborted immediately, so CWIF had no need for this form.
• A new form for tracking communications during NetPlay. Primarily this is for debugging the internet communications. However, what I did was to create a file of translations for the 531 game record logs from numbers to text messages. For example, #38 is “PPlc: Assign a pilot to an air unit”. The advantage of this is that instead of reading through thousands of game record log entries and trying to decode each number, the form presents text messages that make sense in terms of the sequence of play. As a side benefit, this translation capability will be of interest to the diehards who want to analyze what happened during a game by reading the game record log.
• 4 new access points to game internals from the main menu bar, each of which displays a new form. Only a couple of these will be part of the final release: testing NetPlay and PBEM communications. The other two are for: (1) reading in, parsing, and evaluating AIO scripts and (2) monitoring the game record log.
• A new form that presents who holds which victory cities throughout the game. This serves as a nice summary page for when the game ends and can be used during game play to see the status of all 67 objective hexes. The Victory form is a source of information on where the objective hexes are and who controls what. For new players this will be essential since not everyone knows where Diego Suarez and Taihoku are. It seemed silly for a game of this complexity to not have a decent presentation of the victory conditions.
• The New Owner form, which is a simple form, used rarely, that lets a player decide the new owner (major power) for units that are conquered. Sometimes the original owner chooses and sometimes the conqueror chooses.
• A new form for restoring games from within an existing game. This has the same features and the Opening Screen form. One benefit is seeing information about the saved game prior to restoring it.
• A new form for reporting on supply sources and paths. CWIF gave this short shrift and at times would end up with a list of over 100 hexes to define a path, because its algorithm did not search for the shortest/most direct path when determining supply. My revised form shows all the supply sources (primary, secondary, tertiary) for a major power/minor country and annotates each hex/sea area in the supply path as to its type (basic link, rail link, oversea link).
• 21 new forms for PBEM, described in more detail in the section on PBEM below.
And I substantially modified 17 existing forms:
• Revised the Land Combat Resolution form so it presents all the details of the different shifts and die modifications.
• Made substantial changes to the Land Combat Charts form so it can be used prior to, during, and after resolving land combat. This lets the player decide on the order for resolving land combats and to make decisions about the use of snow units and choice of Assault versus Blitz.
• Changed the air-to-air combat form for how the subphases are displayed so they match improvements in Land Combat Resolution. Improved the air-to-air combat process so it is smoother and less confusing to both new and experienced players, and added an MWIF form to display the air-to-air combat results table.
• Drastically modified the Plane Role form - for deciding whether to send fighter-bombers and carrier air units as fighters or bombers on air missions and in naval air combat. To support NetPlay, where multiple players are making these decisions simultaneously, I had to give the players a broader perspective on what was happening. For example, if the CW and USA both have carrier air units in a naval air combat, each of those players needs to see what decisions the other is making for fighter and bomber assignments. At the same time, if the German and Italian players are also making decisions for that naval air combat, neither side should see what the other side is deciding. After my changes, information on decisions is communicated between players on the same side but not between those on opposing sides.
• Modified the form for landing carrier air units on carriers. Here the changes to the form were mostly minor, but the mods to the logic for accessing the form were substantial. There are 8 places in the sequence of play where carrier air units return to carriers. Sometimes it is an individual unit aborting from a combat, and other times it is a group of carrier air units returning to their carriers simultaneously. In the latter case, it is important to provide the player with the information on all the units - both carrier air units and carriers. That way the player can avoid inadvertently landing his planes such that one of them has nowhere to land.
• Activated the Selectable Units form for a couple of the subphases of naval combat to make it easier to identify which units are capable of moving in those subphases.
• Reworked the Use Oil form based on a discussion with the beta testers. These decisions are both easier to implement and much more of the pertinent information is shown.
• Enhanced several forms used in the Vichy Declaration subphases. CWIF provided very little information to the player about what was happening during those subphases. With the addition of several sentences to each form, it is now clear what decisions (if any) the player needs to make in each Vichy subphase. This stuff only occurs once per game (if that) and even experienced players are typically a little foggy about what exactly happens during Vichy formation.
• Redesigned the Initiative form so it provides much more information when making decisions about rerolls and choosing which side is the phasing side for the first impulse of a turn.
• Completed the Replacements form revisions.
• Revised the Start New Game form to improve selecting which players control which major power groups. I had previously tried to use a ‘sexy’ new component capability, but it was unreliable and caused a lot of screen flickering.
• Spiffed up the Spend Surprise Points form. It now has buttons for viewing the various naval combat tables.
• Modified the opening screen so restoring saved games from the AutoSave directories is easy to do. For each scenario, MWIF maintains saved games in: Saved Games, Saved Games\AutoSave, Saved Games\AutoSave\Axis, and Saved Games\AutoSave\Allied. All these directories can now be instantly examined from the opening screen, without having to negotiate the disk file structure.
• Modified the global map so it can be viewed at double size global map. This makes using the global map feasible for a lot of decision making where previously the tininess of the hexes made clicking on individual hexes virtually impossible.
• Modified the production and resources form. It now incorporates the double size global map for displaying the resources and factories controlled by each major power or side. Besides being informative, this will be a key design element in the new system for routing resources (yet to be coded).
I spent a few days running the various combat phases looking for ways to improve how they functioned. Some needed major improvements.
The map data changes for invadable coastal hexes were 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!
I modified how data is stored in the Screen Layout files (SLY files). I had let the SLY file format remain static for almost 3 years and decided it was time to implement all the changes I had accumulated during that period.
Once the double sized global map was working, I integrated it (i.e., added some buttons and functionality) with the Naval Review Details, the Naval Review Summary, and Units In Hex forms. I am pretty happy with the ability of these tools for reviewing naval operations and entering orders for naval units. This was one of my major concerns from the very beginning of this project, since a player examining 25 square feet of paper maps to review all the navies worldwide would seem to have a marked advantage over anyone using a system with only 1 to 3 square feet of map visible on his monitor(s). The more screen real estate a system has, the better this design works, but even with a minimal sized monitor, a player should be able to assess a position and make informed decisions for his navy.
Internet - NetPlay
I wrote the technical NetPlay code for use in MWIF games over the Internet. Besides running as a stand alone test program, I incorporated the logic into MWIF as a way of checking on communication status during game play. TestNetPlayCom will be included in the final release of MWIF as a stand alone program, so players can test setting up communications over internet with their friends without having to fire up the main MWIF program. That should help get IP addresses and security problems ironed out quickly.
The beta testers have tested both MWIF and NetPlayTestCom for communicating between computers. No major problems were reported but I need to translate some ‘problems’ into innocuous messages. For example, a MadExcept error message appears when the player tries to connect to another computer when he is already connected.
I went through all 530+ game record logs and standardized the first four fields: Game Record Log ID #, Entry #, Transaction #, and Entry by ID #. That took me days to accomplish, since I needed to make edits in 4 separate files, resulting in a couple of thousand edits. The payoff is that I can now have the tracking report start with those four fields. By translating the ID #, I can display a plain text description of what has happened in the game (e.g., Air unit aborts during an air-to-air combat). The rest of the game record log provides details, such as: which unit aborted and to which hex it returned-to-base.
For instance, I can open and examine the Game Record Log using NotePad (or many other text editors), but since there are over 14,000 entries created just starting a new game, and those entries are heavily encoded, this improvement lets me be more efficient. In particular, when multiple computers are in use, and several people are making decisions simultaneously, the Master MWIF computer needs to synchronize all those decisions and keep the simulations on all the players’ computers up-to-date. The game record log monitor lets me read the GRL on each computer and see if there are any differences between the different copies.
PBEM
I started creating the forms for Standing Orders and I thoroughly revised the original design I wrote back in 2005 for how PBEM will work. I had already written the code for one of the tricky bits: switching control of who decides between sides/computers. This text describing PBEM is now included in Section 6 of the Players Manual: Modes of Play.
Because the normal WIF sequence of play is so complex, explaining the subtle changes for the MWIF PBEM isn’t easy. I also expect many players to use PBEM extensively, so I wanted the documentation on when emails are sent and what is included in each email to be crystal clear.
After my revisions, there are 22 Standing Orders (SOs) in the PBEM system. A SO is where the player says what he wants to have happen during the other player’s ‘turn’. This way the program can keep the game moving forward by reading the SOs and making decisions on behalf of the ‘absent’ player. This design eliminates thousands of emails and a single game can be finished before both players die of old age.
The forms for the first 3 PBEM Standing Orders are fully operational. The fourth SO has data structures and default values, though I haven’t put in the code so the player can modify those values. I’ve also done work more of the SOs, but much remains to be done on entering, reviewing, and modifying the other 18 SOs.
Artificial Intelligence (AI)
I decided that one way to reduced my task list for creating the AIO is to limit the number of different scenarios that it can play when the game is first released. I’ll do 4 of the 11 scenarios for first release and then add the other 7 as patches in subsequent months. What this removes from my task list is figuring out alternative setups for thousands of units in the 7 scenarios that start late in the war. Each of those scenarios has hundreds, if not thousands, of units on the map at the start of the game. If the AIO always uses the same setup, it becomes too predictable and easy to defeat. But to do a respectable job of designing alternative setups for thousands of units will take time and effort.
The 4 scenarios that will be ready for first release are the ones that will be played the most: the two introductory scenarios (Barbarossa and Guadalcanal) and the Global War scenario (which is virtually the only scenario ever played in over the board games). The fourth scenario is Fascist Tide, which is the European half of the Global War scenario, so it can use the same setups.
I went back over what I had written on the French strategic plan. In 2008 I split the French strategic plan into its component parts for conversion into LAIO scripts. In so doing, I left the rather monolithic first 3 parts untouched. During 2009 I broke out the first two and I rendered them into data files. As a prerequisite, I created the storage structures for those pieces of the strategic plan: vital hexes and regions of conflicts (land, sea, and air).
Peter Skoglund worked throughout the year on setup scripts, first for the minor countries (e.g., Spain and Turkey) and after those were done, for the major powers (e.g., France). For instance, Peter finished up the convoy setups for all the major powers for the Global War scenario. We’re using a sophisticated system to analyze threats from air, sea, and land and since they are employed in so many of the scripts, Peter has developed a library of common functions - written in LAIO (Language for Artificial Intelligence Opponent).
Peter’s library of LAIO common functions is substantial at this point though I expect it to continue to grow. Most programmers will understand this terminology, and for those of you who don’t, a function is a fragment of code that is used by 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 country - that is, they are used in over 50 places.
Note that the AIO uses an abstract system rather than a hard coded “this unit goes in this hex”. There is a dual purpose behind using the abstract form: (1) it is easier than trying to hard code all the different combinations and permutations of defenses against the myriad of threats minor countries face when they enter the war, and (2) it is the system that the AIO will use for setting up the major powers. My hope is that eventually the design will be robust enough that the AIO will be able to set up the 7 scenarios that start late in the war without me (or anyone else) having to take the time to figure out which units set up in which hexes.
I wrote the code for the first five steps for the parser and added a new form expressly for testing LAIO scripts. These can be called from the within MWIF and used to monitor how a script is parsed and executed. I devoted many days to creating the data structures for the LAIO parser. As Peter and I worked through various setup scripts, we identified new variable types that we hadn’t thought of previously. Each variable type requires it own data structure. This is not surprising to me and I expect the number of data structures to continue to grow as we write more scripts. I thought about trying to create an exhaustive list, but if I did, more than half of them would never be needed. Therefore, I just add data structures as I come across new variable types.
I created a full directory structure within MWIF just for the AIO files/scripts.
Ian Wilson (PhD in AI) strongly recommended creating an abstract layer to the MWIF geography, so planning and decision making do not have to be done at the hex level. I had expected to do something along those lines but after Ian’s suggestion, and having worked with Peter on setting up units in Spain and France, my ideas kind of jelled. The result is a 4 level breakdown of the world map: (1) global, (2) theater of operations, (3) area of operations, and (4) sea area groups/land regions. These are hierarchical (1 down to 4), mutually exclusive, and exhaustive for all 70,200 hexes.
Patrice started work on the first cut at this and I spent a day or so digging down into the details too. Each geographical component has one or more decision makers assigned by the AI Opponent. Now many of these ‘areas’ will be irrelevant to most, if not all, of the major powers. For example, which major power in MWIF cares about the Southern Ocean or Hudson Bay? And Italy’s interest in the Pacific is comparable to China’s interest in the Atlantic - none whatsoever.
The benefit for the AIO design is that when a decision needs to be made, (e.g., which naval units to include in a moving stack), the AIO has a well defined frame of reference for making that decision. On land, this enables the creation of fall-back positions in Russia and China that include a group of hexes. Another gain is that sea area pipelines will be composed of a series SAGs (Sea Area Groups). Towards this goal, Patrice and I defined a geographical breakdown of Europe, including the adjacent sea areas. This is now ready for use in the AIO scripts.
I realigned the decision making assignments for each decision maker. Mostly this involved splitting a list of tasks into subsets for a hierarchy of decision makers. For example, instead of there being just one naval decision maker (i.e., the Admiralty), there are now 4: Admiralty - global responsibility, Rear Admiral - theater of operations, Fleet Admiral - area of operations, and Naval Group Commander - sea area group.
Continuing the example, the Admiralty decides on convoy pipeline entry and exit points for each theater of operations (TO) and allocates new/unused units to each TO. The Rear Admiral decides on the use of convoys and naval transports within his TO as well as the positioning of naval units to establish a naval presence in individual sea areas. The Fleet Admiral moves convoys with accompanying escorts within his area of operations. He is also responsible for committing units to attack enemy naval assets and deciding to which port(s) naval units return. And at the lowest level, the Naval Group Commander decides all the tactical naval decisions, ranging from shore bombardment through choice of naval combat table.
The key benefit of these changes is that each decision maker has a geographical area of responsibility that aligns perfectly with the geographical breakdown that Patrice, Peter, and I have defined (still incomplete at this point). When making decisions, each decision maker has a smaller search space for choosing the best move.
Player’s Manual
Mike was assigned by Matrix Games as editor for the Players Manual and he is doing excellent work. Rules as Coded is done and in Mike’s hands. The next time I expect to see the RAC is as a finished PDF for inclusion in the product release. As a point of reference, the beta testers had the various version of RAC to work with throughout the year and Patrice reviewed and approved all changes. The last RAC version was #25 dated November 17, 2009.
Patrice sent me hundreds of screen shots, in TIF, 300 DPI, which is the format needed for the Players Manual (as specified by Marc at Matrix Games). I didn’t use them all but I did use roughly half of them. Greyshaft started the work on copying text from Rules as Coded for the Players Manual, which I finished when “real life” took Greyshaft away from MWIF. The result is that many of the descriptions of the forms include excerpts from RAC regarding the relevant rules.
Several experienced WIF players wrote up their ideas on the topic of “Important Decisions”. Once I had integrated all their submissions into section 3.4, Important Decisions, it had 9 subsections and was 40 pages long. Some of the contributors were: Patrice, Christopher, Mike, and Paul. Later I completed the rest of Section 3, How to Play, which meant adding descriptions of the interactive tutorials.
I finished Section 4, Starting a New Game, by putting in the screen shots that had been missing and writing a few sentences to describe them.
I moved all the forms for PBEM and NetPlay out of Section 8 (Player Interface) and into Section 6 (Modes of Play). There are 22 Standing Orders, most of which have their own form. Altogether there are 21 forms exclusively for PBEM. 2 of them are completely done and the others are in various stages of development. Once the code is written for the PBEM forms, doing the documentation on them will take very little time.
I wrote all 153 subsections for Section 7, Sequence of Play. I then took that text and transferred it into “Help Content.txt” for easy access while a game is in progress. When the player clicks on the sequence of play form, the program displays the text describing the current phase/subphase of the game.
As a result of moving so many forms into Section 6, Section 8, Player Interface, is much closer to being finished. It currently is 150+ pages long. The original work on section 8 was done by Greyshaft started the work on copying text from Rules as Coded for the Players Manual, which I finished when “real life” took Greyshaft away from MWIF.
I read through and made small edits to section 9, Optional Rules. Most of those changes were in response to the changes to the optional rules described above.
Patrice collated the “Deviations from RAW” from RAC which I then called Section 10 of the Players Manual, Rules as Coded. This section is a cursory overview of the entire 150+ page RAC document which is a separate PDF. What is listed in section 10 are all the deviations from Rules as Written, ADG’s definitive rules document for WIF. When experienced WIF players want to know what changes have been made to their beloved game, Section 10 should provide the answers.
I put together a strange collection of information for Section 11, Appendices. That section is complete except for a few sentences I am not ready to write at this time. Those concern “other files” that will be included with the released product (there might be some more that I haven’t thought of yet) and a short description of the INI file.
What I included in the Appendices is a complete list of the unit types, terrain types, countries (and other geographical regions), mouse and keyboard commands, a short overview of the sequence of play, and the two alternative land combat tables. There’s other stuff too, like an explanation of where all the bitmaps are used; so it’s a real mishmash. However, players who are interested in this detailed look at some of the program’s internals should be amused for hours, if not days. For example, there is a full definition of the file structures for the map and unit data.
I put all the sections of the Players Manual together for the beta testers as a PDF. It is only a draft and many of the screen shots are missing (because I pulled them out of most sections for Mike, who likes his text without embedded figures). Nonetheless the most recent PDF came in at 304 pages (8.5 by 11 with narrow margins and 11 point font).
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. 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). Once 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 as the program nears completion.
Tutorials, Training Videos, and Context Sensitive Help
All the Picture and Text tutorials are completed. In mid-year I revised the weather tutorial so the relationship between the weather die roll and advancing the impulse number is easier to understand.
I increased the number of Interactive Tutorials to 11 because I felt a tutorial devoted to setting up units was warranted. WIF has the most complex rules concerning setting up units of any of the 100+ war games I have played. None of the interactive tutorials has been started yet. However, they will follow the scripts I used in the training videos, described below. Once I complete the training videos, I’ll duplicate them as Interactive Tutorials. With the former, the player can simply watch the game being played. With the latter, he can push and keys and move the mouse himself.
Erik and Dave (Matrix Games) persuaded me that there should be a Training Video for MWIF. I thought of having just one sequence, playing through an Axis impulse where the 3 different major powers take a Land, Naval, and Combined actions. But while I was writing up how to use the Setup Tray, I decided that there should be a second clip covering that; it can be quite complex compared to other computer war games.
More thinking on this subject resulted in 12 chapters. The hard fact is that MWIF has 152 phases/subphases/digressions, and uses over 150 forms. There is simply no way to describe this game in 1 hour. I spent a bunch of time in July completing 8 of the chapters:
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) - needs to be redone after the combat subphases are corrected.
Chapter 10 Naval Movement (TBD)
Chapter 11 Naval Combat (TBD)
Chapter 12 Production & Politics (TBD)
If you add up the time, you will get 4 hours and 42 minutes, with 3 chapters yet to go. Wow, is that way over what I estimated! I don’t think they can be trimmed very much. As it is, I see dozens of places where I barely skimmed the surface. There are entire phases of the game that never get so much as a mention. Furthermore, of the optional rules, I probably only lightly covered 4 or 5 of the 80 in the game.
My goal for the Training Videos is for new players to learn the game without having to read the rules. If we decide to use these as a Marketing tool, then it will likely be the last 5 chapters. They presuppose that the viewer has seen the previous 7, but not very much. Moving the units and engaging in combat is usually the exciting stuff from the beginner’s point of view. Since the last chapter is on building new units and declaring war, that is likely to be of interest to the neophyte too.
Patrice and I took the completed text from the Players Manual and added it to the context sensitive help file. For each form there is: (1) the pertinent text from RAC for the rules related to the form, (2) a screen shot of the form, and (3) a paragraph or two on how to use the form. As of today there are 157 slots for context sensitive help for forms, and 130+ of them have completed text messages. There is also a different set of help messages for all the 150+ phases et al - all of the help messages are written for these. In total that’s over 300 individual context sensitive help messages.
I added a bunch of new menu items to the Help menu so it includes links to the new Combat Results Tables forms. The full list of reference documents accessible from the Main form’s menu bar is:
• Player’s Manual (PDF)
• Rules as Coded (PDF)
• Rules as Written (PDF)
• Optional Rules
• Keyboard and Mouse Commands
• Terrain Effects Chart
• Units Symbols and Numbers
• Unit Status Indicators
• Unit Costs and Characteristics
• Air-to-air Combat CRT
• Anti-aircraft CRT
• Land CRT
• Naval CRT
• ASW Pre-fire Attack CRT
• Charts from WIF FE (PDF)
• Picture and Text Tutorials
Historical Video, Music, and Sound Effects
Barry was assigned to do the historical video finished all 26 of them. The program now displays them but I haven’t decided exactly when they should be shown. That decision is waiting on the completion of the sound effects and the music. All three elements need to be incorporated into the code simultaneously.
Jim was assigned to do the sound effects and sent me sample sound effects files (in OGG formats). Matrix Games would like to use OGG format because WAV format has a track record of not working on some system configurations. I added code so the program can now play the sound effects (in OGG format). Once I get them all and the music, I’ll decide when they should be played.
Patrice found 700+ radio clips from WW II (MP3 format). I don’t know about copyright issues (and MP3 format) with using these radio clips though.
I sent Dave my assembled notes for desired music files. While for the video and sound effects I was able to be quite specific, for the music I was rather vague. That’s primarily because I am unsure what is available and the possibility of copyright issues. I am waiting on the rest of the sound effects from Jim and all of the music from Dave.
Marketing
In May I ran a simple survey of the World in Flames forum members asking which mode(s) of play they expected to use, as a percentage of the time they spend playing MWIF. This was motivated by a conversation with David Heath about how important the AI Opponent will be. My guess prior to this survey was that the break down would be 50% NetPlay, 30% AIO, 20% PBEM. I was completely wrong. Based on 126 respondents, the estimated percentages are 53% AIO, 22% PBEM, 17% NetPlay, 6% solitaire, and 2% head-to-head. From the comments players made, solitaire, and to a lesser extent AIO, will be used to gain experience with the game so they can play against human opponents using PBEM and NetPlay. But over 60% of the respondents expect to play against the AI Opponent most of the time. I now agree with Dave: the AIO is crucial for sales.
Sean Drummy (Matrix Games posted my 22 new screen shots to the Matrix Games web site under Games in Development. There are now 34 screen shots therein.
Andy Johnson (#2 - fan site) began work on a MWIF fan site. He received permission and encouragement from Matrix Games for this endeavor. To start, he chose the name WorldInFlames.net for the fan site. Sadly, he later had to stop working on the MWIF fan site because his new job has a “do not compete” clause. We are looking for someone else who might be interested in taking on that responsibility. Andy says he will transfer ownership of the MWIF fan site he started to set up before his new job prohibited him from working on it.
Orm’s after action report (AAR) in the forum on Barbarossa and Lars’ on the war in China could be considered marketing. Similarly, Michael wrote an AAR on the Winter War and Peter did one on the opening turns of Global War.
I did some work on printing out the map. Mostly this was motivated by my need to figure out strategic, operational, and tactical decision making for the AIO. Along the way I generated a printed copy that had hexes large enough to hold the counters from WIF FE. To do that I increased the zoom level to maximum (8), took a screen shot, and then increased the magnification of the captured image by 50%. The quality of the output looked great on my not-very-expensive printer, but you would need a lot of paper for the full map. I was taking the screen shots using 300 dpi TIF.
Communications
People with whom I had extensive communication during the year were: Patrice Forno and Peter Skoglund. Dozens of beta testers posted and sent bugs reports and frequently included copies of saved games so I could quickly recreate the problems they encountered. I hate having to identify individuals since that might annoy those not mentioned. Nonetheless I feel compelled to single out Michael, Lars, GSB, ORM, and Nils for there continuing work debugging. Now there are many others as well - and I apologize to any and all that feel underappreciated. Trust me, I am sincerely indebted to all the beta testers.
I had no direct contact with Harry Rowland or Chris Marinacci this year, although Patrice asked Harry Rowland several rules questions, to which Harry quickly provided answers.
Because this is a volunteer group, people come and go as other demands are placed on their time, and their interest in MWIF waxes and wanes. I’ll repeat myself by stating that I can not say enough about how appreciative I am for the wonderful contributions made to MWIF by so many people from such diverse backgrounds.
To all, I say thank you for your help on MWIF this past year.
Tasks for 2010
Finish MWIF product 1 so I can buy a large screen, flat panel, HD TV.
|
|
|
|
