|
Shannon V. OKeets -> RE: When? (7/1/2011 6:34:58 PM)
|
July 1, 2011 Status Report for Matrix Games’ MWIF Forum
Accomplishments of June 2011
Project Management
I monitored all the threads in the MWIF World in Flames forum daily.
Rolf fixed a couple of bugs in the sequence of play (yay!). Mitchell is revising the stand alone program NetPlayComTest, which he should be ready to incorporate into MWIF proper the first week of July.
Hardware and Software
The open items for Theme Engine remain unchanged: (1) scroll bars for the detailed map, and (2) its inability to display detailed listings of file directories (i.e., the dates and stuff when opening or saving a file). Neither of these is important. I bought Aaron a copy of HyperSnap so he could retake all the screenshots for the Players Manual.
Beta Testing
I released versions 8.03.03 (3 fixes), 8.03.04 (15 fixes), 8.03.05 (3 fixes), 8.03.06 (9 fixes), 8.03.07 (15 fixes), 8.03.08 (3 fixes), 8.04.00 (9 fixes), 8.04.01 (2 fixes), 8.04.02 (14 fixes) and 8.04.03 (6 fixes) to the beta testers last month. This totals 10 new versions and 79 fixes, which is way under my average number of fixes for a month. That’s because some of those ‘fixes’ were changes to multiple places in the code to accommodate NetPlay. In total, I made 79 changes to convert the last of the CWIF code to MWIF Game Record Logs to support NetPlay. Those changes for NetPlay sometimes introduced fatal bugs - hence the quick uploads or new versions that contained only 2 or 3 fixes.
There are 83 bugs remaining in the sequence of play. I keep driving the number down to the low 70's and the beta testers drive it back up to the low 80's. Sooner or later they have to run out of obscure things to find. During the past month I made changes for:
• Splitting convoy units when using the Pools form, so the arrival year is now correct.
• Japan sending a saved oil point to Italy and Italy using it in production.
• Building units ahead where sometimes the program mistakenly took a unit even further ahead than intended.
• Selecting which one of multiple conquered units arrives as a reinforcement.
• Checking French Foreign Troop Commitment in the United Kingdom after the UK has been conquered and some hexes retaken by the US. Since the US owns the hex, the French do not have to check FTC. When the Commonwealth retakes a hex, the French do have to satisfy FTC.
• Collapsing Vichy France so Vichy French naval units in the Construction and Repair pools are transferred to the ownership of the major power that collapsed Vichy France.
• Checking the Naval Combat Abort Queue processing so units that do not cooperate can no longer be moved into the Chosen to Abort Group. This prevents problems later when they would be unable to stack in the same port.
• Processing the naval abort queue so if a second naval combat occurs while there are still units in the queue from the first naval combat, then any newly aborting units are added to the front of the queue. For example, if there are 2 units in the abort queue from the first combat when a second naval combat occurs that causes 5 more units to abort, the 5 new units in the abort queue are processed before the 2 from the earlier combat. The logic here is that the naval combat abort queue is a LIFO (last in first out) queue as far as a series of naval combats is concerned. However, within each combat it is a FIFO (first in first out) queue. I decided on LIFO for multiple naval combats since that is the way the Fighting Through stacks are processed. For example, suppose that the first naval combat was a naval interception combat with 6 units that aborted, followed by 4 of the aborting units moving as a stack, being intercepted, and provoking a second naval interception combat. From the second interception combat there are 5 units that are added to the 2 units still in the naval abort queue. The processing sequence is now: (1st) 5 newly aborted units, (2nd) naval moving stack of 4 units that provoked the second combat - assuming some have survived, (3rd) 2 remaining units in the naval abort queue from the first combat, and (4th & last) the naval moving stack that provoked the original interception combat - again assuming that some have survived. Clear as mud, eh what?
The queue numbers for units that abort from the first naval interception combat begin at 1001 and go up by 1 as each group of units aborts from the combat. For instance, there might be units from both sides that abort in the first round and they would be numbered 1001 and 1002 (different numbers for each side). In the second round there might only be units from one side that abort, which would be numbered 1003. And so on. If after the first combat reaches quiescence there is a second combat due to aborting units moving through another sea area and being intercepted, then units aborting from the second combat will have queue numbers starting at 2001. This numbering scheme enables the program to have all the units from the second combat abort/move before the units remaining to abort from the first combat. It also permits the program to detect when all the aborting units from the second combat having been returned to base so the moving stack that provoked the second combat can be returned to base before the remaining units in the abort queue. Note that if a naval combat is initiated during a naval combat phase, then the queue number for units that abort from that combat start at 1.
Saved Games
Nothing new.
Map and Units
Rob and Adam continue to send me new and/or updated naval and land unit writeups, respectively.
Scenarios and Optional Rules
Michael has prepared 5 Fast Start saved games. Here is an edited except on that from the Players Manual:
Many people like to jump into a new computer game as soon as it is installed, picking up the rules as they go. To facilitate this, MWIF comes with Fast Start saved games for 5 of the most commonly played scenarios: Barbarossa, Guadalcanal, Fascist Tide, Global War, and Missed the Bus. To access these games, click on the Restore a Saved Game button and select one of those 5 scenarios. Note that all of the Fast Start saved games use the solitaire mode of play and the Novice set of optional rules.
The Fast Start games begin at the first major decision of the scenario. For instance, Barbarossa starts with Germany deciding whether to align Hungary or Finland. Global War starts with the Commonwealth about to set up the Poles. These saved games are particularly useful for newcomers to the World in Flames game system, since they begin after the possibly intimidating Setup phase; Lend Lease, Scrap Units, and Unit Setup subphases have already been performed. Fast Start games also use very few optional rules, allowing new players to get a feel for the basic game without having to deal with the more complex optional rules.
I am making some hard decisions about which optional rules will be in the initial release. There are 56 optional rules already coded and debugged. I have 7 more that I would really like to include in the first release, some of which are already mostly coded. That leaves 17 that will definitely not be part of the initial release. See the last section of this report for the list of those 7 and 17.
MWIF Game Engine and CWIF Conversion
I finished converting the last 79 places in the sequence of play where CWIF used Windows messaging to communicate over the Internet. The new code uses Game Record Logs and Indy10 (a Delphi software library that employs TCP/IP for internet communications). The number of unique calls to SetGRL is just under 400. You can translate that as 400 unique record types, one for each decision/event that occurs in the sequence of play (for an example of what one of these record type looks like, see the end of this report). That number will probably go up once we get into testing NetPlay. I have embedded notes in the source code to check a half dozen places where I believe another GRL needs to be created. There are also a bunch of optional rules that will need their own personal GRLs (e.g., Guard Banner Armies, Kamikazes, and Naval Supply Units).
On average, each conversion required about 50 edits, spanning a dozen different modules. That comes out to around 4000 edits for GRLs last month, and having to jump around from module to module for each conversion increased the likelihood of me making errors. The beta testers found about ten, which from their point of view popped up in code that had previously been functioning without problems. But the conversions are essential for NetPlay and PBEM (that is: whenever more than 1 computer is being used). The hardest conversions to make were for moving units, especially naval moves, because of all the information required to keep track of exactly which units are moving through which hexes to reach their destination. Once the units arrive at their destination, what happens next depends on where they started and various other conditions. For instance, did the naval units start at sea? Were they out of supply? Were they intercepted in their arrival sea area? And so on.
Another group of GRL conversions had to do with bidding for major power groups at the start of the game. That code will not be tested until NetPlay is up and running. Which should happen this month (July).
Player Interface
Nothing major here. I modified the code so the UnitData panels and the Status Indicators show when a unit is flying a night mission and/or at extended range. This helps when returning air units to base after an air mission since now you know which ones flew at extended range. It also is of value when choosing targets in an air-to-air combat and for anti-aircraft fire.
Internet - NetPlay
I finished converting the CWIF code to MWIF Game Record Logs, as discussed above.
Mitchell started working with Aaron testing NetPlayComTest, version 2.0. A few problems with handling disconnects and the like had been discovered the last time Mitchell worked on debugging this with Paul earlier in the year. Mitchell’s goal for version 2 is to solve those problems.
For those of you who don’t know, NetPlayComTest is a stand alone program (written by me and improved by Mitchell) which uses Indy10 to send and receive messages over the internet. It deals with all the issues of establishing communications between two or more computers. Then it permits the users to send messages back and forth. Its original purpose is to test the software for use by MWIF proper. But it will also be included in the released product so players can test their communication links without having to run the game itself. If as a player you can get NetPlayComTest to work for communicating between all the players in your game, then MWIF should run NetPlay without problems. Some of the issues it needed to deal with are IP addresses, port numbers, and firewalls - all that good stuff.
Mitchell is also taking a serious look at the MWIF code’s side for handling Internet messages. Once a player has made a move and a GRL (Game Record Log) has been created, Message Control passes it to Mitchell’s NetPlay code for transmission. At the other end, NetPlay receives the message and hands it off to Message Control on the second computer for processing. The design for Message Control is as Spartan as I could make it. So far the feedback I have gotten from Mitchell is that Message Control does not need to be modified.
I am a firm believe in compartmentalization for software. The purpose behind those 400 GRLs is to isolate and completely remove the NetPlay and Message Control code from all the details as to how the game/simulation operates. NetPlay gets a simple string value with an identifier (ID number). It then sends it to its twin on another computer. That the game being played is World in Flames never enters into the NetPlay code. The data it sends and receives could just as easily be orders for tulip bulbs.
PBEM
Nothing new.
Artificial Intelligence (AI)
Peter finished the geographic breakdown for the AI Opponent. It looks great.
I have asked him to look into the Data Structures necessary for AIO strategic plans. I had already done some preliminary work on that. The goal is to design variables for holding all the information necessary to define a strategic plan for a major power. The 3 main elements are: (1) objectives to hold/take, (2) geographical areas to defend/attack, and (3) time lines for declarations of war/offensives, with accompanying production schedules. Some of the data will define conditions for when something should happen (e.g., when to start building garrison units). Defining data structures for conditionals is always difficult, but Peter and I already did some of that when we were working on setup scripts.
Player’s Manual
Aaron has been editing the largest section of the Players Manual: 8 Player Interface. As he makes changes he sends me replacement paragraphs. He has also taken on the major task of retaking all the screenshots needed for the Players Manual. He tells me the most recent count is 206, of which he has done ~150.
The biggest editing changes he has made have been for Production Planning. That form is very complex, since the tasks of fulfilling trade agreements, routing resources to factories, and saving oil/build points can potentially span the entire world map. Those are also critical tasks, since they directly affect production. Every player wants maximum control over these decisions, and a clear understanding of what is happening for his major powers as well as those commanded by other players.
What Aaron and I decided upon was to add a dozen or so small insert figures that are pieces of the overall Production Planning form. This means that when the text discusses, say, Filters for the resources and factories list, a little picture of the Filter radio buttons is shown. The overall effect is that it is much easier to understand the text by referring to the little figures instead of having to look back to a previous page and locate where the Filters are on the full-page form. I am now real happy with how this section reads, instead of being anxious about it being incoherent.
Tutorials, Training Videos, and Context Sensitive Help
I reviewed the training videos I made about 2 years ago. All 9 of the chapters I have recorded have small discrepancies when compared with the current version of the game. But to my eye those are mostly minor differences, and not worth re-recording an entire chapter (some of them are over 30 minutes long). I need to redo chapter 6, since it references the production planning form and uses a completely out-of-date screenshot of that form. But the other 8 chapters I think I’ll leave as is. I still have 3 more chapters to do: 10, 11, and 12, which cover naval movement & combat, production, and politics (i.e., declarations of war et al).
By the way, Erik Rutins of Matrix Games is reviewing my existing Training Video chapters and will either bless my decision to leave them as is, or tell me I need to redo them.
I updated the Status Indicators Help page to include Extended Range, Night Missions, and Flying at Sea when Not Engaged in Combat.
Historical Video, Music, and Sound Effects
Dave and Erik of Matrix Games are working on getting the sound effects and music to me so I can insert them in their proper places in the sequence of play.
Marketing
Nothing new.
Communications
Nothing new.
----------------------------------
Optional rules not yet coded, that hopefully will be included in the initial release:
5.1 Unlimited breakdown
5.2 Rough seas
5.3 Naval Supply Units
5.4 Convoys in Flames
5.5 Guards banner armies
5.6 Kamikazes
5.7 City based volunteers
Not included in the initial release:
5.8 Flying bombs
5.9 V-weapons
5.10 Atomic bombs
5.11 Partisan HQ
5.12 Frogmen
5.13 Japanese command conflict
5.14 Hitler’s war
5.15 Naval offensive chit
5.16 USSR-Japan compulsory peace
5.17 Recruitment limits
5.18 Oil tankers
5.19 No ZOC During Surprise Impulse
5.20 Bounce combat
5.21 En-route aircraft interception
5.22 Limited aircraft interception
5.23 The Ukraine
5.24 Intelligence
---------------------
TRL_TNM = record // Try making a naval move.
MsgID: Integer;
EntryNum: Integer; // Game record log entry number - increments each time an entry is written.
TransNum: Integer; // Game record log transaction number - increments each time a group of entries are sent.
By: Byte; // Who originated the GRL (e.g., major power ID).
PlayerID: Byte; // Which player originated the GRL.
UUnitPlace: Byte; // New Location for the naval unit stack. This may be to an off-map pool or On Map.
UColumn: Integer; // Only used when moving on the map.
URow: Integer; // Only used when moving on the map.
UProdTurn: Byte; // Only used when moving into the production pool; denotes arrival turn.
UOldUnitPlace: Byte; // Old Location for the naval moving stack.
UOldColumn: Integer;
UOldRow: Integer;
UOldProdTurn: Byte;
USentry: Byte; // Whether the stack goes into sentry mode when it stops in a sea area.
UHostile: Boolean; // Whether the stack makes Vichy Hostile when stopping in a port.
UStartedAtSea: Boolean; // Whether the stack originally started its move at sea.
UUndoSave: Boolean; // Whether the move can be undone by the player later.
UCheckInterception: Boolean; // Whether the moving stack might be intercepted in New Location (if a sea area).
ULoadedInPort: Boolean; // Whether the moving stack has loaded a unit in port before it started moving.
NavalMPUsed: Byte; // How many movement points are used to reach New Location.
NavalRangeUsed: Byte; // How much range is used to reach New Location.
NoNavalMoveCount: Boolean; // Whether the move counts against naval movement activity limits.
NavalUnitCount: Byte; // The number of naval units in the moving stack.
UnitCount: Byte; // The number of units in the moving stack.
Units: TMovingUnitArray; // The ID numbers of the units in the moving stack.
end;
|
|
|
|
