RE: When?

RE: When? (Full Version)

All Forums >> [New Releases from Matrix Games] >> World in Flames

Message

wargameplayer -> RE: When? (1/6/2007 10:19:38 PM)
If it's been worked on for 5k hours and its been several years. and still 3k to go I'd guess its about 18 months away. Have you thought about outsourcing some of the more mundane coding to India? That way the game would come out a lot faster and probably cheaper. Heck I'd invest in some development dollars since it's such a great game and I've always wanted to see it in computer format. quote: Some of us work 60+ hours a week just like Steve. I strongly doubt write-ups are delaying production of the game. Those who have the spare time are donating. Throwing insults contributes nothing positive, and doesn't even cast the game in a good light. All prospective players of the game should have a chance to comment regardless of the decisions made. Being defensive on behalf of Steve and/or throwing insults is non-productive. _____________________________

Shannon V. OKeets -> RE: When? (1/6/2007 11:27:24 PM)
quote: ORIGINAL: wargameplayer If it's been worked on for 5k hours and its been several years. and still 3k to go I'd guess its about 18 months away. Have you thought about outsourcing some of the more mundane coding to India? That way the game would come out a lot faster and probably cheaper. Heck I'd invest in some development dollars since it's such a great game and I've always wanted to see it in computer format. quote: Some of us work 60+ hours a week just like Steve. I strongly doubt write-ups are delaying production of the game. Those who have the spare time are donating. Throwing insults contributes nothing positive, and doesn't even cast the game in a good light. All prospective players of the game should have a chance to comment regardless of the decisions made. Being defensive on behalf of Steve and/or throwing insults is non-productive. _____________________________ I cowrote a wargame in assembler with a very close friend in the mid-1980s. And obviously I have worked on numerous other programming projects involving a team of programmers. This project doesn't lend itself to that very well. Currently, I am rewriting existing code, turning it into a more structured design. That requires separating the variables and routines into different modules: standard Windows program application tasks, Player Interface, Game-in-Progress variables (date, turn, phase, impulse, subphase, phasing player, ...), Game Control (Sequence of Play and transitioning from one phase to the next), Simulation Control (updating the map and unit variables, etc.), Game Record Log (for replay), and so on. Since I started with existing code that had these variables/functionality intertwined, it really is a one-person task to break them into separate code entities. If I had my best friend working alongside me everyday, then perhaps we could work out a division of labor where the overhead of communication did not wipe out the benefit of having 2 people work on the project. But he lives in Pennsylvania and has a full time job supporting his family (he needs that regular paycheck). My point here is that very close communications would be required and there would be a lot of time spent/lost simply telling each other what is being done. One reason the original code I received had things intertwined is that there is enormous interaction between elements of MWIF: the player, the operating system, and the simulation. I absolutely have to have them separated to add any of the capabilities required in my contract with Matrix: Internet, PBEM, AI Opponent. Over the last year and a half I have been able to make changes to support the new graphics for the map and units, and many other changes, but doing so interduced "hard to track down" bugs because of the program structure. The redesign I am working on now should alleviate those problems.

marklv -> RE: When? (1/17/2007 3:04:12 PM)
The way I look at it, I think there is another 18 months left of work - the 3,000 hours will quickly become 4,000. I can't see the game released before the first quarter of 2009 at the earliest. The problem with project estimates is that they are invariably optimistic - I speak from experience as an IT manager. The key thing is to get this thing right. I have been massively disappointed by other WWII grand strategy games like Strategic Command II, which took seemingly forever to develop and then turned out to be a load of crap. I would like World in Flames to be nothing short of the best strategy game ever created; a game that you would never tire of playing. If this means another 5,000 hours of work, so be it. I would rather wait years for a masterpiece than having a piece of junk right away.

