World in Flames is the computer version of Australian Design Group classic board game. World In Flames is a highly detailed game covering the both Europe and Pacific Theaters of Operations during World War II. If you want grand strategy this game is for you.
Damn Jose remind me not to get on your bad side whew![:-] El Cid must have had a errrr[&:] never mind, he sure got along with the senoritas huh, a lot of his ancestors around or within a 20 mile radius[:D]
Maybe just pm us the training video's and I would be happy, hint-hint nudge-nudge.
Be happy to sign a non-disclosure agreement.
A head with a camo helment pops up out of the tall grass....
With Wide Eyes and an Alert Look On His face...
His head swivels looking for the target....
"Training Videos .... training Videos.... "
Where Do I Sign
The last time I discussed this with Dave and Erik (at Matrix Games) their decision was to wait until ~ a month before initial release and then made a coordinated and comprehensive marketing push for MWIF. Since marketing is an area where my skills are negative ("if you let me help - you'll have fewer sales"), I defer completely to Dave and Erik, who have both more experience and more success than I.
[As a player, releasing the training videos earlier appeals to me; but see the previous sentence for the worth of my marketing ideas.]
I see its time to apply the negotiating skills.[:'(]
I'm sure once we explain to Dave and Erik that the loyal MWIF forum folks would relish the opportunity to view the video-tutorials as a reward for their continued commitment to the product and their ongoing valuable, if not invaluable contribution they would be more than happy to capitulate. Steve, do you have a number where Dave or Erik can be reached? [8|]
I see its time to apply the negotiating skills.[:'(]
I'm sure once we explain to Dave and Erik that the loyal MWIF forum folks would relish the opportunity to view the video-tutorials as a reward for their continued commitment to the product and their ongoing valuable, if not invaluable contribution they would be more than happy to capitulate. Steve, do you have a number where Dave or Erik can be reached? [8|]
Damn Jose remind me not to get on your bad side whew![:-] El Cid must have had a errrr[&:] never mind, he sure got along with the senoritas huh, a lot of his ancestors around or within a 20 mile radius[:D]
Bo
Not trying to frighten anybody, [8|], just answering about your comment about my supposedly meekish attitude, I have nothing to prove. And when I need to prove something I use to do it personally.[:D]
As for El Cid, I don't know how many young ladies he had, but I don't care, I was not meaning I descend from him but that I come from the land from where the steel comes for these souls.
I see its time to apply the negotiating skills.[:'(]
I'm sure once we explain to Dave and Erik that the loyal MWIF forum folks would relish the opportunity to view the video-tutorials as a reward for their continued commitment to the product and their ongoing valuable, if not invaluable contribution they would be more than happy to capitulate. Steve, do you have a number where Dave or Erik can be reached? [8|]
Try MatrixGames.Com email or use a PM.
Samurai, I think we need to create a target profile on Dave and Erik prior to the negotiation. Something like:
Target Name:
Forum member name:
Age of target:
Weight of target:
Favorite donut:
Likes Twinkies Y/N:
Max foot speed of target:
Time of day when most likes to Nap:
Still has hair?:
Type and age of car:
Modifications (nitrous, racing tires, etc):
Close talker?
Loud talker?
Quiet talker?
Mumbler?
Twitcher?
Hearing impaired?
Visually impaired?
Just generally impaired?
Born again?
Has own office when other staff haves cubicles?:
Despises programmers for being more intelligent?:
Star wars or star trek?:
Trust me on this one... HOPE THE PHONE DOESN'T RING AT EXACTLY THE WRONG MOMENT.. you will 'drop' the cloud of quickie tasks floating in your head and likely not pick them all back up when you resume.
.
.
.
.
NOW consider this analogy....
When was the last time that you got lost driving somewhere you have never been before. Consider that - Really.
You had a map. You studied it ahead of time. You consulted Mapquest. You followed the path as good as you could, but you just couldn't find the spot.
Oh, you got there eventually - maybe even quickly ... but DID YOU DO IT CORRECTLY THE VERY FIRST TIME?
And then, what if when you did not drive directly to the destination, it had the potential to disrupt any other trips that you are about to take OR have taken previously.
Furthermore, if you suspect that a previously taken route may have been affected, now you have to retrace it EXACTLY and alter it if needed.
Meanwhile.... you are being paid based on how many trips you make.
Meanwhile... everyone believes they are the best navigator in the world and consider you a failure if you choose (for reasons they may have never considered) a path that they would not have chosen.
And it has to work even if the streets have potholes (bad drivers, hardware problems, etc.)
And it needs to work for cities where the speed limit is low (old machines)
And it needs to work well enough that at the end of the day, people feel that it *almost* made as good of choices as they would have (i.e. the AI needs to be a challenge but can be beat - otherwise everyone will accuse it of being stupid or cheating)
SUMMARY
Writing large computer programs is a very challenging task that involves keeping up with huge amounts of detail and tying ALL of the loose ends together in a nice package.
WOW![X(] You guys really have been busy in the time I've been gone from the forum!
I want to bring your attention back to the above post by SamuraiProgrammer for a minute. I've abridged it (quite a bit) for the sake of brevity.
Dear SamuraiProgrammer.
First of all, I believe you've hit the nail on the head with that post. Thank you so much! It's really something to hear it from another person. I can really identify with what you write.
Secondly, I laughed out loud when I read the line about the ringing phone. Been there lots of times; and it's equally annoying EACH ¤%@# TIME! [:@] But when put like you do above it's funny as heck. [:D]
Third. I believe that your analogy to driving is the best I've heard so far. Explaining something technical and extremely specialized knowledge to a layman - and making sure that he understands what you're saying - is one of the greatest challenges I can imagine. Congratulations! I think you may have done just that.
So thank you for the music.
And as always : The biggest THANK YOU goes out to Steve!!! [&o][&o][&o] May your lines of code never become entangled.
Best regards guys.
Nanorider426
Edit:
PS: Can't wait for the next update from Steve. It's almost like it's X-mas once a month! [;)]
Samurai, I think we need to create a target profile on Dave and Erik prior to the negotiation. Something like:
Target Name:
Forum member name:
Age of target:
Weight of target:
Favorite donut:
Likes Twinkies Y/N:
Max foot speed of target:
Time of day when most likes to Nap:
Still has hair?:
Type and age of car:
Modifications (nitrous, racing tires, etc):
Close talker?
Loud talker?
Quiet talker?
Mumbler?
Twitcher?
Hearing impaired?
Visually impaired?
Just generally impaired?
Born again?
Has own office when other staff haves cubicles?:
Despises programmers for being more intelligent?:
Star wars or star trek?:
The first two are required fields [:)]
Only the first two??? Surely the last is the most important! [:D]
I'm not sure I've ever posted here but let me just chime in.
I first played this game in 1995. I've dreamed of it on computer since then. I helped playtest CWIF when it was in development. I have read this forum every single week since Matrix took it over.
Steve is doing an amazing job.
I will buy this game when it is done. I've been waiting for 14 years. (And I know others who have waited longer!) I'll keep waiting.
Steve, keep up the good work. It'll be done when it's done. And thank you for sharing so transparently with us what you've been up to all this time.
Damn Jose remind me not to get on your bad side whew![:-] El Cid must have had a errrr[&:] never mind, he sure got along with the senoritas huh, a lot of his ancestors around or within a 20 mile radius[:D]
Bo
Not trying to frighten anybody, [8|], just answering about your comment about my supposedly meekish attitude, I have nothing to prove. And when I need to prove something I use to do it personally.[:D]
As for El Cid, I don't know how many young ladies he had, but I don't care, I was not meaning I descend from him but that I come from the land from where the steel comes for these souls.
Just teasing Jose, my cousin just got back from Spain last month he loved it beautiful country and the food oooofffa, when the hell is Sergio Garcia going to win over here?
Damn Jose remind me not to get on your bad side whew![:-] El Cid must have had a errrr[&:] never mind, he sure got along with the senoritas huh, a lot of his ancestors around or within a 20 mile radius[:D]
Bo
Not trying to frighten anybody, [8|], just answering about your comment about my supposedly meekish attitude, I have nothing to prove. And when I need to prove something I use to do it personally.[:D]
As for El Cid, I don't know how many young ladies he had, but I don't care, I was not meaning I descend from him but that I come from the land from where the steel comes for these souls.
Just teasing Jose, my cousin just got back from Spain last month he loved it beautiful country and the food oooofffa, when the hell is Sergio Garcia going to win over here?
There have been discussions recently on the World in Flames forum about a request to view the MWIF training videos.
I understand through Steve that that you would like to wait until a month prior to release to let the folks see the videos. I was hoping I could convince you to release one per week to keep interest high, as we get closer to the release date.
It woud be a great reward for the forum members continued commitment and their ongoing invaluable contribution to the product.
I thought about a non-disclosure agreement but it probably would not be practical to implement, and even then, who would you sue.
I think I am trying to convince myself that "one-per week " would be a good marketing plan, but then I realize I may be just self-serving.
For sake of argument, let say the video gets released to u-tube, generates some interest. Then another gets released, generates some more interest (details can be found at Matrix games--nice plug). Then you have all these people browsing through Matrix, buying product, generating huge bonuses for staff, ok--maybe I'm stretching things.
Couldnt help to read this enormously interesting thread. And couldnt resist to reply a message
in the subject I am most interested in ' software design'.
I am a software engineer for at least 15 years.
I know what happens to large programs when they grow and grow and even grow to a certain 'beast' that is
unmaintainable. Meaning that changing one line of code at a certain place, introduces multiple bugs which would
never be expected nor properly fixed.
This is called 'end of life' of the software product (also software rot). Many products in the 90s (and even now ) experienced
this (windows 3.11 is one of the nicest examples), at the end fixing one bug introduced 3 new unexpected ones.
Some software products already have this when they are not even finished (the finishing of the software is
hampered by these bugs 'popping up', fixing them will create an even bigger beast etc etc.)
While I believe that a software product will always have bugs (no bugfreesoftware exists), escpecially when its
a big project.
I do believe (and know) it is possible with a good object oriented design it is possible to create large software
products that are maintainable and bug fixable (and so it will be planneable:-> 'we will have the software at date :' )
As seen many times, with a less than good design software grows and grows and the bug hunting will
get out of control (it is not possible to say anymore 'this bug will cost 2 weeks to hunt dwn and fix').
As to say I do not know anything of the software design of this product, so my remarks should not be taken as
critisism to this or any other games. They are more remarks in general.
Typically software products which are procedural in design (or lack design)
have the behaviour as described above. Object orientation is the way to go for software creation. I have used
testdriven development and am very much impressed by this (debuggers are most of the times not necessary).
December 1, 2009 Status Report for Matrix Games’ MWIF Forum
I. Project Management
I still don’t know how long it will take me to fix all the bugs, but I continue to make progress on them. In November I focused 95% of my time on fixing bugs. For December, I will continue to work primarily on fixing bugs, with a small diversion to complete the LAIO parser.
I spent several days revising my master task list. Besides redesigning how information is stored, I also grouped similar bug reports together. One major improvement is that the bugs are now listed in the order of the sequence of play. This lets me review, say, all the bugs reported concerning the Declaration of War phase, which has 9 subphases. Besides changing the order, I renumbered the current bugs starting with 100, so they are all 3 digits. My previous numbering had run over 2000, which I found discouraging to look at every day. Roughly, in the past 4 and ½ years I have fixed 1900 bugs that had the temerity to make it to my task list.
Communications
Mike (Players Manual) has progressed to beginning work editing the ‘big’ section (Section 8, Player Interface), but nothing new from Jim (sound effects), or Dave (music).
I monitored all the threads in the MWIF World in Flames forum daily and uploaded versions 3.00.02, 3.00.03, 3.00.04, 3.00.05, and 3.00.06 for the beta testers. This exceeded my goal of a new version every week.
Patrice continues to keep the map data up-to-date with small changes. This month he got some help from Orm and Alain, which is described below.
Robert continues to do new naval unit writeups every week, while Alain and David maintain a similar pace on the Land Unit writeups.
Michael has done a ton of testing on the sequence of play and, in combination with a half a dozen other beta testers, gifts me with a fresh set of bug reports for every new version I upload (their generosity knows no bounds).
No communications with Harry Rowland or Chris Marinacci.
Hardware and Software Development Tools
I have decided that it is time to buy a new computer. The current one has served me well over the past 3 and a half years, but the salt air in Hawaii plays havoc with metallic elements. By now there are just too many things “not quite right”. I could provide a list of defects, but it would be boring to read. What I have started to do, and will finish in December, is make a detailed list of all the hardware and software in my current system and what I want in the new one.
So far that is one page for hardware and a second for software, but it will probably be 6 pages total once I get everything identified precisely. When I was younger, I would configure a new system off the top of my head and then go buy it. But I’ve become aware these days I have a lot of ‘stuff’ on my system. I do not want to lose any capabilities, plus I have a couple of small items under ‘improvements’. Mostly I will be upgrading my software, with the big changes being to Windows 7, the latest Delphi, and the latest Theme Engine. The portable computer I bought last year runs under Vista, and I will stay that way. This will give me systems for testing both Vista and Windows 7. I expect to be able to test Windows XP under Windows 7 (can anyone confirm that for me)?
I’ll purchase the new system in January and I’ve scheduled a week of misery getting it to perform as well as my current one.
II. Sequence of Play Beta Testing
I uploaded five new versions for the beta testers this month.
Version 3.00.02 (18 changes) primarily fixed problems with naval movement. The rules for moving naval units is very complex with: limitations on which units can move together, activity limits sometimes imposed, restrictions on moving into some sea areas (e.g., through Gibraltar), dropping off units at sea/while moving through a port, loading units in a port/at sea/while passing through a port, possible naval interception, and resultant naval combat if an interception succeeds. Mixed into all of that are the naval moves that happen when aborting from a naval combat and naval units that are forced to rebase when overrun. The last can occur during the conquest phase and in several places when forming Vichy France. The code to enforce these rules while enabling the players to perform all legal actions is daunting to read, much less write and modify. The player interface design for naval movement has its own little tangle of interactions. Another change with this version was the addition of the optional rule Breaking the Nazi-Soviet Pact. That permits players to break the Nazi-Soviet more readily in 1941.
Version 3.00.03 (10 changes) made “follow up” patches to naval movement. I added a trinary decision after naval interception if there are units still capable of moving. The third choice is for the player to drop off some units in the sea area (where the interception just took place) and have others continue moving. Note that this can happen whether the interception attempt succeeded or not. Also note that the dropped off units can load land units from coastal hexes. Once units have been dropped off, the remaining units need to have their maximum destinations redetermined since they may have dropped off slower units.
Version 3.00.04 (19 changes) was mostly small changes. Some of these were eliminations of old bug reports that I could not reproduce. What happens is that I make corrections but do not necessarily update my task list in all the places where it should be updated. For example, if a beta tester emails me a bug report where the program crashed with a MadExcept error, I use the MadExcept report to locate the problem and fix the code. Linking that correction back to a specific bug report in the MWIF Development Forum isn’t always obvious. I also get a lot of duplicate bug reports (which is a good thing!). However, removing duplicate entries is time consuming and I begrudge the time when I am hot in the throes of getting code to work.
Version 3.00.05 (25 changes) made the changes to invasion hexes which is described in the paragraphs below about the Map, and fixed several problems with placing units in the air reserve pool during setup. This version fixed bugs in the Support Minors phase and in the newish code for the Surrendering phase. Here I was taking advantage of my redesigned task list to fix all the bugs for selected phases of the game. Other improvements were the additions of new help messages in Help Content.txt for the 20 multiple use Unit Dialog forms (e.g., disposition of Vichy units). I guess the most momentous change with this version was the elimination of the Collapsing Vichy France ‘phase’ that was part of CWIF. Collapsing Vichy France is now a digression that occurs during the Axis rail or land movement phase. The advantage of having this as a digression is that the series of events that happen when Vichy collapses can be performed cleanly, and then the game returned to the place in the sequence of play where the collapse was initiated.
Version 3.00.06 (19 changes) was a real hodgepodge of corrections. Rather than tackle a group of related bugs, or one ‘difficult’ bug, I simply investigated all the new bugs reported by the beta testers for the previous two releases. The result was I jumped around in the program hither and yon slathering on patching compound (no programmer should be without it).
Test Script/Plan
Nils has defined 7 sets of optional rules that can be used to encompass all the possible combinations thereof. What this means is that by creating saved games for each of the 7 sets, all the optional rule combinations can be tested. That is a lot easier than having 2 saved games (one with an optional rule ON and another for it OFF) for each of the 81 optional rules.
Game Engine Redesign
One major annoyance this month was the discovery that the sequence of play for the subphases of Land Combat Resolution was incorrect. I had published section 7 of the Players Manual early this year describing these subphases in gruesome detail, but no one had noticed the two serious errors.
What now needs to be done is: (1) modify section 7 text - to me, this is the design specification for the sequence of play, (2) add two new subphases for Converting Shattereds to Retreats and Disorganizing Attacking Units following the Advance After Combat subphase, (3) modify the Land Combat Resolution form to reflect the changes, (4) take new screen shots of that form for the Players Manual, and (5) modify the accompanying text in the Players Manual, (6) modify the text in Help Content.txt, and (7) redo the chapter of the Training Videos on land movement and combat. As someone who has programmed for over 40 years, having the design specifications change after I have written the code and it is thoroughly debugged and documented, instantly infuriates me. I think I’ll go buy more chocolate.
Nothing new on rewriting the supply routines. It’s now 4th in my task queue behind naval combat bugs, the land combat resolution modifications, and coding the redesigned system for routing resources to factories.
Units, Map, and Scenarios
Orm reviewed all the straits hexes on the map for legibility and Patrice changed the data so icons in the hex do not occlude the straits arrows. Alain reviewed the COA data file and located some spurious coastal hexes in the middle of the ocean. Those had no effect on game play and were a consequence of changes to the Scandinavian portion of the map several years ago (but I feel strongly that neatness counts in all software and data).
Patrice searched for obscure coastal hexes which border on two or more sea areas but can only be invaded from one of the sea areas. Because the CWIF map data files did not identify these hexes, the program was permitting invasions from all adjacent sea areas if an invasion were possible from any one of them. I added a new field to a data file and Patrice made the necessary changes. Now the program ‘knows’ that the 2 hexes forming the border between Denmark and Germany are adjacent to both the North Sea and the Baltic sea but can only be invaded from one of them (it’s different for each hex).
The above changes were all a consequence of Michael coming up with a clear way to present the information on which coastal hexes can be invaded from which sea areas. Previously the program displayed adjacent sea areas in a panel of the Main form as the cursor passed over coastal hexes. Now that panel also contains “(no invasion)” following the sea area name if invasion from the sea area into the hex under the cursor is not possible. I am extremely happy with this solution. Unless I am mistaken, new players will no longer have to struggle to figure out the rules for which hexes can be invaded. Not only does moving the cursor make that crystal clear, but after doing so over a bunch of hexes and seeing which ones can be invaded from which sea areas, a new player can figure out the rule himself - without reading any text at all!
Robert Jenkins continues to generate new naval unit writeups and send me periodic updates of the master file. Alain sends me his current master copy of the land unit writeups when he gets new ones from David Hughes. As always, Patrice found a few more names to add to the map.
Optional Rules
I added a new optional rule that makes the Nazi-Soviet pact easier to break in 1941. It is a small change that was easy to code. Simply, the ratio of garrison strength needed to break the pact drops from 4:1 to 3:1 for the second half of 1941. ‘Stuffing’ the border with the confidence that Germany will be unable to break the pact is therefore more difficult for the USSR, and the attempt to do so runs the risk of having the Russian units overwhelmed in the first turn or two of Barbarossa. However, Germany isn’t given free rein to attack whenever it likes, and should the German player neglect his garrison on the border, he can still find himself unable to DOW the USSR until 1942.
Saved Games
Nothing major this month. Changes were required to add the new digression for collapsing Vichy France, but that was transparent to the beta testers. All previously saved games can still be restored.
III. Player Interface
I fixed a bunch of player interface bugs this month. The new ordering of my task list has them towards the top so they drew more of my attention than they typically do. When selecting what to work on, one question I ask is: “Is it easy to do?” Another is: “How long has this defect been festering?” Several of the interface bugs met one or both of those criteria. Oh, and the third question is: “How fatal is this bug?” I refer you to Billy Crystal’s monologue in The Princess Bride on different degrees of dead.
IV. NetPlay
Nothing new.
V. PBEM
Nothing new.
VI. AI Opponent
Peter started work on creating Common Functions for use in the AIO scripts. Most programmers will understand this terminology, and for those of you who don’t, these are fragments of code that are used in multiple LAIO scripts. By pulling them out and placing them in a separate file, they only have to be written (and debugged) once. Then they can be used by any script that needs the same logic. A couple of examples are: (1) determining whether there are any seaborne invasion threats when setting up minor country units, and (2) the same for paradrop threats. These functions are used when setting up the units for almost every minor country - that is, they are used in dozens of places.
I scrimped some free time to work on the LAIO parser this month. At this point I have it close enough to being done that I hope to complete it in the first week of December.
VII. Documentation
Mike asked me to send him my current (unfinished) text on Sections 6 and 8 of the Players Manual, so I guess that is what he is working on now (153 pages in section 8 to date). The former has a lot of holes (PBEM and NetPlay forms). For the latter, (Player Interface), I have caught up to all the code that is finished. That is, if the code is written and working, then its documentation in the Players Manual is also finished. The main open items are for Production Planning (redesign of the system for routing resources to factories), and Breakdown/Reform units (requires implementing the optional rule for Unlimited Breakdown). As I get the code to work, I’ll supplement the documentation in the Players Manual. My goal here is to have zero concerns about documentation when the program nears completion.
VIII. Learning Aids (tutorials, training video, embedded help text)
Nothing new on the last 3 chapters of the training video: naval movement, naval combat, and production. I was about ready to author the chapter on naval movement, but that will have to wait until after I redo the chapter on Land Movement and Combat.
As mentioned above, I added text in the context sensitive Help file for 20 more forms. Context sensitive help is nearly finished, with the exception of the PBEM and NetPlay forms which haven’t been completed. As before, the sequence is: write the code, create the form, take the screenshot, write the documentation in the Players Manual, and then copy that text into the Help Content.txt file. The last step is what appears on the screen when the player clicks on the ubiquitous Help button on the forms - a separate message for each of the 157 forms.
IX. Glitz (historical video, sound effects, music, historical unit write-ups)
No change from last month. The currently active authors for the unit writeups are Robert, Alain, and David. I am waiting on the sound effects from Jim and the music from Dave.
X. Marketing
No change from last month. Andy Johnson has retained the ownership of the MWIF fan site he started to set up before his new job prohibited him from working on it. If anyone is interested, send me an email or Personal Message (PM) - Andy is willing to transfer ownership to someone else.
Remaining Tasks
I Tasks requiring a small number of hours
1. Historical video
Integrate these into the program (randomizing when they are shown).
2. Sound effects
Awaiting Jim’s complete set of sound effects, after which I will integrate them into the program.
3. Music
Awaiting Dave’s complete set of music, after which I will integrate them into the program.
4. Unit writeups
I simply replace old master files with new ones when Rob and Alain send me updates.
5. Players Manual
8 of 12 sections are done.
6. Context sensitive help
I clone the text from the Players Manual once that text has been written.
7. Auxiliary files
These are starter sets for new players so they can jump right into playing the game without having to make a lot of preparatory decisions. Michael just volunteered to work on creating these.
8. Tutorials and training video
The Training Video is 70% done.
9. Player Interface
With the exception of the Standing Order forms for PBEM, I have finished the forms.
10. Optional Rules
For the optional rules, I need to fix bugs and bring them up-to-date with rules changes since 2003.
II Tasks requiring a medium number of hours
11. PBEM
The technical task of sending and receiving emails from within the program hasn’t been coded. Work on the standalone program (running on a third party computer) to generate random numbers hasn’t begun. The large task here concerns the Standing Orders: defining and instantiating internal variables, then displaying them in the forms so players can review and revise them.
12. Sequence of Play
There are still many bugs related to the sequence of play.
III Tasks requiring a large number of hours
13. NetPlay
There isn’t a lot to do directly related to NetPlay, but the underlying performance of the program in generating Game Record Log Entries has to be perfect. That’s because the GRLs are sent to each computer in a networked game to keep them up-to-date with the decisions of all players. I need to instantiate, with actual data, the form used to monitor internet communications while a game is in progress.
14. AI Opponent
I need to finish writing the parser. Which will then leave the task of calibrating the rules’ performance so the AIO plays well.
