When?

[zoc_trooper]

Thanks for the advice gents. I've already developed a rather ingenious method of coping with scantily clad ladies. I simply imagine that all Yemeni women are garbed from head to toe in black abayas.

As for scorpions... well the abaya trick doesn't work as well.

Cheers,

ZOC

[Shannon V. OKeets]

April 1, 2007 Status Report for Matrix Games’ MWIF Forum

Accomplishments of March

Project Management
I’ve rearranged the task schedule so I worked on the AI Opponent this month instead of in the spring. Overall I lost another week against the schedule I created in October, but that’s within the slack/contingency I had built in so I still plan to finish the programming for MWIF in 2007.

Communications
Patrice and I gave Rob Armstrong a list of touch ups for the coastal and river/lake bitmaps.

I monitored all the threads in the MWIF World in Flames forum daily.

Patrice continued to make data corrections to the detailed world map based on his own research using period maps, and from discussions with forum members.

I have yet to upload version 4.00 for the beta testers so things are quiet from them.

Work on the unit writeups made small progress, and every little bit helps.

Peter Kanjowski promised to finish the Rules Clarifications list for transmission to Harry Rowland. But he has been busy with other things recently.

No communications this past month with: Chris Marinacci, Harry Rowland, or Dan Hatchen (NetPlay).

No activity with the AI Opponent team, though the forum members helped with discussions on strategy and assigning fighters to escort and interception duty.

Beta Testing
I worked on correcting bugs primarily this month. Oftentimes this means that I fix one bug and then go through all the places in the code where similar logic exists and make similar modifications to them. For example, there are about 50 forms/screen that appear when the player needs to decide something right away: Move first? Reroll for initiative? Combat table choice? As part of this list, I include little help forms: Distance calculator, Find city, and also informative screens: Weather chances for next turn, Units review.

As I said, there are about 50 of these all told and several of them had various problems. This past month, I corrected those problems and then standardized how these forms are processed: their preparation, player interaction, and post-processing of the player’s decision. There is now one routine for processing all these forms, and throughout the rest of the program the calls to that routine are virtually identical. Actually, it not quite that clear cut. Calls to 3 or 4 of these forms are still rather messy, because the data fields that ideally should be external to the forms are internal. But I’ll correct those later, when I look at those processes in more detail (e.g., Destroy Units - due to various combat or other game activity results).

The standardization of forms for immediate processing (Modeless for those of you who are technical) is important for future additions. For instance, there are no forms/screens designed for the new optional rules Bounce Combat and Intelligence. The PBEM code also needs new forms/screens for entering each of the 19 Standing Orders.

I also worked on debugging the routines related to movement of units. Presently I want to fix whatever it is that’s wrong with the routine that checks on stacking limits for naval units. In general, the process is that I fix stuff and then check a bunch of other things to see if they work, building up a list of bugs to correct. I build the problem list, then correct items on it. I keep making progress, but it is slow going.

Units
Patrice wants me to revisit the medium resolution bitmaps for air units and he makes a good case for improving them. But that has a very low priority for me in the overall scheme of things.

Map
Not much new here. Rob has a list of small changes to make to finalize the map. He has made a first pass on the Compass Rose we will use to display the credits for the map data and graphics (probably placed way down south in the Indian Ocean). Once Rob gets the final bitmaps to me, I’ll build pages for all the bitmaps. I have the design for pagination done for the units and I’ll make comparable pages for the coastal hexes and the river/lake overlays. I have already written most of the code to create and use these bitmap pages, but there is no sense in putting them into the program until I have the complete and final graphics for the map.

Using pages of bitmaps, instead on individual ones, will produce a definite gain in execution speed when the program loads. I expect it to cut the load time to about 1/4 of what it is now. That is due to a decrease by two orders of magnitude in the number of files the program will have to open, read, and close. Disk access is time consuming when a program has to search for thousands of specific files. For example, by creating pages that each contain 100 individual bitmaps, the number of river/lake bitmaps will go from 7000+ to 70+.

I am considering setting up a simple system for adding text write ups to go with some named locations on the map. As I did for the units, I would be expecting the forum members to provide the text for these descriptions. The code would be very easy to do (2 hours max), and players could add to the text descriptions themselves should they so desire. In theory, each named hex could have its own write up. Right clicking on a named hex, when it is empty, would bring up its text description. I guess pictures could be associated with those, but I am reluctant to make this a big subsystem, and I am chary of placing additional demands on JPG resources. There wasn’t much interest in this expressed by the forum members, so maybe I’ll let this ‘feature’ drop off my task list.

Scenario Information
Coding the scenario data for the remaining 3 scenarios and adding the new unit types to the lists of units for each scenario (e.g., light cruisers and Convoys in Flames units) is scheduled for May.

Player Interface
I achieved a major breakthrough in that the naval units now appear on the map in sea area section boxes. This mimics how they appear when playing the game over the board. For each sea area the paper map contains 5 sea box sections with each section indicating how active the naval unit(s) is (are) patrolling the area. If a unit uses most of its movement points to reach a sea area, then it is in a low numbered section and less active (e.g., more vulnerable to surprise). This is a crucial aspect of the WIF subsystem for modeling the navies of the world for both movement and combat.

My improvement over CWIF is that the naval units now appear on the map in sea area boxes - a separate hex dedicated to each sea box. Going one step further, I have improved the design over the WIF FE paper map by having 10 sea area boxes for each sea area: 5 for the Axis units and 5 for the Allied units. This way the player can tell at a glance if there are friendly and/or enemy units in each sea area and sea box.

To make this depiction of units on the map possible, I rewrote how a unit’s location, when it is at sea, is stored internally. And I also changed all the references to unit locations when they are at sea (there were 500+ references in the code).

I did a lot of documenting and general tidying up on the routines that display forms to the player. Last July, I had gone through all this code and standardized the procedures for presenting lists of units (that occurs in 40 or 50 forms at least). In September I went over all of the forms again, to standardize the components used in the screen displays. These are now primarily taken from JEDI libraries, though I have a half dozen forms remaining to be completely converted from the old style to the new.

This past month’s work on the forms concerned the nitty gritty of selecting and making decisions about individual units: load, unload, break down, reform, destroy, damage, disorganize, use to intercept, and so on. Many of these result in units moving from one location to another: one hex to another, one off-map pool to another, or between the pools and the map. In the process of doing this documentation and standardization, I corrected a few bugs. More importantly, I can now read and understand this code when debugging the routines used for unit movement.

MWIF Game Engine
Not much done here this month.

Internet - NetPlay
Not much done here this month.

CWIF Conversion
The revisions to the code for off-map and sea area locations are finished except for one debugging form (Place Units) that purchasers of the game will never see. I almost finished changing that form last week, so it can be used by the beta testers to set up specific situations for testing whether the program works correctly.

