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.
_____________________________
When?
Moderator: Shannon V. OKeets
-
wargameplayer
- Posts: 112
- Joined: Mon Apr 04, 2005 8:06 pm
RE: When?
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.
-
Shannon V. OKeets
- Posts: 22165
- Joined: Wed May 18, 2005 11:51 pm
- Location: Honolulu, Hawaii
- Contact:
RE: When?
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.
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.
Steve
Perfection is an elusive goal.
Perfection is an elusive goal.
RE: When?
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.
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
- Posts: 22165
- Joined: Wed May 18, 2005 11:51 pm
- Location: Honolulu, Hawaii
- Contact:
RE: When?
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.
================================================================
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.
================================================================
Steve
Perfection is an elusive goal.
Perfection is an elusive goal.
-
jesperpehrson
- Posts: 846
- Joined: Sat Jul 29, 2006 4:48 pm
RE: When?
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?
PBEMgames played
- Korea 50-51 MV as communist
- Agonia y Victoria xx as Republican
- Plan Blau OV as Soviet
- The great war xx as Central Powers
- DNO XX as Soviet
- Korea 50-51 MV as communist
- Agonia y Victoria xx as Republican
- Plan Blau OV as Soviet
- The great war xx as Central Powers
- DNO XX as Soviet
-
Shannon V. OKeets
- Posts: 22165
- Joined: Wed May 18, 2005 11:51 pm
- Location: Honolulu, Hawaii
- Contact:
RE: When?
If you want to make arrangements to meet, let me know. When will you be there ("rented cottage")?ORIGINAL: capitanORIGINAL: 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?
Steve
Perfection is an elusive goal.
Perfection is an elusive goal.
-
jesperpehrson
- Posts: 846
- Joined: Sat Jul 29, 2006 4:48 pm
RE: When?
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!
PBEMgames played
- Korea 50-51 MV as communist
- Agonia y Victoria xx as Republican
- Plan Blau OV as Soviet
- The great war xx as Central Powers
- DNO XX as Soviet
- Korea 50-51 MV as communist
- Agonia y Victoria xx as Republican
- Plan Blau OV as Soviet
- The great war xx as Central Powers
- DNO XX as Soviet
RE: When?
Whatever happened to the demo they had out a few years ago? It looked like it worked fairly well... I still have it.
JUST SAY NO... To Hideous Graphics.
-
Shannon V. OKeets
- Posts: 22165
- Joined: Wed May 18, 2005 11:51 pm
- Location: Honolulu, Hawaii
- Contact:
RE: When?
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.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.
Steve
Perfection is an elusive goal.
Perfection is an elusive goal.
-
Shannon V. OKeets
- Posts: 22165
- Joined: Wed May 18, 2005 11:51 pm
- Location: Honolulu, Hawaii
- Contact:
RE: When?
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?ORIGINAL: msrt59
If you pass near Reims going to Avignon i could exchange a botlle of Champagne for a beta version you know ?
Steve
Perfection is an elusive goal.
Perfection is an elusive goal.
RE: When?
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.[&:]
Arrogance is the next best thing to being there.
RE: Old WIF Player Saying Hello and Thanks
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.
================================================================
RE: When?
So that means July - August 08!!!!
Oh the inhumanity of it all!!
[:(][:(][:(]
Oh the inhumanity of it all!!
[:(][:(][:(]
Arrogance is the next best thing to being there.
-
composer99
- Posts: 2931
- Joined: Mon Jun 06, 2005 8:00 am
- Location: Ottawa, Canada
- Contact:
RE: When?
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.
~ Composer99
-
Shannon V. OKeets
- Posts: 22165
- Joined: Wed May 18, 2005 11:51 pm
- Location: Honolulu, Hawaii
- Contact:
RE: When?
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.
================================================================
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.
================================================================
Steve
Perfection is an elusive goal.
Perfection is an elusive goal.
-
zoc_trooper
- Posts: 4
- Joined: Sun Mar 04, 2007 7:02 am
RE: When?
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 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
RE: When?
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[;)]
RE: When?
And all those scantily clad women! [X(] They can easily lead you astray... [:'(]ORIGINAL: ess1
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[;)]
Cheers, Neilster
Cheers, Neilster