Shannon V. OKeets -> RE: When? (2/2/2007 3:52:45 AM)
February 1, 2007 Status Report for Matrix Games’ MWIF Forum Accomplishments of January Project Management Every month, at a minimum, I review the project plan and I am still on track with the schedule from last October. A few tasks have switched around though, for instance, Rob gave me a lot of map segments in December and very few in January. Communications Rob Armstrong was on vacation for most of January (it’s summer in Australia), so he only completed two map segments: northern and southern Canada. 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 land unit writeups continues, albeit slowly. No communications this past month with: Chris Marinacci, Harry Rowland, Dan Hatchen (NetPlay), or Peter Kanjowski (Yahoo WIF Discussion group to clarify outstanding WIF rules questions). No activity with the AI Opponent team, though the forum members helped with the strategic plan for the USSR defending against Barbarossa. Beta Testing I have been able to fix some bugs identified by the beta testers as part of the redesign of the game engine. Once I get the redesign of the game engine tested some more, I’ll upload version 4.00. Units Other than some new unit writeups, there has been no new work on the units. The code and data are stable at this point. Map I processed the coastal and river/lake bitmaps that Rob sent me and incorporated them into the current version of MWIF. Then Patrice took those images and made corrections to the map data they revealed. Rob still has 4 map segments left to do: the USA, Central America, and South America (2 segments). We are definitely in the home stretch on finishing the map! I have had a task on my project schedule that it appears I will not have to do. In order to get all the bitmaps to fit within the constraints imposed by the Windows operating system on bitmap ‘resources’, I expected to have to write a pagination routine for the coastal bitmaps. However, at this point we have 4320 coastal bitmaps loaded the and program runs without any complaints (i.e., no “insufficient memory” messages). It is very close to tapping them out though, because I do get that message when I try to run it from within the Delphi Integrated Development Environment (IDE). Apparently the Delphi IDE has its own demands for bitmap resources and in combination with the program, the available capacity is exceeded. I do not believe this has anything to do with hardware memory on a system, but instead is simply some Windows imposed limitation created by poor programming of the operating system. So, the full map would use 5010 coastal bitmaps. There are a whole lot of other bitmaps, for the units in particular. Nevertheless, the biggest demand on capacity are the coastal bitmaps. To avoid having to write a pagination routine (where the least frequently viewed coastal bitmaps and kept on disk, but not in main memory), I intend to trim the map. Specifically, the top 15 hex rows: from 195 hex rows to 180. Doing this will remove 681 coastal bitmaps from the 5010 so the map would only need 4329. This makes the map 360 hexes wide by 180 hexes high. By the way, the mathematician in me exults at the beauty of the numbers 360 by 180. From the point of view of playing the game, the top 15 hex rows contain absolutely nothing. I have posted this to the forum members and they unanimously agreed that trimming the top 15 rows of the map would have no effect whatsoever on game play. Of course they would like the map to display the larger view of the world. For now, I am holding off on a final decision on this. I want to get the rest of the coastal bitmaps from Rob and see where the upper limit actually is. Then I want to leave some unused bitmap capacity as slack for future contingencies. I’ll keep as much of the map as I can, but not having to write the pagination code makes me real happy - so trimming the map is definitely on the agenda. Forum members have been asking if they will be able to obtain copies of the maps in printed form, and they are willing to pay extra for them. In response, I have investigated this possibility. The full map would be 11' 2" high and 18' across if done with the same size hexes as the WIF Final Edition paper maps (each hex is 19/32" across and 7/10" high). The top 15 hex rows could be trimmed with no loss, but that only brings it down to a height of 10' 4". There are many ways to segment the world map to reduce the total surface area (by eliminating a lot of the pure ocean hexes). It might be feasible to define both a one piece world map and a set of map segments and offer them for sale. What the players envision doing is playing WIF with a paper map and cardboard counters, using the MWIF world map (because it has a unified scale throughout the world - and looks pretty). I expect there would also be some interest in a world map at reduced scale. For example, using 1/4 size hexes would result in a world map that is 5' 2" high and 9' across (.3" by .35" hexes). 1/16 size would be 2' 7" high and 4' 6" across (roughly 1/6" by 1/6" hexes). Either might be suitable for mounting on a wall. To this end, I have talked with Larry, my brother-in-law, and he has offered to arrange for samples to be printed by a friend of his in Philadelphia who prints large advertising JPG files onto canvas for wrapping around buses. So, I took 68 screen shots of 1/3 of the world, a full north-south segment, from Iceland to the middle of India. It covers all of Europe, Africa, and the Middle East, and Russia well past the Urals. Patrice assembled the 68 BMP files into a single BMP file and I now have it as a zipped JPG (20MB). There is no hurry on printing this, since is it only part of the world map, and it’s just a trial run to see how things turn out - plus work through the logistics of communications and shipping. Scenario Information I made a few modifications to the code for processing scenario data to support new unit types. In reality this code is solid now and shouldn’t need any more changes. I have scheduled coding the data for the remaining 3 scenarios in March and April. Game Interface Not much new here. I have 160 hours of work on the player interface scheduled for April. MWIF Game Engine I have completed designing the overall structure of MWIF. It took me a day and a half just to write it up. Almost all the code is now written and I have been testing and debugging it for the last 2 weeks. However, this is ‘just’ a calling sequence, the detailed aspects of changing phases and subphases and processing player input already existed and hasn't changed very much. So you can think of this as a new superstructure within which the individual processes perform as previously. What the new design accomplishes is: ∙ it reduces the 170+ calls to check for Internet communications to one. ∙ it reduces the 200+ calls for changing game phase/subphase to one. ∙ it centralizes the decision making for changing between phasing and non-phasing players; previously it was in 100+ places. ∙ it enables decision making by local and remote players, AI opponents and AI assistants, as well as local and remote MWIF programs. By remote I mean both Internet and PBEM play. eMWIF is a small random number generator program to be hosted by independent third parties to remove the possibility of cheating during PBEM. ∙ it enables game replay. The only thing I haven't thought through here is when a player starts with a tutorial and then uses that as the jumping off point for a game. It shouldn't be too hard to incorporate that into this design but I am waiting until after I have created some of the Interactive Tutorials so I understand better what is involved. There are 78 phases in the game but many more phase transitions. For instance, the code related to naval combat has a lot of self-references with loop back possibilities (naval units aborting from combat that are intercepted on their way back to port and engaged in another combat), while more naval movements or combats are still pending. A queue of all the naval events that remain has to be maintained and eventually processed until it is empty.. What I have done is commented each phase transition so I can find them all by simply searching on the word 'transition'. In most cases I know precisely both the current and the future phase. However, there are times when the transition is to "Old Phase" which is ambiguous. I have also cut out the code that sends messages (over the Internet) to other players about decisions and placed it into one central location. I have merged the diverse routines for end of player decision making and changing phase into five case statements: (1) to determine the next major power or phase, (2) to check if a phase should be skipped, (3) to clean up from the previous phase, (4) to prepare for the new phase, and (5) to execute the processes associated with the new phase. The first step handles those situations where multiple players act simultaneously. Often the phase does not change then, but instead a different major power becomes the decision maker (e.g., during setup). Internet - NetPlay This got some attention in that I have set up the calling sequence within the main structure for sending and receiving messages over the Internet. Right now they are mostly “stub ends” with the guts of the code either missing or disconnected (Dan Hatchen wrote a lot of the code for this which needs to be connected). CWIF Conversion I have created, or expanded enormously, new modules: CentralControls, GameControls, MessageControls, PlayerInterfaceControls, and GameInProgress. While three of these are less than 5 pages each, GameControls is now 30 pages and GameInProgress is 80. These routines were located in different modules in CWIF. As part of the redesign, I have made the structure of the modules/files parallel the structure of the game engine. That makes it easier to analyze the code. I have been replacing CWIF’s code for communicating game events (changes in the simulated world) to remote players. Instead, I am creating game record log entries and writing them out to the game record log on disk. These same entries are used for transmission over the internet. The process is: game event occurs locally –> record log entry –> string message sent –> Transmission –> string message received –> record log entry –> game event applied to remote game state. Most of this code is already written and I am grinding my way through finishing the first and last steps in the above sequence.. The beauty of this is that the same record log entry is used internally when the event occurs, so the record log entry is applied the same way on both the sending and the receiving computers. This works for not only Internet play and PBEM but also for AI Opponents and AI Assistants, and even for game replay. Let me make this clear, the 462 definitions for game record log entries are: (1) written out to disk, (2) read from disk for game replay, (3) sent and received over the Internet, (4) sent and received via email, (5) written by the AI Opponent and Assistant when they make decisions, and (6) used to effect changes in the simulated world. The last is the most important of course. By standardizing on the 462 different formats, I am able to use them everywhere and not worry whatsoever about the current mode of play when updating the simulation. Saved Games I made a few changes here related to moving variables from the Main Form module to the Game-In-Progress module. Player’s Manual Nothing new. Help System, Tutorials, and AI Assistant Nothing new. Artificial Intelligence (AI) Nothing new. Other I am firming up plans to meet with Patrice in Avignon in late May or early June. At that time I will be visiting my in-laws in Geneva (Switzerland) and we’ll visit Avignon for a few days. Avignon is less than an hour’s drive from where Patrice lives. ==================================================================== January summary: In the final stretch on the bitmap graphics for the map. Most of the game engine redesign was completed and its role as the centerpiece for executing all modes of play transformed from theory into code. ==================================================================== Tasks for February Communications Continue monitoring the forum threads. Map and Units Continue adding coastal and river/lake bitmaps as I receive them from Rob. [est. 10 hours] Redesign of MWIF Game Engine Continue refining the superstructure of the MWIF game engine. [est. 40 hours] CWIF Conversion Convert from CWIF style internet formats to Game Record Log Formats. [est. 120 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] Game Interface Get the bidding capability to function cleanly and modify other aspects of the Player Interface to support NetPlay. [est. 20 hours] NetPlay Code interface between Game Record Log and NetPlay. [est. 20 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 (as part of the debugging process for 3.00). [est. 30 hours in March & April] AI Opponent Nothing planned for February or March. Player’s Manual Nothing planned for February or March. Historical Detail, Animations, and Sound Nothing planned for February or March. Help System, Tutorials, and AI Assistant Continue work on the Introductory Tutorials. [est. 20 hours in March] ================================================================ February summary: Short month, but I hope to finish both the map and coding for the redesigned game engine. ================================================================

jesperpehrson -> RE: When? (2/3/2007 1:15:19 AM)
quote: ORIGINAL: Shannon V. OKeets I am firming up plans to meet with Patrice in Avignon in late May or early June. At that time I will be visiting my in-laws in Geneva (Switzerland) and we’ll visit Avignon for a few days. I will wave to you from our rented cottage in Fourqualqier (Haute-Provence). You will probably drive past us going to Switzerland. Come in for a glass of wine perhaps?

Shannon V. OKeets -> RE: When? (2/3/2007 2:20:27 AM)
quote: ORIGINAL: capitan quote: ORIGINAL: Shannon V. OKeets I am firming up plans to meet with Patrice in Avignon in late May or early June. At that time I will be visiting my in-laws in Geneva (Switzerland) and we’ll visit Avignon for a few days. I will wave to you from our rented cottage in Fourqualqier (Haute-Provence). You will probably drive past us going to Switzerland. Come in for a glass of wine perhaps? If you want to make arrangements to meet, let me know. When will you be there ("rented cottage")?

jesperpehrson -> RE: When? (2/3/2007 5:21:24 PM)
We will be there in late May but I will let you know when everything is 100% certain. But of course it would be great to share a bottle of wine with you!

geozero -> RE: When? (2/4/2007 4:41:03 AM)
Whatever happened to the demo they had out a few years ago? It looked like it worked fairly well... I still have it.

Shannon V. OKeets -> RE: When? (2/4/2007 4:53:13 AM)
quote: ORIGINAL: geozero Whatever happened to the demo they had out a few years ago? It looked like it worked fairly well... I still have it. A modified version of that is being sold by Australian Design Group (ADG). I am not familiar with the particulars, though the ADG website should describe what it includes.

msrt59 -> RE: When? (2/5/2007 12:06:37 PM)
If you pass near Reims going to Avignon i could exchange a botlle of Champagne for a beta version you know ?

Shannon V. OKeets -> RE: When? (2/5/2007 9:45:12 PM)
quote: ORIGINAL: msrt59 If you pass near Reims going to Avignon i could exchange a botlle of Champagne for a beta version you know ? Ah, thanks for the offer but Reims is a bit out of the way for a trip from Geneva to Avignon and back. N'est-ce pas?

Jimm -> RE: When? (2/6/2007 12:12:54 AM)
Could be a European magical mystery tour, the way it sounds! Your liver might not survive unscathed though.

38special -> RE: When? (2/26/2007 4:22:01 AM)
I read through this entire thread and lost track of When the game is due. The last thing, I think, I read was 1st qtr 07? But some of the last posts seem to indicate Fall 07.[&:]

Mziln -> RE: Old WIF Player Saying Hello and Thanks (2/26/2007 5:28:42 AM)
quote: ORIGINAL: Shannon V. OKeets I had trouble logging into Matrix this morning or I would have posted this earlier. ------------------------------------------------------ December 1, 2006 Status Report for Matrix Games’ MWIF Forum Accomplishments of November Project Management I did my first detailed project plan in mid-October and have more or less kept on track against that to date. However, my estimation of my time required to complete MWIF product 1 is over 3300 hours. Roughly, the big items are coding/modifying: Player Interface and the AI Opponent (~800 hours each), Game Engine and Rules (~400 hours each), and the Tutorials, PBEM, and Documentation (200 - 300 hours range for each). These are broken down into finer detail, with everything rounded off to units of 10 hours. Altogether, I have 70 items on the project plan spreadsheet with what gets worked on when scheduled by month. This is only one of 5 task lists I maintain. The others are: reported bugs from versions 2 and 3, programming to-do list, and project tasks. The last deals with the project overall and includes people other than myself, while the other 3 are specific to programming. The programming to-do list priorities the bugs to be fixed and interleaves new items (e.g., new optional rules). At this point I am the bottleneck in the project schedule, but there doesn’t seem to be much more I can do about that. I delegate tasks whenever possible and then step aside, taking care to not micro-manage items I have given to others. Of course, this still requires staying informed of how things are going and providing assistance whenever it’s needed. Still, management, and all that implies, places few demands on my time. I figure it is only 10 - 15 %, and I include in that all the report writing and communications to forum members and other members of the MWIF project team: email, posts, status reports, plus a few rare phone calls. I calculate I have spent around 5000 hours on MWIF since I started in July 2005. Someone in the forum wasn’t sure whether I was working full time on MWIF. Well, I am using 9 productive hours a day as my metric for scheduling tasks, with no days off. By productive, I mean after the 10 -15% for management has been accounted for. In reality I work 10-12 hours a day on MWIF. That lets me fit in some barbershop singing, but otherwise I am a recluse: me and MWIF. My wife keeps me fed and points out lapses in personal hygiene. This works out to me completing my tasks in December 2007. David Heath translates that to a release at Origins in July 2008. Why so much longer than originally thought? Mostly it is a lack of documentation. The programming tools I am using explore all the possible ways to do poor documentation: none, incomplete, misleading, obsolete, written by a non-English speaker (Theme Engine - Russian), and, most common, frequent use of words with special meanings that are never defined. For example, every so often, while I am entering text comments into the source code, the compiler crashes with the error message: “Target of an invocation failed.” Reboot and start again. I also lost 4 days last week before I figured out that adding a directory to the search path for the compiler was resulting in it ‘automatically’ recompiling all the Theme Engine modules - incorrectly. I removed the directory from the search path and dozens of problems disappeared. When I write new code, programming is easy. When I need to go into the CWIF code and make changes, extreme care is required or things can go wrong without me knowing. Tracing the repercussions of changes, especially when it involves the Windows User Interface routines is time consuming. Failure to understand exactly what is going on is even worse and can lead to a great loss of time later spent finding and fixing bugs. You now know most of what I know about the MWIF project schedule. Communications Rob Armstrong provided new coastal and river/lake bitmaps for about 2/3rds of Russia, the Caucasus, Mid-East, India, Burma, China, Malaysia, Australia, New Zealand, and the Solomon and Caroline Islands. I monitored all the threads in the MWIF World in Flames forum daily. Work on the unit writeups continues, with a few new volunteers. Chris Marinacci sent me some bug corrections he has made to the version of CWIF being sold by ADG. I hope to be able to reciprocate from time to time. Beta testers sent me numerous reports on the versions 3.02, 3.03, 3.04, 3.05, and 3.06 I uploaded for them during the month. No activity with the AI Opponent team, though the forum members are helping with the strategic plan for France. No word from Patrice and Peter Kanjowski about their project on the Yahoo WIF Discussion group to clarify all outstanding rules questions. Dan Hatchen (I hope) is waiting on me to install what he has already done on NetPlay. Beta Testing I have been able to fix a dozen or so bugs identified by the beta testers but there are still major difficulties, even playing Barbarossa. More on my attempts to iron out the fatal crashes below. Units Other than some new unit writeups, there has been no new work on the units. The code and data are pretty stable at this point. Map I processed all the coastal and river/lake bitmaps that Rob sent me (see the list given above) and incorporated them into the current version of MWIF. Patrice took those images and made corrections to the map data they revealed. He also has been going gang-busters on adding new names/labels to the map. Once the detailed coastlines, rivers, and lakes have been drawn a lot of touch-up work is needed. Part of that is to place the map icons in reasonable places (keep the factories out of the ocean), reroute the rail lines through each hex so they do not cross water, and place the names/labels so they are both legible and do not cover important game elements. Somewhere in the middle of the month I provided both Rob and Patrice with the utility program I use to cut Rob’s large coastal bitmaps into individual hexes and generate the river/lake quasi-bitmaps. I included documentation on how to run the program. Patrice now runs it so he can edit the map data files without waiting on me to process them. The coastal bitmaps are 50% complete and the river/lake bitmaps are 55% complete. Scenario Information I learned that the version of the WIF FE unit setup information I had been using was obsolete. I now have the correct one and I will ask the beta testers to proofread the scenario setup code to identify needed changes. Most of the mods have to do with Cruisers in Flames and Convoys in Flames. CWIF Conversion Problems popped up with the pop-up unit menu. Since I wanted to do it anyway, I restructured this earlier than I had planned. The routines that process the unit menu items are now in a separate module and the main program module is down to a svelte 11,200 lines of code. Unit menu items are: split/merge convoys, breakdown/reform units, place units in sentry mode, and dozens of others. I began work on a new system to route resources to factories. This is needed by the AIO but it will also help players route resources and save oil points. The design is 95% done and I will use a similar one for determining supply for units. Basically calculating supply status for units is the same routing problem but with different rules. Game Interface Most of my time this month has been spent working on bugs in the player interface identified by the beta testers. While working on that I kept coming across anomalous events, some of which were “now it’s a problem, now it isn’t”. Eventually I began to suspect that the software libraries were out of sync so I went back to bedrock. I uninstalled all the software libraries I was using, including the Delphi compiler itself. I then reinstalled everything from scratch. As is usual in performing this task, it required several days full of profanity and detailed discussion on the ancestry of the people who design, code, and document software packages. This did result in identifying some systemic problems which I was able to correct without too much trouble. More importantly, I am no longer worrying about the code base with which I am working - or at least not as much. Internet - NetPlay I made some progress on this but had to stop work in order to debug versions 3.0x. MWIF Game Engine I also made good progress in writing events out to the game record log. This was much easier than I expected and should be completed quickly once the rest of the game engine redesign is complete. Saved Games I haven’t tested this recently. I have no bugs listed for this code at the present. Player’s Manual Nothing new. Help System, Tutorials, and AI Assistant I did a little more work on the Introductory Tutorials but I need Rob to redo the Weather bitmap overlays. I also need to get the code that determines supply corrected. Artificial Intelligence (AI) Started detailed work on the strategic plan for France. Other Our Xmas show is coming up next week. We have been practicing a lot plus we have several other paid gigs scheduled. During the holidays we get to perform at parties which helps the chapter treasury. I have also found a new baritone for our quartet. We lost our previous baritone when he went off to college in western Massachusetts in August. ==================================================================== November summary: Good progress on the bitmap graphics for the map. Too little on fixing bugs and NetPlay. ==================================================================== Tasks for December Communications Continue monitoring the forum threads. Beta Testing Fix more bugs, so that version 3.00 can play through the entire Barbarossa scenario cleanly. [est. 60 hours] Map and Units Continue adding coastal and river/lake bitmaps as I receive them from Rob. [est. 20 hours] CWIF Conversion Thoroughly test the new random number generator. [est. 1 hour] Game Interface Get the bidding capability to function cleanly and modify other aspects of the Player Interface to support NetPlay. [est. 20 hours] Redesign of MWIF Game Engine Continue refining the superstructure of the MWIF game engine. [est. 45 hours] Software Development Tools Finish replacing all the old components with new ones from JEDI (as part of the debugging process for 3.00). [est. 10 hours] NetPlay Incorporate the Indy10 code for the new design for the multiplayer system into MWIF. [est. 100 hours] AI Opponent Finish the Strategic plan for France and begin work on the same for China and Italy. [est. 15 hours]. Player’s Manual Nothing planned for December. Historical Detail, Animations, and Sound Nothing planned for December. Help System, Tutorials, and AI Assistant Continue work on the Introductory Tutorials. [est. 10 hours] Other Perform in the Xmas show - as one of the anonymous reindeer/basses in the back row. Start work on the script for the Spring show. ================================================================ December summary: Debug version 3.00. Continue mass production of the coastal and river/lake bitmaps. Implement NetPlay. ================================================================

38special -> RE: When? (2/26/2007 11:03:37 PM)
So that means July - August 08!!!! Oh the inhumanity of it all!! [:(][:(][:(]

composer99 -> RE: When? (2/27/2007 1:23:11 AM)
Could be worse. No one could be working on it at all. [:D] But yes, for all of us [edit] (possibly overeager?) enthusiasts it is sore news.

Shannon V. OKeets -> RE: When? (3/1/2007 5:56:59 AM)
March 1, 2007 Status Report for Matrix Games’ MWIF Forum Accomplishments of February Project Management I have lost about 1 week against the schedule I created in October, but I had allowed for 3 weeks slack/contingency so I still plan to finish the programming for MWIF before the end of 2007. Communications Rob Armstrong finished the rest of the coastal and river/lake bitmaps for the world. There will be a few touch-ups, but those are only minor details. 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 appears to be at a standstill. Though there is no hurry on this item, I would like to see a dozen or so new writeups every month, since every one done is an addition to the historical ‘heft’ of the final product. No communications this past month with: Chris Marinacci, Harry Rowland, Dan Hatchen (NetPlay), or Peter Kanjowski (Yahoo WIF Discussion group to clarify outstanding WIF rules questions). No activity with the AI Opponent team, though the forum members helped with discussions on game play (e.g., the use of offensive chits). Beta Testing I have created more bugs than I have fixed this past month due to my redefinition of how unit locations are stored internally, which is described in more detail below. Units Other than a couple new unit writeups, there was no work on the units. That code and data are stable. Map I processed the final coastal and river/lake bitmaps that Rob sent me and incorporated them into the current version of MWIF. Then Patrice took those images and made corrections to the map data. It now looks like I will only have to trim 2 or 3 hex rows from the top of the map to avoid having to write a pagination routine for the coastal bitmaps. However, I will delay that task for several months in the hopes that some way occurs to me for squeezing in the entire map. The final counts were 5054 coastal bitmaps and 7173 river/lake bitmaps. I was surprised that the coastal bitmap count was so high (I expected it to be 5010) though the increase may be due to the corrections to the map data that were needed. I talked to David Heath about printed copies of the map, and he said that while not especially important it was worth investigating. In talking to Larry (my brother-in-law) I learned that there are at least two types of material on which the map could be printed. One is a Mylar-type sheet which would be rather flimsy and would have to be mounted onto something (e.g., a wall or cardboard). A second choice would be a canvas material which has a thin plastic coating on its surface onto which the map would be printed. The canvas is more substantial and would be much preferred by players I expect, but it has the disadvantage of only being available in a maximum width of 48 inches (but effectively infinite length). The Mylar could be created in larger widths - they wrap buses in the stuff for advertisements. I’ll keep working on acquiring a sample printed copy of the map. 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 still scheduled for March and April. Player Interface Not much new here. I have 60 hours of work on the player interface scheduled for March and another 130 for April. I did insert comments for a lot of the code related to naval movement this past month, including naval interceptions, deciding whether to stop or fight through after being intercepted, abort from combat, forced rebasing, and so on. There are separate forms for the stop/fight through decision, dropping off units, loading/unloading naval transports, and other aspects of naval movement. In my project schedule, review and revision of those forms/decision processes comes under the category of Player Interface. MWIF Game Engine I inserted the code to write out several dozen new Game Record Log entries to disk. This involved replacing the CWIF code for writing messages to the Internet with code to both write and execute decisions as Game Record Log entries/messages. These are coded as SetGRL and UseGRL calls. The first formulates the GRL entry/message and the second executes the decision. I think of these as SetGRL being the providence of the player interface, as the ‘local’ player makes decisions, while UseGRL implements the player’s decision against the current game state, bringing it up-to-date. This is the real nitty-gritty of maintaining the simulation in accordance with RAW. I completed all the routines related to moving units to and from the 13 off map locations (those are discussed below). Internet - NetPlay The code for processing messages received over the Internet (or via PBEM) is less than a dozen lines. It simply calls the same routines that the sending program executes, using the same ‘messages’. One central processing routine calls UseGRL (Game Record Log) and branches on the message ID for the game record log entry. That is a single case statement with 462 enumerated values. CWIF Conversion I have redefined how unit locations are stored internally by the program. CWIF primarily used Column and Row but then expanded the meaning of column to include scrap pool, force pool, conquered pool, and so on. Row also had a different meaning for when a unit was in a sea area. I found this very difficult to work with, since the variables Column and Row did not always mean a column and row on the map. Likewise, the variable Hex sometimes had non-intuitive meanings. More importantly, this structure made it very difficult to display units in the sea area section boxes, which I believe to be essential. So, I finally bit the bullet and changed the code to guarantee that Hex, Column, and Row always refer to a hex on the map or a hex coordinate. This has taken me most of the month of February and I still have a lot of loose ends to clean up. In the process of making thousands of changes, I investigated a lot of code I had not looked at in detail before and inserted comments throughout. In particular, most of the routines related to moving units are now commented: for air, land, and naval movement on map and unit moves in general to and from the map and the off-map pools. Here is the documentation I wrote (for myself) so I could keep everything straight in my head. The new storage structure is a TUnitLocation record, which contains: ∙ UnitPlace: TUnitPlacement; ∙ Column: Integer; // Only used when UnitPlace = upOnMap ∙ Row: Integer; // Only used when UnitPlace = upOnMap ∙ ProdTurn: TTurn; // Only used when UnitPlace = upProduction Each unit’s UnitPlace variable has one of these mutually exclusive values: upOnMap, upMoving, upSetup, upReserve, upTransferPool, upProduction, upConstruction, upRepair, upForcePool, upFutureForcePool, upBrokenDown, upInternment, upConquered, upScrapped, upRemoved . Other than the first value, these are all off-map locations and any unit in an off-map location is not visible on the map. Instead, they can be viewed using one of two information forms: Pools and Units Review. All units on the map are visible, including those in sea areas. The last sentence is a major change from CWIF. A TUnitPlacement record is the minimal amount of information needed for locating a unit in the game. However, there are additional variables maintained by the program to facilitate coding and speed of execution. Important ones are contained in a TUnitLocationFull record: ∙ UnitPlace: TUnitPlacement; ∙ Column: Integer; // Only used when UnitPlace = upOnMap ∙ Row: Integer; // Only used when UnitPlace = upOnMap ∙ ProdTurn: TTurn; // Only used when UnitPlace = upProduction ∙ OnMap: Boolean; ∙ AtSea: Boolean; // OnMap is true and the unit is in a sea area ∙ SeaAreaID: TSeaAreaID; // Only used when AtSea is true ∙ Section: TSectionRange; // Only used when AtSea is true; values are 0 - 4 ∙ OnLand: Boolean; // OnMap is true and AtSea is false In addition, the program maintains the following boolean values for each unit in the game: OnMap, AtSea, OnTheMove, InSetupTray, InReserve, InProduction, InConstruction, NeedsRepair, InTransferPool, InForcePool, InFutureForcePool, BrokenDown, Interned, BeenConquered, BeenScrapped, BeenRemoved. MapStacks is a table of TMapStacks with size MapColumns (360) by MapRows (195). MapStacks is used when drawing the map to determine which hexes contain units and what those units are. It is obviously also used whenever the player is moving units on the map. Within each sea area there are 10 hexes designated as sea area boxes. Units in a sea area are only displayed in one of those 10 hexes. By translating the hex column and row number to a sea area and then to a section within the sea area, the program ‘knows’ precisely which sea area section each unit is occupies. Though the table MapStacks always exists, each TMapStacks within the table are only instantiated if there is a unit in the corresponding hex (i.e., Column and Row). Whenever a unit is placed in a MapStack, a check is performed to see if the MapStack needs to be created (i.e., there are no units in the hex). Whenever a unit is removed from a MapStack, a check is performed to see if the MapStack should be deleted (i.e., if it is now empty). Note this system avoids wasting memory for hexes that never contain units (i.e., all sea hexes that do not contain a sea area box). For each off map location a separate list of units in that off map location is maintained. Those lists are: MovingStack - TMovingStack SetupPool - TUnitStack ReservePool - TUnitStack ProductionPool - an array of 6 TUnitStacks ConstructionPool - TUnitStack RepairPool - TUnitStack TransferPool - TUnitStack CommonForcePool - TUnitStack FutureForcePool - TUnitStack BrokenDownPool - TUnitStack InternmentPool - TUnitStack ConqueredPool - TUnitStack ScrappedPool - TUnitStack RemovedPool - TUnitStack Saved Games I made a few changes here related to the changes to unit location. Player’s Manual Nothing new. Help System, Tutorials, and AI Assistant Nothing new. Artificial Intelligence (AI) Nothing new. Other I delivered 18 singing Valentines on February 13th/14th which is a hectic way to spend a day but really rewarding when you see the smiling faces of the recipients. We score a delivery as a success if the recipient cries - we had 50% cry this year. ==================================================================== February summary: For all intents and purposes, the map is done. What a relief! I made good progress in understanding and revising the unit movement routines. ==================================================================== Tasks for March Communications Continue monitoring the forum threads. Map and Units Prepare a list of touch-ups for Rob. Scenarios Add data for the 3 remaining scenarios. [est. 10 hours] Redesign of MWIF Game Engine Refine the MWIF game engine. [est. 40 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. 60 hours] NetPlay Get the bidding capability to function cleanly and modify other aspects of the Player Interface to support NetPlay. [est. 20 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. 30 hours in April] AI Opponent Nothing planned for March or April. Player’s Manual Nothing planned for March or April. Historical Detail, Animations, and Sound Nothing planned for March or April. Help System, Tutorials, and AI Assistant Continue work on the Introductory Tutorials. [est. 20 hours] Other I now have tickets for traveling to Geneva, Switzerland in May (to visit my in-laws & Patrice) and for traveling to Philly in April (funeral). ================================================================ March summary: I should finish coding the changes to unit locations and the associated unit movement routines. Then I can give the beta testers 4.00 and start work on redoing how unit supply is calculated. Last in line for the month is work on NetPlay. ================================================================

zoc_trooper -> RE: When? (3/4/2007 9:33:28 AM)
Thanks for these updates! I've rarely seen such thorough or regular communications from a development team. I left behind a game of World in Flames that I'd been playing for the last three years in order to start a two year assignment in Yemen. I really look forward to having a computerized WiF for PBEM. Thanks for all the hard work! It's definitely appreciated. Zoc_Trooper

ess1 -> RE: When? (3/5/2007 4:55:32 PM)
quote: ORIGINAL: zoc_trooper Thanks for these updates! I've rarely seen such thorough or regular communications from a development team. I left behind a game of World in Flames that I'd been playing for the last three years in order to start a two year assignment in Yemen. I really look forward to having a computerized WiF for PBEM. Thanks for all the hard work! It's definitely appreciated. Zoc_Trooper I did a spell in the Radfan whilst serving in the British Army. Good luck & watch out for the scorpions... etc[;)]

Neilster -> RE: When? (3/6/2007 12:14:33 AM)
quote: ORIGINAL: ess1 quote: ORIGINAL: zoc_trooper Thanks for these updates! I've rarely seen such thorough or regular communications from a development team. I left behind a game of World in Flames that I'd been playing for the last three years in order to start a two year assignment in Yemen. I really look forward to having a computerized WiF for PBEM. Thanks for all the hard work! It's definitely appreciated. Zoc_Trooper I did a spell in the Radfan whilst serving in the British Army. Good luck & watch out for the scorpions... etc[;)] And all those scantily clad women! [X(] They can easily lead you astray... [:'(] Cheers, Neilster

zoc_trooper -> RE: When? (3/6/2007 10:09:56 AM)
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 -> RE: When? (4/2/2007 4:27:37 AM)
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 -> RE: When? (4/2/2007 9:50:19 PM)
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 -> RE: When? (4/2/2007 11:23:29 PM)
quote: 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 -> RE: When? (4/5/2007 3:40:44 PM)
Hey Steve, Sorry to hear about your mother and I hope for the best with your trip to Philly. Chaylaton

Shannon V. OKeets -> RE: When? (5/2/2007 2:42:55 AM)
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 -> RE: When? (5/5/2007 4:21:12 PM)
Thanks for all the updates. I check in every few months or so to see how the development is going.

Bluestew0 -> RE: When? (5/6/2007 3:53:24 AM)
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 -> RE: When? (5/7/2007 1:47:16 AM)
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 -> RE: When? (5/7/2007 2:39:55 AM)
quote: 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.

Page: << < prev 9 10 [11] 12 13 next > >>

Forum Software © ASPPlayground.NET Advanced Edition 2.4.5 ANSI

2.203125