I have yet to run tests on many of the modified unit movement routines to make sure they: (1) don’t crash the program, and (2) at least give the appearance of working correctly.

I started work on revising the routines for determining unit supply. There were 4 different routines with the same name, CheckSupply, which are now named: CheckUnitSupply, CheckStackSupply, CheckCountrySupply, and CheckSupply. The last one determines supply for all units on the map while the others do what their names imply. So far I have documented these CWIF routines (thereby making them MWIF routines to my eye) and corrected a few small omissions of possibilities. However, I need to design and code the major change I want to make, which is to modify the search algorithm from undirected to directed.

Instead of spiraling out from a single unit/stack, looking for a supply source, I want to first determine all the primary and secondary supply sources for each country. That will let the program direct the search for each unit towards the nearest source of supply. Hopefully, this will provide two benefits: (1) find the most direct supply line to the closest supply source, and (2) improve the speed of execution. In particular, the program should be able to quickly determine when there is no supply source within reach - sometimes without having to do any search at all. In CWIF the search for impossible-to-reach-supply could take a while.

Improving the search algorithm is crucial for developing the AI Opponent. When on the offense and on the defense, I need to have the AIO be capable of understanding when a supply line is vulnerable to attack. The only way to do that is to execute the search algorithm multiple times, under different circumstances of hexes being lost to enemy units or enemy ZOCs. E.g., if the enemy moves to this hex, will my unit be out of supply? Actually, this comes up a lot when trying to position HQ units to keep advancing/retreating units in supply at all times. Clearly, the search algorithm has to be as fast as I can make it since the AIO is going to be examining hundreds, if not thousands, of possibilities.

Saved Games
I made a few changes here but I want to do more. I am coming around to the idea that I may prevent the game from being saved when most decision forms are on the screen. For example, if you decide to save the game in the middle of doing production. On the one hand, it would be nice to let the player save the game whenever he wants. On the other hand, it is a ton of work to keep track of the 40 or 50 forms for making separate decisions that might be visible when the player does a save. Writing the code for recording and later restoring all the settings for each of those screens is a lot of work for a rather small gain.

Player’s Manual
Nothing new.

Help System, Tutorials, and AI Assistant
I went back and took new screen shots for a dozen of the pages in the second tutorial, which describes the map. Once I get version 4.00 in the hands of the beta testers, I think I’ll ask them to go through all the tutorials and update the screen shots to reflect changes I have made to the appearance of the map and units over the last 6 months.

Artificial Intelligence (AI)
I did a lot of work on the AI Opponent this month. Originally I had planned on doing this much later in the schedule, but since I will be traveling for one weekend in April and 2 weeks in May, I want to have something I can work on while I am away from my computer. The AIO fits the bill. But first I had to get things organized:

(1) Updated from hand written notes my design document on programming the AI Opponent. Those notes had accumulated over the past 8 months. The file now is 86 pages long and it doesn’t include any of the details on the strategic plans. I set up four new binders for the AIO: design document, code/routines, notes for each major power’s strategic concerns, and strategic plans for each major power.

(2) Created a separate task list for AI programming items.

(3) Transferred the notes for strategic plans from the Matrix MWIF forum posts to text files on my computer. 7 of the 8 major powers have separate threads on strategic planning for the AIO (China is missing) and their content ranges from 1 to 5 forum pages of posts. A page of forum posts becomes 20 pages of text notes in a word processing file. So, these 7 threads resulted in about 600 pages of notes on strategic planning, spread out over 7 text files - 1 per major power. My first editing pass, to remove redundancies and off-topic posts, cut that in half, but I still need to sort through and organize all the remaining 300 pages of advice into a coherent structure so I can encode it into strategic plans for the AI Opponent code to use. Once I get all the notes organized, I will convert them into Strategic Plans, one for each of the 8 major powers. That has been mostly done for the French (only).

(4) Wrote the first thousand lines of code for the AIO. These create the structure into which the AIO decision specific code will be placed. I have 153 separate decisions/tasks for the AIO to perform with 52 of them having what I consider a ‘complete’ text description of how to write the code for implementing them. I also wrote the master calling routine (Decide), which is based on nested case statements. Given a AIO decision maker (e.g., Admiralty, Air Marshal, Field Marshal) and an index number, Decide branches to the correct code fragment which makes the requested decision. I wrote this code this month because I have had it sitting in my head for over a year, and I wanted to have it down on paper so I could reuse those memory cells.

It is still early days for coding the AIO and I have scheduled 3 months in the summer for performing the bulk of this work, but I am very happy with the current structure and its code. I can envision where in the redesigned Game Engine branching logic will be placed to either ask the player to decide or request the AIO to make the decision, depending on who is playing the major power that is “on move”.

Other
The miracle is that my quartet won our local barbershop chapter’s annual contest for best novice quartet. It seems like small potatoes coming in 1st out of 5 but then we came in 4th out of 5 last year, so our reaction was stunned amazement. I also generated 5000 labels from the customer database I maintain for the chapter and we sent out flyers for our spring show. Other than MWIF, singing barbershop is about the only thing I work on these days.
====================================================================
March summary: The unit movement routines are now fully documented but should still be cut into 30 or 40 separate routines from their present monolithic 2. Progress on the AIO was good, but debugging for the release of version 4.00, is going far too slowly.
====================================================================
Tasks for April

Communications
Continue monitoring the forum threads.

Map and Units
See how Rob is doing on the final touch ups for the map.

Scenarios
Add data for the 3 remaining scenarios. [est. 30 hours in May]

Redesign of MWIF Game Engine
Refine the MWIF game engine. [est. 30 hours]

CWIF Conversion
Convert from CWIF style internet formats to Game Record Log Formats. [est. 90 hours]
Test the new random number generator. [est. 1 hour]

Beta Testing
Upload version 4.00 once the game engine redesign is completed and Game Record Log event processing is stable. [est. 1 hour]

Player Interface
Revise the code for determining and displaying supply lines to units. [est. 20 hours]
Test placing all types of naval units into sea boxes. [est 10 hours].
Display sequence of play on the screen so the player knows where he is within the SOP and what is coming up next. [est 30 hours]

NetPlay
Get the bidding capability to function cleanly and modify other aspects of the Player Interface to support NetPlay. [est. 10 hours]
Incorporate the Indy10 code for the two player system into MWIF. [est. 40 hours]

Software Development Tools
Finish replacing all the old components with new ones from JEDI. [est. 15 hours]

AI Opponent
Finish the first editing pass on remaining Strategic plans. [est. 10 hours]

Player’s Manual
Nothing planned for April or May.

Historical Detail, Animations, and Sound
Nothing planned for April or May.

Help System, Tutorials, and AI Assistant
Develop the Introductory Tutorial on supply lines. [est. 15 hours]

Other
I’ll be in Philly for one weekend for my mother’s funeral.
================================================================
April summary: Make an all out push to give the beta testers 4.00. Finish redoing how unit supply is calculated. Still last in line is work on NetPlay.
================================================================

