Shannon V. OKeets -> RE: When? (5/31/2006 1:07:20 PM)
June 1, 2006 Status Report for Matrix Gamesí MWIF Forum
Accomplishments of May
With regret, I estimate that the graphics wonít be completed until September. After they are done, time will be needed to test the code with them all included. Once the program code is finalized (always a terrifying decision), Matrix Games will need 4-6 weeks at the back end to make the game ready for release, which is quite reasonable. For one of the games I did in the mid-1980's the company producing the game took 8 months after I had finished the code to release it. Argh! A little calculation leaves me looking at December as a release date.
Rob Armstrong has finished 85% of the bitmaps for the air and naval units. I currently have 1900 bitmaps for individual units out of roughly 2200 that will be included with the final product.
I monitored all the threads in the MWIF World in Flames forum daily. Members of the forum are helpful and supportive.
Beta testers continue working but would like me to correct fatal bugs they keep running into. Thatís not my highest priority, though I corrected a few of them.
Dan Hatchen and I have scheduled the middle of June for integrating his NetPlay code into MWIF proper.
Claes Insulander has made several passes at encoding the changes to the Scandinavia map worked out by Patrice Forno and Nils Andresen. His final version is expected to be done the first week of June.
Patrice took the work he had done, with help from Nils, for modifying the China map and posted it to the MWIF forum for review. The forum members gave this a very serious critique with over 150 posts and 1000 hits within the first 72 hours.
Terje and Fred Zimmerman have written descriptions for most of the naval units. Since there are over 800 named naval units, that is a lot of work. They expect to complete them all in June (!?).
Mike Wethington and I have scheduled mid-June for making a preliminary pass on the Playerís Manual. At Mikeís suggestion I purchased HyperSnap 6 - for creating better screen shots for display on the forum? No, in reality, it is for creating nice looking screen shots for inclusion in the Playerís Manual.
I remain in occasional email contact with Chris Marinacci.
I uploaded versions 1.01 and 1.02 during May. Version 1.01 included massive changes to the units, which are described in more detail below. It also contained modified definitions of the "short cut keystrokes". For example, <Ctrl> L loads a saved game. In version 1.02 the primary change was a major redesign of the unit review form. This form lets the player look at all the units in the game. You can think of it as a way to examine the counter sheets. As you scroll over each unitís thumbnail bitmap, the corresponding highest level of zoom bitmap is displayed along with the text writeup for the air and HQ units (all 600 provided by Greyshaft). The addition of the large bitmap and the text descriptions was the big change. The text descriptions for all the units are in simple *.txt files, so players will be able to make changes to these files in their personal copy of the game.
Map and Units
The map revisions for Scandinavia are being encoded and those for China are undergoing review and improvement in the MWIF forum. The European portion of the map is finished except for the Qattara Depression. Rob has sent those bitmaps to me, but I havenít gotten around to incorporating them into the map yet.
The units received most of my attention this past month. I added all the units from Cruisers in Flames and Convoys in Flames and generally tidied up the unit files. I had had a list of corrections that Patrice sent me in August, that I finally got around to making them all. There are about 2 dozen land units still missing (e.g., Chinese warlords), but that is small potatoes. As part of including the units from the 2 WIF add-ons, I created new unit types for ASW warfare, specialized submarines, and auxiliary cruisers (raiders). The number of different unit types in MWIF is now up to 70.
Placing the bitmap image correctly within the frame is a pain. There are variations due to: the original artwork, the transformation of that artwork to bitmap images by Rob, the different unit types, and (most annoying) the names for the units. I added the names to the counters for all the air and naval units which required some of them to have a second version of their name with delimiters for how it should be placed on the counter. In some cases there are four segments to an air unitís name: its official name (2 pieces) and its "also known as" name (2 pieces). Each piece has an assigned location on the counter. And, of course, that is different for each type of air unit (fighter, bomber, naval air, air transport, carrier based air). Designing a general purpose system for all of that took some time.
Then there is the fact that the naming of air units differs by country and even by branch of service within a country. Patrice sent me detailed rules about hyphens and blanks for how to write BF 109G6 Gustav and Macchi C.202 Folgore, for example. This seems like really trivial stuff, but if I get it wrong, there are players who will be annoyed by it forever. And it isnít that hard to get it right - just a little extra effort.
For Commonwealth member nations and all minor countries, I added the 3 letter abbreviations to the air and naval counters (e.g., CAN, NZL, GRE). This had already been done for the land units.
There are a lot of what I call generic naval units in the game. For example, the bitmap images for generic convoys, amphibious units, naval transports, and submarines are identical. Or at least they are within each country. I have 76 bitmaps that are not assigned to specific counters, but rather to unit types (by nationality). This lets the player create additional convoys and the program is able to assign a bitmap image to it. The whole arrangement required separate code from what is used for most of the unit bitmaps.
As part of this general review and spiffing-up of the units, I renumbered them all so the air units are between 1 and 2000, the land units between 2001 and 4000, the naval units between 4001 and 6000, and the special units between 60001 and 8000.
Lastly, I finally caved in and added rounded corners and shadows for the units. In the process of doing that I came up with an improved way to depict the status indicators. Both the shadowing and the status indicators need to be improved graphically and Iíll have Rob help out on that once he finishes the rest of the unit bitmaps. For status indicators CWIF used a row of contiguous rectangles across the top of the unit, which was both bland and hard to interpret. After some discussion with forum members I have now implemented 7 separate circles as the status indicators, with the 3 most important ones placed on the top of the unit (movement, disruption, and supply) and the 4 that are useful at times, but only infrequently, on the left side (combat, movement/combat, transportation, and damaged naval units).
What I gain by separating them is twofold: (1) the indicators only appear when there is something of interest, and (2) the position of the indicator conveys almost as much information as its color code. For example, most of the time a unit will have no status indicators at all. That makes for a cleaner display and adds emphasis for when they do appear. Similarly, a couple of the indicators are binary: yes/no (disrupted and damaged). More detail is provided by the non-binary supply and transportation indicators. The former only lights up when there is a problem with supply. The later only lights up when one unit in the hex is transporting another. Within each of those, however, color codes provide more specifics as to the unitís status.
What I have now are units that look good and are named as accurately as I could achieve. It is quite amazing to go through all 3000+ units in the game and see the individual high resolution counters. Rarely do 2 of them look alike. If anyone is interested, I am looking for someone to do write ups on the non-HQ land units.
Internet - NetPlay
I diagramed how the NetPlay code relates to the main MWIF program and sent those diagrams over to Dan Hatchen for review. After a couple of iterations we worked that all out. The focal point of our discussion was when one side (e.g., the Axis) should send information about decisions to the other side.
Let me explain the problem here, for it is rather interesting from a playerís point of view. In over the board play, a player will move a bunch of his pieces about on the board while the other player watches. During the course of that activity, the player might take a move back, either the one he just made or perhaps one he made several minutes ago. Usually this is permitted by his opponent, provided something consequential did not happen in the meantime. Often the most serious consideration is whether the player can remember (and his opponent agree) as to where each piece was at the start of the turn.
Now in MWIF, the program will know precisely where every unit started and also know without any doubt whether something consequential occurred. So, the issue now becomes one of communicating information. The internet portion of MWIF could do either (A) let everyone see everything that everyone does, or (B) limit what is shown to the opposing side while letting players on the same side see what everybody on their side is doing. I favor the latter as a way of enabling the players to plan and coordinate their moves. Indeed, I would like to expand on it a little - but not a lot - so that they could point out to players on their side moves they intend to do in future turns.
Internally, when a player moves a unit several hexes, the game records each hex in the game record log. That is, each hex moved has an entry #. Once the player places the unit in its final hex, the game sends the whole list of hexes it traversed over to the other players on his side. This is called a transaction and has an associated transaction #. When all the players on one side have completed moving their units, the program will send all the transactions across to the players on the opposing side. This is called interside communication and has an IC# assigned to it.
Built into the system is the ability for players to take back moves up until the point that a IC is sent to the other side. With accompanying text messages between players on the same side, coordinating moves shouldnít be a big problem. The possibilities for improving this subsystem for intraside communication, so the players can work out operational plans and long term strategies, is pretty much endless. Emphatically, I do not intend to be subsumed into the abyss of designing and coding anything elaborate for that.
Besides the revised unit form described above, I made some more changes to the Start New Game form. It is now possible to have multiple players play a game and assign them which major power groups they are playing (e.g., Japan/Italy). All that is missing is the bidding system for assigning players. CWIF had both of these features, but I have integrated the former into the main Start New Game form. The latter will eventually get a separate form but I am waiting on the Internet code before designing and coding it. Thatís because the bidding system will only be used when playing over the Internet.
I redid the Pascal component for the data concerning Players. This was to make it satisfy the needs for player data that Dan Hatchen listed for his NetPlay code.
I removed the title bars from some of the forms. That is the topmost bar that appears in almost all Windows applications. It contains the title and also the minimize, maximize, and close icons. By removing the title bars, the forms use less screen real estate which makes more of the map visible when using those forms. Of course, the functionality provided by the title bar has to be included in the form elsewhere (e.g., a way to close the form).
MWIF Game Engine
I have completed 3/4rds of the record definitions that correspond to the messages used by the game record log. They are tedious to do, and I get bored with doing them quickly. So I whittle away at it daily. When I get within striking distance of completing them, Iíll make a final push and close the book on that task. Once they are all completed, I will started incorporating them into the code that plays the game. They will be used when writing out what has happened in the game to the game record log. After that code has been tested and validated, I will start using them for passing messages over the Internet.
There are still a couple of lingering problems here that I need to fix.
Nothing new here.
Help System, Tutorials, and AI Assistant
I posted a request for advice/suggestions for the first two tutorials on the MWIF forum. A few responses but not a whole lot of interest. I envision the introductory tutorials containing two panels: left and right. The left panel, a screen shot from a game in progress, would be almost square and the right panel, text describing the screen shot, more like a column. Each screen shot will describe a game element with a tease about other game elements that are described in the next couple of screen shots. Ideally this design will keep the player reading by generating questions that can only be answered by reading the next item in the tutorial, or by going on to the subsequent tutorial. Eliminating boredom is crucial for the tutorials to provide a valuable contribution to the playerís enjoyment of the product.
Artificial Intelligence (AI)
Work on this has been in hiatus because I have been focusing heavily on the units, interface, and internet play.
I installed my new computer: Gateway, 3.8 GHz, 2GB RAM, and a second 19" flat screen monitor. The new monitor really made the old 19" flat screen look shabby, though they should be the same. The old one is from 2003 and it has a markedly yellow tint to its colors. The new one has whiter whites and brighter brights.
May summary: High resolution counters are almost done for all the units, which includes all the additional units and unit types from Cruisers in Flames and Convoys in Flames. Not enough progress on the Internet code or the revised game engine.
Tasks for June
Continue monitoring the forum threads.
Fix enough of the bugs so the beta testers can test Internet play when that code is written.
Map and Units
Finish the high resolution counters for all the air and naval units. Create a preliminary design for all the medium and low resolution counters. Install Claesí data files for the revised Scandinavian portion of the map. Start work on modifying the data files for the revised China map.
Thoroughly test the new random number generator (this task is at the bottom of the pile and I never get to it). Start cutting over from CWIFís messaging system to the game record log system.
Add bidding capability to the Start of Game Form so the beta testers can play one-on-one over the internet. Have Rob start work on the theme and color scheme for the player interface. That will involved the use of skins primarily.
Redesign of MWIF Game Engine
Continue work on the new MWIF Game Engine.
Software Development Tools
Develop a test program for Internet communications using Indy10 (multiple players over the Internet).
Incorporate the Indy10 code for the new design for the multiplayer system into MWIF. This requires replacing the CWIF calls to DirectPlay.
Finish defining the relationship between the air, naval, and land unit values. Continue working on defining the value of individual hexes and a line of hexes (i.e., a front line).
Historical Detail, Animations, and Sound
Start listing all the places the program will use historical video footage, sound, and music. Begin fleshing out the content for the first half dozen tutorials with advice from forum members.
Help System, Tutorials, and AI Assistant
Set up forms dedicated to viewing the sequence of play, so they can be used later as an index/table of contents into the context sensitive help files.
40 minute walk every day.
June summary: Make the system for playing over the Internet work. Build on the work for the high resolution counters to create their medium and low resolution counterparts. Continue with creative cartography.