[wfzimmerman]

Bugs seem to be one of the most significant and difficult to manage risk factors in the project.

I remember that at the outset of the project some of us suggested creating a web-accessible bug tracking data base, but Matrix had security concerns and nothing happened. Our bug tracking database is still simply a list that Steve keeps, and this has always worried me. 

 It has now been almost 2 years (IIRC) since the project started, things in the outside world and in Matrix's environment have changed, should we revisit this issue and see if Matrix can't implement a web-accessible bug tracking database?  It seems pretty clear that tracking, solving, and closing bugs is going to be a key issue in determining whether the project meets its schedule and quality goals.  The project is being managed and implemented so professionally in other respects, I hate to see us use a less than optimal method for quality assurance.

[Shannon V. OKeets]

ORIGINAL: wfzimmerman
Bugs seem to be one of the most significant and difficult to manage risk factors in the project.

I remember that at the outset of the project some of us suggested creating a web-accessible bug tracking data base, but Matrix had security concerns and nothing happened. Our bug tracking database is still simply a list that Steve keeps, and this has always worried me. 

It has now been almost 2 years (IIRC) since the project started, things in the outside world and in Matrix's environment have changed, should we revisit this issue and see if Matrix can't implement a web-accessible bug tracking database?  It seems pretty clear that tracking, solving, and closing bugs is going to be a key issue in determining whether the project meets its schedule and quality goals.  The project is being managed and implemented so professionally in other respects, I hate to see us use a less than optimal method for quality assurance.

For my own purposes, keeping track of things that aren't working or that I want to improve, is pretty straightforward and not a problem.

Once I get the beta testers sending in dozens of reports for version 4.00, then having a program/system/package to manage them will be more of a concern. There are several difficulties with using simple lists:

- gathering information on bugs so I can understand what the beta tester experienced
- recreating the problem
- accumulating information about the problem (different circumstances under which it occurs, fixes that have been tried and did/did not work, etc.)
- providing feedback to the person who reported the problem on its status
- combining/eliminating duplicate reports on the same/similar problem

I will give this some more thought once I get version 4.0 out the door.

Though debugging appears time consuming, a lot of that time is spent on:
(1) figuring out how the program processes its response to player actions
(2) documenting those lines of code and/or subsystems
(3) clarifying the code by renaming variables, function, and procedures
(4) improving the code through standardization, centralization, and/or decentralization.

The first 2 happen almost all the time when I 'fix' a problem. 3 and 4 occur less frequently but require a lot more time.

Here is some documentation I created last month. I see I didn't even mention this in the monthly report.

All of the following documentation was created by me through examining the existing code and following call sequences and the use of different variables and functions throughout the program. When I started work on this last month (or perhaps 2 months ago) I had a blank sheet of paper. This falls into the category of #2 - documenting subsystems. When I write this stuff, it is so I can read it 6 months later when I am confused about how the subsystem works. I also find the call sequences very helpful when tracking down a problem (in this case, a problem related to the Moving Stack).

============

MovingStack Documentation
(as of April 1, 2007)

Introduction

MovingStack is used primarily to hold the units the player is in the process of moving. Most often this is when the player is repositioning a unit or units already on the map. An important secondary use is to take units from the setup tray and place them on the map.

The module MoveStack contains the routines for TMoveStack. However because TMoveStack is based on TStack, many of the routines MovingStack uses are in the module Stack.

Definition, Initialization, and Memory Release

MovingStack is defined in the module InProgressVar. It is initialized in the initialization portion of the module MoveStack and free’d in the finalization portion of the same module. The MovingStack starts empty when it is created.

Adding Units

There are 3 places in the code where units are added to MovingStack

∙ WIFUnits, EnterPool:
This is the main routine for adding units to the MovingStack. It handles the updating of the unit’s location and the placement of the unit from one location to another, be that from the map or from an off map pool (e.g., the setup tray).

∙ MoveStack, TransferToMovingStack:
This routine is used to return a unit from a temporary stack back to the MovingStack. At times, the program needs to place units in a stack that the player can manipulate. Once this secondary processing is completed, this routine is used to move the original units back into the MovingStack.

∙ Setup, PrepareMovingStack:
This routine takes the units that the player has selected from the setup tray and places them in the moving stack so the player can then position them on the map.

TransferToMovingStack is called by:

∙ SimControl, WIFNavalInterceptionChoice
This handles the processing of the player’s decision whether to stop or fight his way through when intercepted during naval movement.

∙ WIFUSEntryAction, DoEntryAction
DoDelayedEntryActions, WIFUSEntryAction, and EntryAction call DoEntryAction. The last two are the same, with one for Internet major powers and the other for the local major power. Some US entry actions are delayed until the US player is the phasing player (?). The units in MovingStack are temporarily transferred to USEntryStack while the player responds to US entry actions and then they are transferred back to MovingStack once the US entry action has been processed. For example, when the USSR occupies Eastern Poland, units in Eastern Poland are repositioned using the MovingStack.

∙ MoveStack, DeleteStack
This routine takes the next stack of units in the NavalMovingStack table and transfers them into MovingStack. During naval movement, there might be several moving stacks active at the same time. For instance, the phasing player moves units that are intercepted at sea and he decides to fight through. As a result of combat, some naval units from both sides abort back to port. During the abort back to port, either side’s units might be intercepted, and so on. The program maintains a list of naval unit stacks that need to be moved.

EnterPool is called by OffMapMove and MoveOffMap. Those routines, in turn, are only called by MoveIntoPool, which, with the argument upMoving, is only called by MoveInto. There are 3 places in the code where MoveInto is called:

∙ SimControl, WIFUnitCreateMove
This routine is only used when splitting a convoy into separate units. Each of the new units is given the same location as the original convoy unit. That may be MovingStack (?).

∙ WIFUnits, MoveToStack
This is called after loading the units in a saved game, to give them their correct Unit Placement. That may be MovingStack (?).

∙ WIFUnits, MoveToLoc
This is the primary call to MoveInto. It is called by MoveToMovingStack, MoveToLocation, and MoveToLocationTop. Only the first is exclusively for placing units in the MovingStack.

Here are the places where MoveToLocation is called:

∙ MapTable, CancelStackMove
∙ MoveStack, SetStackValues, SetLandMoveValues, AddHexes, AddDef
∙ Naval, CreateCarrierPlane
∙ Naval, SplitConvoy
∙ SimControl, WIFUnitLoad
∙ UnitMenuProcs, UnitMenuLoad

Here are the places where MoveToLocationTop is called:

∙ MapTable, CancelStackMove
∙ SimControl, WIFUndo, pRailMovement (twice)
∙ SimControl, WIFUnitMove (primary routine for changing unit placement).

Here are the places where MoveToMovingStack is called:

∙ Main, ARailMoveFactoryExecute
This routine creates a temporary unit to represent the factory while it is on the move. The temporary unit is place in the MovingStack so the player can indicate to which map hex it is going.

∙ MoveStack, SetStackValues, SetLandMoveValues, AddHexes, AddDef
I do not understand what this code is doing.

∙ MoveStack, TransferToMovingStack
This routine restores units to the MovingStack from either the USEntryStack or TransferStack.

∙ MoveStack, MoveToMovingStack
This is a recursive call to move all the units that are being transported by the unit originally specified as being moved to the MovingStack.

∙ PhaseControlProcs, PhaseAdvanceAfterCombat
Here the MovingStack is used for moving units in the advance after combat phase.

∙ PhaseControlProcs, PhaseForcedRebase
Here the MovingStack is used for moving units in the forced rebase phase.

∙ GameMapArea, AddToMovingStack
Here the MovingStack is used for moving air units in the return to base phase (for both attacker and defender).

∙ GameMapArea, AddToMovingStack (4 occurrences)
Here the MovingStack is used to place a newly created temporary carrier air unit (when not playing with carrier air units) and any other air unit during air mission subphases. It is also used during all other game phases.

∙ UnitMenuProcs, UnitMenuLoad (twice)
Here the MovingStack is used when the player selects Load Unit from the unit menu.

∙ GameInProgress, SetPhase
When units overrun other units, the overrunning units are placed in the MovingStack.

The routine AddToMovingStack is called from:

∙ MouseCommands, GMAMouseDown (4 occurrences)
The MovingStack acquires the units the player selected from the unit selection form. That form is displayed when the player presses Shift Left button click. The more common way to pick up units is a simple Left button click, which picks up the top unit and places it into the MovingStack (any units it is transporting are also placed in the MovingStack).

In summary, when the player clicks on a hex containing one or more units, the top unit is transferred to the MovingStack with the following call sequence:

1 MouseCommands, GMAMouseDown
2 GameMapArea, AddToMovingStack
3 WIFUnits, MoveToMovingStack
4 WIFUnits, MoveToLoc
5 WIFUnits, MoveInto
6 WIFUnits, MoveIntoPool
7 WIFUnits, MoveOffMap
8 WIFUnits, EnterPool

Almost the same call sequence is used when a player clicks on a unit in the setup tray. The first call is to Setup, PrepareMovvingStack, which then calls the 3rd step in the above list: WIFUnits, MoveToMovingStack.

Removing Units and Clearing the Stack

The MovingStack is cleared of all units in the following places in the code:

∙ GameControls, GameDestroy
When the game is destroyed.

∙ MapTable, CancelStackMove
When a stack move is cancelled, after all the units have been moved back to their starting locations.

∙ WIFUSEntryAction, DoEntryAction
After transferring all the units in MovingStack to USEntryStack.

∙ SimControl, WIFNavalInterception
Prior to transferring the first stack in NavalMovingStack to the MovingStack.

∙ SimControl, WIFTryLandMove
After determining whether a land move was possible and prior to destroying a unit or units (caused by overrun?).

To remove individual units from the MovingStack the routine MovingStack.DeleteIndexOf(U) is called. This happens in only two places:

∙ Main, FormKeyPress, DoDestroyPartisan
This is for voluntarily destroying the top partisan unit in the MovingStack.

∙ WIFUnits, LeavePool
With its companion routine, EnterPool, LeavePool handles almost all relocations of units to/from the MovingStack.

LeavePool is called by MoveInto which was partially analyzed previously in this document. Picking up where that analysis left off, here are the places in the code where WIFUnitMove is called.

∙ MoveStack, MoveTo
This moves all the units in the MovingStack into a hex. The vast majority of unit movement is processed using this routine. For example, all air unit moves go through MovingStack.MoveTo.

∙ WIFUnits, MoveTo
This moves an individual unit into a hex. All the odd actions like breaking down and reforming units, selecting HQ for emergency supply go through this routine.

∙ SimControl, WIFTryLandMove
This runs a check on whether a land move can be made. If the check is ok, then the land move is made.

∙ SimControl, WIFTryNavalMove
This runs a check on whether a naval move can be made. If the check is ok, then the naval move is made.

∙ SimControl, WIFTryTRailMove
This runs a check on whether a rail move can be made. If the check is ok, then the rail move is made.


In summary, the units in the moving stack are removed from the MovingStack (and usually placed on the map) through the following call sequence:

1 MouseCommands, GMAMouseDown
2 MoveStack, MoveTo
3 SimControl, WIFUnitMove
4 WIFUnits, MoveToLocationTop
5 WIFUnits, MoveInto
6 WIFUnits, LeavePool

[Chaylaton]

Hey Steve,
 
Sorry to hear about your mother and I hope for the best with your trip to Philly.
 
Chaylaton

[Shannon V. OKeets]

May 1, 2007 Status Report for Matrix Games’ MWIF Forum

Accomplishments of April

Project Management
It seems like April had only 3 days in it. Overall I lost 2 weeks against the schedule I created in October, which extends the programming schedule into January 2008 for the first time. David Heath had put 3 months of slack in at his end (January through March 2008). So Origins 2008 is still the planned release date.

Communications
Nothing from Rob Armstrong this month.

I monitored all the threads in the MWIF World in Flames forum daily.

Patrice has moved from working on the map to the units, which is discussed in more detail below.

I have yet to upload version 4.00 for the beta testers so things are quiet from them.

Work on the unit writeups made some progress.

Patrice has revived the Rules Clarifications list for eventual transmission to Harry Rowland.

No communications this past month with: Chris Marinacci, Harry Rowland, or Dan Hatchen (NetPlay).

No activity with the AI Opponent team, though the forum members helped with discussions on strategy for many major powers, especially China, for which I had had nothing previously.

Beta Testing
I worked on correcting bugs most of this month. Unit movement works correctly for the places I have tested it. But there are some bugs concerning undoing moves with stacks of units that still need to be fixed. Eventually I would like to split the 2 monolithic routines that process all unit movement into separate routines for land, naval, air, and rail movement. That is partially done already, internal to the monolithic routines, and I now have those pieces well documented. However, there is nothing pushing me to do these changes, other than my own fetish for a well defined structure for the code.

I have been going through each of the 11 scenarios and attempting to set up the units for each major power. In so doing, I have been checking the setup lists for the scenarios and making corrections to them. There are on average 7 major powers per scenario, and roughly 40 units per country, which works out to 7 x 11 x 40 = 3000+ units that need to be checked. Most errors concerned getting the country right for captured naval units. I have those all straightened out now so what remains are typos and to finish adding Cruisers in Flames and Convoys in Flames units to the data lists.

Units
I revisited the graphics for drawing units on the screen and removed a bunch of obsolete code. When I first redid the unit rendering on the screen I wasn’t sure what a lot of the variables and branching logic were there for, but by now I can remove it without worrying. The reason I was looking into this was that I added the graphics for indicating captured units with a band of color across the top of the unit.

The work on the China AI Opponent brought up the issue of Warlord units so I modified the program to incorporate Warlords, Partisan HQs, and City Based Volunteers as new unit types. The last isn’t actually a unit type, but rather is handled internally as a type of ‘reserve’ unit. In many ways it is like a city reserve unit, but there are enough differences that a clear distinction has to be made. These three unit types are the last ones needed for MWIF product 1. There were only 18 actual units/counters involved. I still need to write code for how these units get created and the restrictions on their movement; some of which I have already put in place.

Patrice has identified the new units that need to be added to bring the unit data files up-to-date with the 2007 counter sheets ADG has just released. He is working on doing that for me.

Map
Not much new here. Rob still has a list of small changes to make to finalize the map.

I have decided to put text write ups for named locations on the map into MWIF product 2, and only then if there is a lot of interest in it.

I talked with Fernando (the printer) and Larry (my brother-in-law) while I was in Philadelphia. I need to get the address for Fernando’s FTP site, then I’ll post the large (40+ MB) JPEG there for him to print. He is going to try 2 or 3 different forms of media and then send me several copies of each.

Scenario Information
I did some coding and checking of the scenario data in April and hope to finish them up in May.

Player Interface
Nothing much new here.

MWIF Game Engine
Not much new here.

Internet - NetPlay
Not much new here.

CWIF Conversion
Not much new here.

Saved Games
Not much new here.

Player’s Manual
Nothing new.

Help System, Tutorials, and AI Assistant
Not much new here.

Artificial Intelligence (AI)
I did a lot of work on the AI Opponent this month. Originally I had planned on doing this much later in the schedule, but since I was traveling April, I was able to get a some serious thinking done during the 20 hours I spent in airplanes. Then when I got back home, I had a lot of typing to do.

I now have the text from the forum posts condensed into about 30% of what they had been originally. There are 8 separate files for strategic planning for the AIO, one per major power. As I edited and reorganized the ideas provided by a host of different people, I was able to finally get a good understanding of how the AIO will handle strategic plans at the macro level. Basically this is similar to my originally ideas but with more detail.

The AIO will assess the current position as to units on the board, but even more importantly, the current year and turn. Strategic plans will depend heavily on both. Here are some examples.

France starts on the defense, expecting an attack from Germany, and possibly Italy too. If after a year or so, neither attack occurs, or is blatantly unsuccessful, then gradually, France will shift to a more aggressive posture. France will also look for the opportunity to exploit openings in the German and Italian defenses. Specifically, I do not want the human player to be able to leave one or two units to defend against France, (while going off on other adventures), confident that France will not attack. The expectation is that Paris will fall and then France will fight on while in direct contact with the Axis, and even after losing contact. Though the last will see France in a supporting role to the CW and USA.

China is similar to France in that the starting defensive position is expected to deteriorate, perhaps even to the point of China being completely conquered. Should that not come to pass, then strategically, China will shift to a more aggressive positioning of its units, looking to push the Japanese out of China. And similar to the French, the Chinese will look to exploit any openings that appear in the Japanese front lines.

I have a comparable set of strategies worked out for the USSR, though the USSR has a grace period before Barbarossa, where it can go on the offensive. The naval powers will be similar, with the CW and USA the most difficult because of their far-flung operations.

I am feeling real good about the AIO at this point and I expect to get a lot more done on it while in Europe for 2 weeks.

I wrote more code for the AIO, principally defining variables to hold information the AIO will need for decision making. For example, I have variables for storing where the front lines are, hexes that can be invaded, victory cities, ports that need to be defended , vital hexes, and so on. As aspects of the design come into sharp focus, I write code that captures those ideas. That way I will not have a mountain of stuff to code later, and I can reference the code I have already written as I think through additional elements of the design.

Other
I was in Philadelphia for a funeral and my quartet is very busy preparing to sing 4 songs after our annual spring show. We aren’t good enough to actually sing on the show, but we have been invited to perform at the cast parties afterwards.
====================================================================
April summary: Progress on the AIO was good, but debugging for the release of version 4.00 is taking bloody forever. It was real nice to finish adding the last of the unit types.
====================================================================

Tasks for May

Communications
Continue monitoring the forum threads.

Map and Units
See how Rob is doing on the final touch ups for the map.

Scenarios
Add data for and test all 11 scenarios. [est. 20 hours]

Redesign of MWIF Game Engine
Refine the MWIF game engine. [est. 10 hours]

CWIF Conversion
Convert from CWIF style internet formats to Game Record Log Formats. [est. 90 hours]
Test the new random number generator. [est. 1 hour]

Beta Testing
Upload version 4.00 once the game engine redesign is completed and Game Record Log event processing is stable. [est. 1 hour]

Player Interface
Revise the code for determining and displaying supply lines to units. [est. 20 hours]
Display sequence of play on the screen so the player knows where he is within the SOP and what is coming up next. [est 30 hours in June]

NetPlay
Get the bidding capability to function cleanly and modify other aspects of the Player Interface to support NetPlay. [est. 10 hours in June]
Incorporate the Indy10 code for the two player system into MWIF. [est. 40 hours in June]

Software Development Tools
Finish replacing all the old components with new ones from JEDI. [est. 20 hours in June]

AI Opponent
Work some more on strategic plans, define a language for the AIO and flesh out more of the AIO decisions as text. [est. 120 hours]

Player’s Manual
Nothing planned for May or June.

Historical Detail, Animations, and Sound
Nothing planned for May or June.

Help System, Tutorials, and AI Assistant
Develop the Introductory Tutorial on supply lines and weather. [est. 20 hours]

Other
I’ll be in Europe for 2 weeks visiting relatives and Patrice!
================================================================
May summary: Keep trying to give the beta testers 4.00. Finish redoing how unit supply is calculated. Work on the AIO while away from home.
================================================================

[gilderan]

Thanks for all the updates. I check in every few months or so to see how the development is going.

[Bluestew0]

I too appreciate the detailed updates. I check in once a month to read the updates and to force me to remember my password. [;)]

To Steve.....I admire your organizational skills.

[Sewerlobster]

These monthly updates are great. Keep on plugging away, I can't wait for 07/08 but knowing what you are doing is awesome; I can't help but be emotionally invested already.

Any idea when prepurchasing will be permitted? Even if you can only express it in when development is at t-x# of weeks.

[Shannon V. OKeets]

ORIGINAL: SewerStarFish

These monthly updates are great. Keep on plugging away, I can't wait for 07/08 but knowing what you are doing is awesome; I can't help but be emotionally invested already.

Any idea when prepurchasing will be permitted? Even if you can only express it in when development is at t-x# of weeks.

Welcome to the MWIF forum. I enjoy reading everyone's posts and many of the design decisions I have made for MWIF have been either directly or indirectly due to forum members' comments.

As for prepurchasing, Matrix handles all the marketing decisions. I have more than enough to do just plugging away at the code.

[Darkman99]

hello,


im a new member in this forum and im very interseted in World of Wlames.
i found a Link on the A-D-G website to a BETA for the computer Game,but the link doesnt work.[&:]
has anyone a link to the Beta ?

best regards
Kai

[Mziln]

http://www.a-d-g.com.au/
Then Products
Then WiF the (original) computer game
 
Price: $15.00 US, $20.00 AU
 
As Patrice has noted this is the old CWiF, which was prior to MWiF and its changes.

[Jeff Gilbert]

Getting very close to the monthy information update ... [:)] 
Always one of my major highlights.

[Shannon V. OKeets]

June 1, 2007 Status Report for Matrix Games’ MWIF Forum
EDIT: Corrected date above from May 1 to June 1.
Accomplishments of May

Project Management
Origins 2008 is still the planned release date.

Communications
Nothing from Rob Armstrong this month.

I monitored all the threads in the MWIF World in Flames forum daily.

I met with Patrice and his family in St. Remy, France for dinner. He and I talked in a WIF dialect of English while our wives spoke French (they looked seriously bored at times).

I couldn’t quite meet up with Jesper (Capitan) while in Provence, France. We got with 100 km of each other, but passed like ships in the night.

I have yet to upload version 4.00 for the beta testers, so things are quiet from them.

No communications this past month with: Chris Marinacci, Harry Rowland, or Dan Hatchen (NetPlay).

I heard from Richard Dazeley again (PhD in AI) who has expressed renewed interest in the AIO for MWIF. I promised to send him a copy of the AIO language specifications I worked out while traveling.

Beta Testing
I didn’t get much time to debug this month. After typing in all the scenario data I started running through each of them to make sure there weren’t typos undetected by the compiler. Of course there were some bugs, most of which were easy to fix, but that still took time.

Units
I made a few tweaks to the data files for the units. Some of the synthetic oil plant units have to be built in specific hexes, and one of them costs extra. I also merged the storage needs for specific city hexes into one location in the files and internal storage. These are for city reserve units, Chinese warlords, and “city based volunteers”. The last are units who fight against the country that originally controls the city, once the city is taken by the enemy. For example, if the Japanese take Calcutta, then they can raise an Indian unit (based in Calcutta) to fight on the side of the Japanese.

While on the plane, I reviewed all the current land unit writeups (152 pages) that Jesper had sent me. Afterwards I typed in my edits at home. This brings me up-to-date reviewing and editing all the writeups (air, naval, and land).

Map
Nothing new. Rob still has a list of small changes to make to finalize the map. I consider the graphics work to be 98% complete with most of the remainder being art work for the packaging and start up screens.

I sent a test file (30% of the world map - a vertical stripe including Iceland, all of Europe, and all of Africa) to Fernando (the printer) just before I left for Europe but I haven’t heard back from him yet. He had said he would produce the map on several different media so I could decide which one works best.

Scenario Information
I finished typing in the data for all 11 scenarios. The later scenarios still need a close review of the various events that are suppose to happen before they start.

For example, Decline and Fall starts with Vichy having been declared and then collapsed and Italy conquered. That scenario contains a lot of naval units from conquered countries that start the scenario as part of a different country’s fleet (e.g., Dutch, Danish, Norwegian, French, Yugoslavian, Greek, and Italian units). The start up instructions for Decline and Fall do not explicitly mention the declaration of Vichy and its collapse, but in game terms that is important because it affects the force pools. I believe I will have to use the historical date for the declaration of Vichy so the modification to the force pool is done correctly.

Player Interface
I started designing the forms/screens for displaying and manipulating naval task forces. These are just groups of naval units that the player can define at will, saving himself time later when deploying them to sea and returning them to base. With the addition of light cruisers from Cruisers in Flames to the unit setups, there are 50 to 100 naval units for the large maritime powers (US, Japan, Commonwealth) that need to be set up at the start of the game and put to sea/return to base each turn.

The design and mechanics for creating and modifying task forces is pretty well set. The next step is to actually create the forms in code and display them for review by the forum members. This is low on my priority list of things to do right now, but I would like to get to it in the next 2 months.

MWIF Game Engine
Not much new here.

Internet - NetPlay
Not much new here.

CWIF Conversion
I am correcting the MWIF Lend Lease routines so they match the WIF FE rules. CWIF used a simplified version of these rules, permitting players to lend lease any air units they wanted to. The Rules as Written (RAW, August 2004) limit which air units can be ‘lent’ to other major powers. These are well defined groups of air units and when the USA lend leases one of it units to the USSR (for example), then the USSR gets a matching unit, which may have slightly altered combat and movement factors. In addition, the USA loses the ability to build the unit it has ‘lent’.

There are 73 lend lease air units in the counter mix and I rechecked all that data for accuracy. I also established exactly which air units constitute each of the 47 lend lease groups, which involves roughly 200 air units out of the 2000+ in the game. Currently, everything loads in correctly at the start of a game..

I still need to modify the player interface to support the new design, though that is partially completed. In order to lend lease a unit, the player who is receiving the unit needs the player who owns the source unit to agree. For example, for the USSR to lend lease a Spitfire, the Commonwealth player has to agree to remove a Spitfire unit from his pool of units available to be built. While in Europe, I worked out a simple solution for when and how to enable units to be lend leased at the start of the game, before the random drawing of units from the force pools takes place.

Saved Games
Not much new here.

Player’s Manual
Nothing new.

Help System, Tutorials, and AI Assistant
Not much new here.

Artificial Intelligence (AI)
I spent most of my travel time working on the AI Opponent. I reviewed the strategic plans for all the major powers and made substantial improvements to them. Since I’ve been back, I’ve typed in the edits to the existing strategic plan documents for France, Japan, and the CW, with my notes for the other major powers still awaiting typing. On average, the strategic plans are running about 40 pages, with some shorter and some longer.

What I am getting closer to is a standard format for all 8 major powers. In fact, I have designed: (1) the data structure for storing about half of the strategic plan information into program variables and (2) the format for the accompanying CSV files. For France, I have written, (for eventual data entry into the CSV file), the half of the strategic plan that has been designed. The idea here is to understand what information a generalized (one size fits all) strategic plan contains, give it a structure, and then format it for rendering in a CSV file. By working with concrete examples, rather than imaginary abstract concepts, I am confident that what I have designed will be usable.

For the portion of the design I am certain about, I have written up code (it still needs to be typed in). The pieces of this puzzle are coming together, but I need to get back to debugging now that I’m home. In a couple of months I’ll have more time to focus on just the AIO, and I then should be able to finalize the strategic plan design in roughly a week.

Second, I created a language for writing rules for the AIO’s decision making. I’m calling this LAIO (Language for AI Opponent) and it is fairly primitive. After exploring the possibilities of a more elaborate language, I decided that the return on the investment of time and effort would be low. In previous jobs I have created fairly complex languages and coded the parsers for processing them, but MWIF presents some obstacles that would require a lot of time to overcome. In particular, the number of variables within the game that the decision rules will reference is very large. Branching logic for the different unit types (70) and terrain types (12) come to mind. There are also the weather, combat tables, and relative strength of the units on map and in production for each country.

Basically, if a rule includes a variable related to the game-in-progress, (e.g., IF Weather = Blizzard ...) then the language would have to provide a means for referencing that variable and the parser would have to establish the link between the rule reference and the game variable. Almost all of these variables have different values (e.g., utArmor, teForest, wtBlizzard, ctAssault), each of which requires its own accommodation within the language. If they all had numeric values between 1 and 100, then things would be easier to code, but that is clearly not the case.

Another possibility would be to write all the AIO rules as code within the program. That is unsatisfactory because it would require recompiling the program every time I changed a rule, even slightly. So I decided I would simplify my life a little and use a hybrid of the two extremes: (1) a full/script language with access to all the game variables and (2) hard coded rules.

Presently the design assigns intermediate variables for each rule (e.g., B1, B2, O1, O2, D1, D2) and the code branches on the rule number to determine what each of those means. So, assuming the JCS (Joint Chiefs of Staff) rule #10 has a reference to B1, B2, and O1, then internally the program would have hard coded translations. B1 (Boolean 1) might be Weather = Blizzard. It will have a value of True if and only if the current weather is blizzard. Another rule could also use B1 as a variable with a completely different meaning. Indeed, I expect B1 to be a very popular variable.

O is for Ordinal, I is for Integer, and D is for decimal. I intend to make frequent use of one particular ordinal scale: Awful/Poor/Fair/Good/Very Good/Excellent. I have found this to be easier to work with than integer numbers (say from 1 to 100) and decimal numbers (3:2 odds = 1.5). In practice the combat odds would be translated from a decimal number to the APFGVE ordinal scale. Done correctly, the loss of accuracy will have little effect on how well the rule works and the translation from the fine detail of decimal numbers to the cruder ordinal scale will simplify writing the rules enormously.

The rules themselves will be stored in CSV files and reference the intermediate variables. This permits them to be edited without recompiling the program. Of course, if the meaning of an intermediate variable has to be modified, then recompiling will be necessary.

Third, I reviewed all the descriptions I have written up for how each decision the AIO makes should be encoded. There are still gaps in the full set but I have been able to complete about 75% of them. The text descriptions start out as explanations any WIF gamer would understand, progress from there to a more rigorous and exhaustive methodology (that handles all conceivable possibilities), and lastly end up as rules written in LAIO. About a quarter of the rules now have a rigorous methodology associated with them. To summarize: 1/4 blank, ½ with descriptions in WIF terminology, and 1/4 with rigorous methodology. Oh, and one actually written in LAIO.

Just to tie together some loose ends of this description of the AIO:
∙ During a game there are a fixed number of places where the AIO has to make a decision.
∙ For each decision point a LAIO rule will exist.
∙ The AIO will decide what to do by parsing the LAIO rule, dynamically evaluating the intermediate variables, and processing the rule (IF ... THEN ...).
∙ Oftentimes, the LAIO rules will reference the current strategic plan for the major power that is making the decision. Those strategic plans will have been read in from the CSV files (when the Solitaire game began) and stored internally as variables.

Other
The trip from Honolulu to Bulle, Switzerland took 23 hours door to door. However, on the return trip the airline caused enough of a delay that we missed our connection and it took 45 hours (overnight in Houston). Jet lag coming back has been much more difficult too.
====================================================================
May summary: Progress on the AIO was excellent, but debugging for the release of version 4.00 is still taking forever. It was real nice to finish typing in all the scenario data.
====================================================================
Tasks for June

Communications
Continue monitoring the forum threads.

Map and Units
See how Rob is doing on the final touch ups for the map.

Scenarios
Continue testing all scenario data. [est. 10 hours]

Redesign of MWIF Game Engine
Refine the MWIF game engine. [est. 10 hours]

CWIF Conversion
Convert from CWIF style internet formats to Game Record Log Formats. [est. 80 hours]
Test the new random number generator. [est. 1 hour]

Beta Testing
Upload version 4.00 once the game engine redesign is completed and Game Record Log event processing is stable. [est. 1 hour]

Player Interface
Revise the code for determining and displaying supply lines to units. [est. 20 hours]
Display the sequence of play on the screen so the player knows where he is within the SOP and what is coming up next. [est. 30 hours]

NetPlay
Get the bidding capability to function cleanly and modify other aspects of the Player Interface to support NetPlay. [est. 10 hours]
Incorporate the Indy10 code for the two player system into MWIF. [est. 40 hours]

Software Development Tools
Continue replacing old CWIF components with new ones from JEDI. [est. 10 hours]

AI Opponent
Type in the rest of my handwritten notes. [est. 10 hours]

Player’s Manual
Nothing planned for June or July.

Historical Detail, Animations, and Sound
Nothing planned for June or July.

Help System, Tutorials, and AI Assistant
Develop the Introductory Tutorial on supply lines and weather. [est. 20 hours in July]

Other
In early May our chorus had a successful spring show. While my quartet did not sing in the show we were invited to perform at the two cast parties. I have attached a picture of my quartet taken back in February. From left to right they are: Chris (tenor), Jeff (Chris’s father singing lead), me (Bass), and Kamu (Baritone).

At one of the cast parties we performed the song “Sam, You Made the Pants Too Long”, which is told to Sam, a tailor, about how the “coat and vest, fit the best” but the “trousers dragging, slowly dragging through the street; I am walking but I’m walking without feet”. For the performance Chris bought a pair of pants with a 50 inch waist (145 cm) which he held up in one hand while singing the song. Before the song started his father, Jeff, leaned over and peered down the front of Chris’ pants, then turned to the audience with a big smile and said proudly, “That’s my boy!”. In the next post I have attached a picture of us singing the last chord of the song.
================================================================
June summary: Keep trying to give the beta testers 4.00. Finish encoding unit supply calculations. Return to work on Game Record Log conversions in preparation for NetPlay.
================================================================

[Shannon V. OKeets]

The last chord of "Sam, You Made the Pants Too Long." Note the hands applauding.

[Zap]

Nice shirt, A face to the name helps, but you don't look like a Shannon V. OKeets, however![:)]

[Froonp]

ORIGINAL: Zap

Nice shirt, A face to the name helps, but you don't look like a Shannon V. OKeets, however![:)]

What should a Shannon V. OKeets look like ?

ORIGINAL: Shannon V. OKeets
I met with Patrice and his family in St. Remy, France for dinner. He and I talked in a WIF dialect of English while our wives spoke French (they looked seriously bored at times).

This was good time !!!! [:D] Thanks again for coming !!!

[Neilster]

Lose the old, fat, bald guy with the beard. He looks out of place. [:D]

Cheers, Neilster

[Zap]

Now you did it Neilster[:)], I would'nt say that because I,m old,fat,bald(no beard though). [:D]

[Shannon V. OKeets]

ORIGINAL: Neilster
Lose the old, fat, bald guy with the beard. He looks out of place. [:D]

Cheers, Neilster

Those things don't matter in barbershop singing (though they do on American Idol[:D]).

As they say, barbershop is a thinking man's 'sport'.

First, you need good ears to hear whether the note you are singing is perhaps a bit too sharp or flat. Each person is singing a different note and if one note is slightly out of tune, the chord doesn't 'ring'. And ringing chords is what barbershop is all about. When blended perfectly, the wavelengths/frequencies of the 4 notes reinforce each other producing an 'enhanced/expanded' sound - ringing chord. Ideally every chord in a song rings when it is sung correctly. Besides ptich, vowel matching is crucial for the ring disappears if one person sings their A's as in 'hat' while everyone else sings them as in 'car'. And then the volume relationship has to be right too, with the Lead (who usually sings melody) loudest, the bass second loudest (and full, for the lowest frequency is what the other notes enhance), the tenor high/sharp and light, and the baritone slightly low/flat within the range for his note (assuming he is singing the 7th in the chord). At times the baritone notes will look identical on the written music, but actually be sung slightly higher/sharper or lower within the range of the note to make the different chords ring.

Second, you need good production abilities, which is not just how loud you can sing, and how big a breath you can take, but also the ability to sing louder, softer, faster, slower, smoothly, stacatto, etc. as required by the song. barbershioppers always have the same posture when singing, feet positioned directly under hips to the width of the shoulders, and shoulders over hips. You can wave your arms around and turn your head slightly, but the vocal production from diaphragm through vocal folds, and across the soft palate can't be messed up.

Third, timing is crucial. The lead sets the tempo and decides any changes to same during the song. Many barbershop songs have changes in tempo to make the song more interesting to the listener. The 3 harmony parts have to be especially sensitive to what the lead is doing with the song (it is likely to change from one performance to the next depending on the lead's energy level and mood) and come in on each vowel exactly when the lead does, sustaining the note precisely up to the point the lead cuts it off (these are called attacks and releases). And the lead also dictates how loud the song is as it progresses, with the harmony parts required to follow/match.

Fourth, we never sing holding printed music. It is all done from memory. About 8 years ago I was worried that my memory might be fading so as a test I learned the following song (see below - it is sung to the tune of the Mexican Hat Dance). I have since performed this solo on several occasions. Also the 3rd verse is my own invention.

Fifth, as performers we have to emote for the song and convince the audience that we believe every word we are singing with the deepest conviction. Luckily that ususally simply means smiling the whole time with a lot of energy, since we rarely sing depressing songs.

I've been doing this for 10 1/2 years and I am still learning the craft and working on improving my abilities. Inevitably after a performance all 4 guys in the quartet believe they could/should have done better.[:)]

Given all that, age and weight don't matter. Though perseverance, dedication, and personality do. The 4 guys have to really be able to get along and work hard to be capable of singing even one song well together.

======
Yakko’s World by Randy Rogel
(as sung by Brian Philbin of Metropolis)
Lyrics modified by Steven Hokanson, July 16, 1999 and May 16, 2006

United States, Canada, Mexico, Panama, Haiti, Jamaica, Peru,
Republic Dominican, Cuba, Carribean, Greenland, El Salvador too,
Puerto Rico, Colombia, Venezuela, Honduras, Guyana and still,
Guatemala, Bolivia, then Argentina, and Equador, Chile, Brazil,
Costa Rica, Belize, Nicaragua, Bermuda, Bahamas, Tobago, San Juan,
Paraguay, Uruguay, Suriname, and French Guiana, Barbados, and Guam.

Norway and Sweden and Iceland and Finland and Germany, now in one piece,
Switzerland, Austria, Czech and Slovakia, Italy, Turkey, and Greece,
Poland, Romania, Scotland, Albania, Ireland, Russia, Oman,
Bulgaria, Saudi Arabia, Hungary, Cyprus, Iraq and Iran,
There’s Syria, Lebanon, Israel, Jordan, both Yemens, Kuwait, and Bahrain,
The Netherlands, Luxembourg, Belgium and Portugal, France, England, Denmark and Spain.

Estonia, Latvia, Georgia, the Ukraine, Armenia, Azerbaijan,
Croatia, Moldova, Slovenia, and Lithuania, Uzbekistan,
St. Lucia, St. Vincent, St. Kitts and Nevis, the Solomon Islands, Nauru,
East Timor, Samoa, the Seychelles, the Marshalls, the Maldives, and Vanuatu.
Cote D’Ivoire, Comoros, Andorra, Grenada, Belarus, and Turkmenistan,
Macedonia, Bosnia-Herzegovina, Serbia, Tajikistan,

India, Pakistan, Burma, Afghanistan, Thailand, Nepal, and Bhutan,
Kampuchea, Malaysia, then Bangladesh Asia and China, Korea, Japan.
Mongolia, Laos, Tibet, Indonesia, the Philippine Islands, Taiwan,
Sri Lanka, New Guinea, Sumatra, New Zealand, and Borneo and Vietnam,
Tunisia, Morocco, Uganda, Angola, Zimbabwe, Djibouti, Botswana,
Mozambique, Zambia, Swaziland, Gambia, Guinea, Algeria, Ghana.

Burundi, Lesotho, and Malawi, Togo, the Spanish Sahara is gone,
Niger, Nigeria, Benin, Liberia, Egypt, U.A.E., Gabon,
Tanzania, Somalia, Kenya, and Mali, Sierra Leone and Algiers,
Eritrea, Namibia, Senegal, Lybia, Cameroon, Qatar, and Zaire.
Ethiopia, Guinea Bissau, Madagascar, Rwanda, Majorca, Cayman,
Congo, South Africa, and Mauritania, Antigua, Chad, Cape Verde, Dominica,
Monaco, Liechtenstein, Malta and Palestine, Fiji, Australia, Sudan.

Ole.

Underlined portions are SJH modifications/interpretations. Czech and Slovakia substitutes for Czechoslovakia since the latter was split into the two separate countries. Congo, South Africa replaces Hong Kong (since it was incorporated into China proper in 1998). Yugoslavia was removed since it dissolved into separate countries in the 1990's.

The new third verse is composed mostly of countries from the break up of the USSR and Yugoslavia, plus some newly independent countries in the South Pacific.

Countries that are still missing are:
Burkina Faso, Brunei, Central Africa, Kazakhstan, Kiribati, Palau, San Marino, Sao Tome and Principe, Singapore, Tonga, Tuvalu, Vatican, Micronesia, and Kyrgystan,