Page 2 of 4

RE: The Banyan Tree

Posted: Thu Jul 14, 2005 4:09 pm
by Shannon V. OKeets
ORIGINAL: Greyshaft

http://www.mekong.net/cambodia/banyan1.htm

"The banyan tree grows throughout Cambodia. It may reach a height of over 100 feet, and as it grows, new roots descend from its branches, pushing into the ground and forming new trunks. The roots grow relentlessly; many of the ancient temples of Angkor have toppled as these roots have become embedded in the cracks and crevices between their massive stones. A single tree might have dozens of trunks, and it is often impossible to tell which is the original."

Ah, yes. That is a good description of a Banyan tree and specifically, the one in front of our building. The horizontal branches of ours are about 20 to 30 feet off the ground and they do drop down tendrils seeking the ground. If they reach the ground, the ends turn into roots and eventually the descending vines become trunks. The groundskeepers (I live in a 36 story condominium) have to keep the descending branches trimmed back fairly aggressively. Right now ours has about 5 trunks, is 50 feet high, and about 50 feet by 100 feet in canope. Hawaii has a bunch of Banyans - imported from Thailland I gather from your post. The vast majority of flora in Hawaii are imports, coming from all over the tropical climes.

RE: Play by Email (PBEM) for MWIF

Posted: Thu Jul 14, 2005 4:26 pm
by Shannon V. OKeets
ORIGINAL: Gaius Varro

Shannon,

As to the question of getting die rolls back and forth between e-mail clients, there are a number of cryptographic based protocols that are made to deal with this type of problem. One source of a few of these protocols that I remember reading a few years back was from a book called "Applied Cryptography" by Bruce Schneier. (It's still available last time I checked). It's a monster book, and I'm sure there are others out there.....

These techniques can be used in the TCP/IP version as well, as there are a few ways to intercept and cheat those protocols as well.

I would recommend you take a look at a text on these trusted protocols and information verification techniques, rather that just guess at a protocol on your own. There are insidious ways to spoof many things, and like most things, experts do know best.
IIRC, that book also has a section on random number generation.

Good luck on this. The topic is not an easy one!

Gaius Varro
Sorry I didn't response to this post earlier - I missed it the first time around.

I don't actually expect to have much of a problem encrypting files. This cavalier attitude is because I do not expect the Department of Defense to dedicate any of their supercomputers or expensive personnel to taking on the task of decoding them. I can just use something based on a 32 bit key and be pretty certain that anyone's home computer won't be up to the job.

If players are playing without fog-of-war, then everything will be visible to everyone anyway (US entry status being the sole exception). Even with fog-of-war. a lot of what happens in the game is visible to everyone, so the 'secret' stuff is a fairly minor part of each message/game file.

Thanks for the heads up anyway. It made me reevaluate my planned design and I'll be careful when implementing it.

RE: Play by Email (PBEM) for MWIF

Posted: Thu Jul 14, 2005 6:17 pm
by pak19652002
Smart move to stay out of the CB quagmire. I say that with great affection because as much as I complain about it, I am playing three CB games simultaneously and loving it.

I'm so addicted to PBEM playing now that when I go down to my commandeered dining room table an look at my plexiglas (and dust) covered maps with scores of counters all over them, I cringe when thinking about trying to pick them up with tweezers, living in fear of sneezes and children, and negotiating with my wife for sqaure footage.

I figure that it will sit there until Thanksgiving and then will be packed up indefinitely!

Therefore, I'm highly motivated to see a successful MWIF as soon as possible and will try to help any way I can.

Peter


RE: Play by Email (PBEM) for MWIF

Posted: Sat Jul 16, 2005 3:34 pm
by Shannon V. OKeets
I am expanding on the idea of having Matrix Games (or some other third party) host a small program that facilitates PBEM. Let me call this program eMWIF since it would only be used for PBEM games. eMWIF would be running all the time on the host system and always available to respond to requests from MWIF programs. eMWIF would only have one real task: to generate random numbers for PBEM and let all players in a PBEM game know when, why, and what the random numbers are. The why portion of the previous sentence refers to why the phasing player requested the random number.

Yes, random numbers would only be requested by phasing players. At some places in the turn sequence there is no phasing player (e.g., weather roll) but we’ll just assign some player the task (player with initiative). All random numbers that are for die rolls would be visible to all players. Random numbers generated for US Entry chits would be visible only to the Allies during game play, but once the US enters the war, they would be revealed to everyone.

The mechanics of the process would be fairly simple. While playing MWIF, the phasing player would commit to some action that needs a die roll in response. For example, he selects his first ground attack. MWIF, with NO involvement of the player, would login to the Matrix Games web site and pass along why the random number is being requested (e.g., for which combat) to eMWIF. eMWIF would generate a random number and return it over the Internet to the MWIF program that requested the random number. eMWIF would also generate emails, that it sends to all the other players in the game. Each of these emails would hold the absolute minimum amount of information necessary to bring everyone else’s copy of MWIF up-to-date. These emails would be quite small. I do not want eMWIF to use up anyone’s email account capacity with large files.

To make this work, each game would have to go through a simple setup routine with eMWIF when it starts up. The setup would assign a unique “game in progress” number and a list of the players in the game: player names for each major power, passwords for each player, and email addresses. These would let eMWIF validate that the person who logs in is authorized to request the die rolls and to send emails to everyone. The list of players could be modified should someone drop out of a game, or more people join a game in progress just to watch.

From the phasing player’s point of view he simply rolls the dice whenever needed. He might have to wait a little bit while MWIF and eMWIF communicate. It should take about the same amount of time that it takes now to login to Matrix Games forums. The time to execute the request and generate the emails would be almost instantaneous.

From the non-phasing player’s point of view, when he next loads a specific MWIF game, the program would go out to his email account and download all the emails related to that game. It would also delete them from his list of email, just to keep his email account tidy. Then it would display all the die rolls to the non-phasing player in the sequence that they occurred.

There is the possibility that MWIF might find both die roll emails and other communications about the game as well. For example, after the phasing player completes his attacks, et al, for a phase, he would send an email stating that he is done his impulse. MWIF should be able to retrieve all the emails in the correct order before presenting them to the non-phasing player. Actually, at the end of an impulse the definition of who is the phasing player changes.

Creating eMWIF gives us several benefits. Just to be clear, they are:
(1) random numbers that the player’s cannot somehow manipulate so they can cheat,
(2) the ability of a phasing player to conduct all his land attacks in sequence without needing any email communication with the non-phasing player, and
(3) different phasing players on the same side able to perform their attacks without coordinating with other players on their side (e.g., Japan and Germany can do land attacks without waiting for each other).

In summary, eMWIF would prevent cheating and also reduce the number of emails substantially. There are still some details to work out. For instance, the phasing player would have to make any advances after combat before asking for the next die roll, but I think these can implemented rather easily.

Do you see any weaknesses? Do you have any improvements to add?

RE: Play by Email (PBEM) for MWIF

Posted: Sat Jul 16, 2005 11:38 pm
by Froonp
In summary, eMWIF would prevent cheating and also reduce the number of emails substantially. There are still some details to work out. For instance, the phasing player would have to make any advances after combat before asking for the next die roll, but I think these can implemented rather easily.

Do you see any weaknesses? Do you have any improvements to add?
The only weakness I can see here is that it is another server that Matrix has to administrate and backup so that it doesn't fail. I remember a time when all the forums at Matrix disappeared and were lost. I suppose they were not backuped. So Will Matrix maintain a server for MWiF PBEM ???
Moreover, Matrix may not last forever, and what about MWiF if Matrix disappears ? I would not be pleased to own a game that I can no longer play because one feature housed on a Matrix Server is dead.

RE: Play by Email (PBEM) for MWIF

Posted: Sun Jul 17, 2005 12:46 am
by Incy
Hi, haven't been reading the boards for a while, too buzy with real life.

Anyways I have been playing CWiF PBEM a lot, and I also have a fairly solid AI and programmer background. I'll post more later, but have some comments after reading most of the newer threads:

-random numbers:
loose the double matrixed random generator idea, it does not help. As someone said, look up in a book how to do random generation.
Find a decent generator/algorithm in a book. Probably the book will reccomend how to safely hash the random generator output with system time as well (don't use system time alone!).

-PBEM:
You need to get it down to very few emails/turn. When we play, we do 1 save/impulse, and about 2-3 for EOT, plus usually one for important DOWs (where setup/alignment is critical). The phasing player decides what the non-phasing player does unless there's something really critical going on. Decitions are subject to notes(on units) and general intructions. We also have some special rules, most notably that RTB can be changed once the non-phasing player resumes control (effectively, it happens at the start of the next impulse, so a chasnge in sequence of play).

In a real PBEM game, I suggest:
-change sequence of play, all RTB by non-phasing players happen at the start of next impulse/go. That actually changes the game rules/logic slightly (when returning units, it might be better known if a hex is safe or not). But the upside is huge, much less planning required, and complexity is much reduced.
-have AI make choices for the non-phasing player.(i.e taking over the job of the phasing player in our games)
-give the non-phasing player some handles to be able to adjust the AI to his liking (to some extent). What handles there should be of course depends on the AI implementation, but the AI SHOULD cater to taking external parameters from players. It's generally a bad idea to allow/encourage/require players to do to much micro-managing (= explicit decitions), because that will tend to break an AI. Good input to an AI could be things like: acceptableLossRatio(in expected lost BP vs. inflicted BP), maintaining<Unittype>ReserveHappiness (how much to keep back), agressiveness, <unittype>Highthened/LoweredValue (care less/more about keeping certain units alive), holdGroundStance (fighting a mobile defence vs. trying to hold the line), missionTypeImportance (lets AI know what enemy mission types you worry more about), etc. Players could also be allowed to assign simple flags (more/less value, save this unit, etc) to hexes/areas/individual units.
Anyways, the goal should be to have only a limited set of buttons for the player to play around with, and a decent "default" behaviour. Time spent tweaking the AI is not quality gametime for most people. Leaving certain things to the AI should not be a big turnoff as long as the AI isn't a perfect moron, and as long as the "other guy" also gets to have his perfect plan ruined by the AI.

about dice generator server:
-make any servers required to run the game player configurable, so they can be changed by players!!
-if you're going down the path of server-based dicerolls, why bother with email at all? Use tcp/ip or other suitable client/server protocol to communicate with a server!! If you'll connect to a server for every diceroll anyways, you might also consider using a central server to send and recieve saves, etc too. 3-way communication with 2 separate protocols will tend to create more trouble than it solves, if you ask me.

about several players/side:
-this will be difficult, not so sure it can be easily solved for PBEM

will write more as I find the time (right now it's way late)


RE: Play by Email (PBEM) for MWIF

Posted: Sun Jul 17, 2005 1:08 am
by Shannon V. OKeets
ORIGINAL: Froonp
In summary, eMWIF would prevent cheating and also reduce the number of emails substantially. There are still some details to work out. For instance, the phasing player would have to make any advances after combat before asking for the next die roll, but I think these can implemented rather easily.

Do you see any weaknesses? Do you have any improvements to add?
The only weakness I can see here is that it is another server that Matrix has to administrate and backup so that it doesn't fail. I remember a time when all the forums at Matrix disappeared and were lost. I suppose they were not backuped. So Will Matrix maintain a server for MWiF PBEM ???
Moreover, Matrix may not last forever, and what about MWiF if Matrix disappears ? I would not be pleased to own a game that I can no longer play because one feature housed on a Matrix Server is dead.

Ah, my idea is that eMWIF would be a separate part of the game package when MWIF is purchased. Any third party could host it, not just Matrix. If there are no third party servers hosting the game, then anyone could set one up.

RE: Play by Email (PBEM) for MWIF

Posted: Sun Jul 17, 2005 1:49 am
by Shannon V. OKeets
Good stuff. It makes me think about things in new ways.

ORIGINAL: Incy

-random numbers:
loose the double matrixed random generator idea, it does not help. As someone said, look up in a book how to do random generation.
Find a decent generator/algorithm in a book. Probably the book will reccomend how to safely hash the random generator output with system time as well (don't use system time alone!).

We probably won't agree on this. I have rather simple aims for the random number generator and little interest in the heavily theoretical side that most books go into. My only real concern is that the numbers are evenly distributed and random. There are simple checks I can do to make sure of that. I agree completely that relying on time alone is incorrect.
-PBEM:
You need to get it down to very few emails/turn. When we play, we do 1 save/impulse, and about 2-3 for EOT, plus usually one for important DOWs (where setup/alignment is critical). The phasing player decides what the non-phasing player does unless there's something really critical going on. Decitions are subject to notes(on units) and general intructions. We also have some special rules, most notably that RTB can be changed once the non-phasing player resumes control (effectively, it happens at the start of the next impulse, so a chasnge in sequence of play).

In a real PBEM game, I suggest:
-change sequence of play, all RTB by non-phasing players happen at the start of next impulse/go. That actually changes the game rules/logic slightly (when returning units, it might be better known if a hex is safe or not). But the upside is huge, much less planning required, and complexity is much reduced.

-have AI make choices for the non-phasing player.(i.e taking over the job of the phasing player in our games)

-give the non-phasing player some handles to be able to adjust the AI to his liking (to some extent). What handles there should be of course depends on the AI implementation, but the AI SHOULD cater to taking external parameters from players. It's generally a bad idea to allow/encourage/require players to do to much micro-managing (= explicit decitions), because that will tend to break an AI. Good input to an AI could be things like: acceptableLossRatio(in expected lost BP vs. inflicted BP), maintaining<Unittype>ReserveHappiness (how much to keep back), agressiveness, <unittype>Highthened/LoweredValue (care less/more about keeping certain units alive), holdGroundStance (fighting a mobile defence vs. trying to hold the line), missionTypeImportance (lets AI know what enemy mission types you worry more about), etc. Players could also be allowed to assign simple flags (more/less value, save this unit, etc) to hexes/areas/individual units.

Anyways, the goal should be to have only a limited set of buttons for the player to play around with, and a decent "default" behaviour. Time spent tweaking the AI is not quality gametime for most people. Leaving certain things to the AI should not be a big turnoff as long as the AI isn't a perfect moron, and as long as the "other guy" also gets to have his perfect plan ruined by the AI.

First, I would like to keep a distinction between the AI that plays as an opponent (or partner) and the code that makes decisions on behalf of a player. To my mind the latter should only perform simple and straight forward tasks, not something that is too complicated. In any event, let's reserve the word AI for the opponent and use "standing orders" for the latter. I am not real happy with this choice of words but "programmed instructions", "scripts", and everything else I have thought of seem worse.

I have yet to start the thread on PBEM - Other which will include DOW and EOT. I haven't put my thoughts on these down coherently enough on paper yet. I hope to get it done by Monday.

Changing the order of play moving RTB to the start of a phase seems viable. It is just this sort of thing that made me decide to do the PBEM design as one of the first items to discuss. It could effect a lot of code. Probably we will want to make this an option. I am reluctant to impose my opinion on how people should play the game if alternatives can be provided without too much effort.

Some of your suggestions for what the AI should/should not be able to do are broader in scope than what I envision for standing orders. If what you are thinking about is having the AI play the Japanese while you play the Germans, then those ideas belong in a future thread about the AI as a partner. I probably can't get to that for a couple of months.

Most of your ideas in that paragraph are right on target and what we want to flesh out here. When you say parameters, the more specifics the better. How I interpret "acceptableLossRatio(in expected lost BP vs. inflicted BP)" might not be what you have in mind. By giving examples your meaning will be clearer so I get it correct. Simple flags on the other hand, even I can understand. Where I am headed is to define a data structure for standing orders that accommodates as much as possible, that isn't too confusing, and that can have a simple interface design so the players can give instructions easily.
about dice generator server:
-make any servers required to run the game player configurable, so they can be changed by players!!
-if you're going down the path of server-based dicerolls, why bother with email at all? Use tcp/ip or other suitable client/server protocol to communicate with a server!! If you'll connect to a server for every diceroll anyways, you might also consider using a central server to send and recieve saves, etc too. 3-way communication with 2 separate protocols will tend to create more trouble than it solves, if you ask me.

about several players/side:
-this will be difficult, not so sure it can be easily solved for PBEM

I would prefer that the server be something simple. If you read Froonp's post just above yours, you will see that my concern about the host machine maintaining integrity is shared by others. I envision the game residing on each players' computer with the server merely maintaining a list of who is playnig and where they are in the game (year, turn, impulse, phase, subphase, etc.).

Keep those posts coming. Your last one reminded me to put the AI as partner on my list of things that should be included in MWIF.

RE: Play by Email (PBEM) for MWIF

Posted: Sun Jul 17, 2005 11:15 pm
by Incy
ORIGINAL: Incy

-random numbers:
loose the double matrixed random generator idea, it does not help. As someone said, look up in a book how to do random generation.
Find a decent generator/algorithm in a book. Probably the book will reccomend how to safely hash the random generator output with system time as well (don't use system time alone!).
We probably won't agree on this. I have rather simple aims for the random number generator and little interest in the heavily theoretical side that most books go into. My only real concern is that the numbers are evenly distributed and random. There are simple checks I can do to make sure of that. I agree completely that relying on time alone is incorrect.


Don't be to sure we can't agree :)
The reason I think you shouldn't mess around with some sort of home-grown 2*RNG matrix is that:
-it will add complexity(= more time spent, more bugs)
-IMHO you're more likely to reduce randomness rather than add it (why would best be explained over about 5 beers). A good, single RNG solution will most likely allready have little tricks like the one you describe embedded (IF theory dictates that such a trick would improve the result). And the implementation would be by someone who spent time understanding the underlaying theory.

To see if I could be of help, I did a little googling, and found:
http://csrc.nist.gov/rng/rng6_2.html
At least one of those mentioned
( http://www.schneier.com/yarrow.html )
are opensource and freely available. I'm sure you could google others, surely someone allready coded a decent delphi RND.

mWiF does not have a demanding need for RNG, we need only something that is normal-distributed and does not display any obvious patterns.

btw, it should be noted that the existing CWiF implementation did indeed have serious bugs in it's RND code (at least for 2d10). Chris fixed a bug, but having used CWiF quite a bit since that fix I'm still uneasy about the reandomness of numbers (enough to use an external RND generator for important rolls).
-PBEM:
You need to get it down to very few emails/turn. When we play, we do 1 save/impulse, and about 2-3 for EOT, plus usually one for important DOWs (where setup/alignment is critical). The phasing player decides what the non-phasing player does unless there's something really critical going on. Decitions are subject to notes(on units) and general intructions. We also have some special rules, most notably that RTB can be changed once the non-phasing player resumes control (effectively, it happens at the start of the next impulse, so a chasnge in sequence of play).

In a real PBEM game, I suggest:
-change sequence of play, all RTB by non-phasing players happen at the start of next impulse/go. That actually changes the game rules/logic slightly (when returning units, it might be better known if a hex is safe or not). But the upside is huge, much less planning required, and complexity is much reduced.

-have AI make choices for the non-phasing player.(i.e taking over the job of the phasing player in our games)

-give the non-phasing player some handles to be able to adjust the AI to his liking (to some extent). What handles there should be of course depends on the AI implementation, but the AI SHOULD cater to taking external parameters from players. It's generally a bad idea to allow/encourage/require players to do to much micro-managing (= explicit decitions), because that will tend to break an AI. Good input to an AI could be things like: acceptableLossRatio(in expected lost BP vs. inflicted BP), maintaining<Unittype>ReserveHappiness (how much to keep back), agressiveness, <unittype>Highthened/LoweredValue (care less/more about keeping certain units alive), holdGroundStance (fighting a mobile defence vs. trying to hold the line), missionTypeImportance (lets AI know what enemy mission types you worry more about), etc. Players could also be allowed to assign simple flags (more/less value, save this unit, etc) to hexes/areas/individual units.

Anyways, the goal should be to have only a limited set of buttons for the player to play around with, and a decent "default" behaviour. Time spent tweaking the AI is not quality gametime for most people. Leaving certain things to the AI should not be a big turnoff as long as the AI isn't a perfect moron, and as long as the "other guy" also gets to have his perfect plan ruined by the AI.
First, I would like to keep a distinction between the AI that plays as an opponent (or partner) and the code that makes decisions on behalf of a player. To my mind the latter should only perform simple and straight forward tasks, not something that is too complicated. In any event, let's reserve the word AI for the opponent and use "standing orders" for the latter. I am not real happy with this choice of words but "programmed instructions", "scripts", and everything else I have thought of seem worse.

I have yet to start the thread on PBEM - Other which will include DOW and EOT. I haven't put my thoughts on these down coherently enough on paper yet. I hope to get it done by Monday.

Changing the order of play moving RTB to the start of a phase seems viable. It is just this sort of thing that made me decide to do the PBEM design as one of the first items to discuss. It could effect a lot of code. Probably we will want to make this an option. I am reluctant to impose my opinion on how people should play the game if alternatives can be provided without too much effort.

Some of your suggestions for what the AI should/should not be able to do are broader in scope than what I envision for standing orders. If what you are thinking about is having the AI play the Japanese while you play the Germans, then those ideas belong in a future thread about the AI as a partner. I probably can't get to that for a couple of months.

Most of your ideas in that paragraph are right on target and what we want to flesh out here. When you say parameters, the more specifics the better. How I interpret "acceptableLossRatio(in expected lost BP vs. inflicted BP)" might not be what you have in mind. By giving examples your meaning will be clearer so I get it correct. Simple flags on the other hand, even I can understand. Where I am headed is to define a data structure for standing orders that accommodates as much as possible, that isn't too confusing, and that can have a simple interface design so the players can give instructions easily.

The settings I describe are my suggestions for what you term standing orders. Based on experience, I do not think a limited toolbox of quite explicit standing orders will work well. There's just to much the phasing player can do, and way to often something will be left out/be extremely badly covered by explicit standing orders (an ochit, a paradrop, a lucky flip or whatever else can completely change what a good strategy is). That's based on experience, I played several PBEM games where I spent as much as 20-30 minutes/impulse writing explicit-type orders, and still more often than not something would pop up that made a mess of my orders. So gradually, I ended up realizing that I got my intercepts handled a lot better if I left more to the phasing player, and just gave general instructions. Whenever I did give explicit orders, they were sill as general as possible, and the opposing player was always allowed to override my orders if a reasonable justification could be made.

Thus, I think standing orders should be handled by something resembling a quite autonomous, fullblown AI capable of making reasonable choices on its own, but with a few some options to overrule or "push the AI in the right directions".

To elaborate on the flags/variables I suggested (and which are loosely based on the types of orders I found it useful to give my opponents:

-acceptableLossRatio(in expected lost BP vs. inflicted BP) By this I mean how happy I am to take losses/attrition. My opponent will use this to help decide for me whether or not to initiate battles/abort battles, plus also how to behave in naval battles (i.e. increase enemy losses or reduce own losses, think shortterm or longterm, what boxes to pick). For example, as Italy I usually let my opponent know that I need my expected losses to be about 0.5-0.6 of enemy expected losses for me to "want" to fight a battle. My CW usually has an acceptable ratio of 1.5 or higher. Of course, my opponent will also consider other issues than wether or not the attrition is within what I want (such as maintaining presence & supply) and will have to combine pros and cons and make a best judgement.

-maintaining<Unittype>ReserveHappiness (how much to keep back) By this I try to assign a value to how important I find it to maintain a reserve of some unittype, for instance bombers. If I make this a high value, my opponent should justify it well if he commits all my bombers. So I let him know that he can use some, but preferably don't use all.

-agressiveness By this I let my opponent know my stance on initiating battles. If I let him know I'm agressive, I'll expect him to intercept air missions more often/stronger, be more liberal with ground support, etc. In a nutshell, I tell him he's more free to commit "consumable" resources (i.e. planes, HQ support, etc that can only be used once befor it will be unavailable for the remainder of the turn. A good time to be agressive is when you have or can hope to achieve air superiority by drawing out enemy FTR, or it's late in the turn and you have oil to spend and feel your air bases are fairly safe from conquest.

-<unittype>Highthened/LoweredValue (care less/more about keeping certain units alive) I use this to let my opponent know what units I value the most, both for my own units and for enemy units. For example, I will often say to my opponent that he should be careful about risking my TRS and/or cp, or my SUBs or my CVs, or I could announce that CW BBs/LS are to be considered "ammunition". My opponent will then consider units to have higher/lower BP values than printed

-holdGroundStance (fighting a mobile defence vs. trying to hold the line) I use this to let my opponent know how I feel about such things as getting my units flipped, comitting short range air & HQ support(all of wich are much less preferable in a mobile defence)

-missionTypeImportance (lets AI know what enemy mission types you worry more about) I use this to let my opponent know better where to use my sparse units, particularly FTR cover. Sometimes I'm worried about ground strikes, other times a looming paradrop is more of a concern.
Yet other times I feel I have good enough control to intercept them pesky strat-bombers, and sometimes I'm definately not in the mood for port strikes or air transports.

Players could also be allowed to assign simple flags (more/less value, save this unit, etc) to hexes/areas/individual units. I use this to designate important hexes, for instance I sometimes reserve air units for reaction to particular sea boxes. Other times I let my opponent know some hexes I definately don't want to allow missions against and/or want to use my bombers to try to save, other times I let my oponent know that he shouldn't waste resources on certain places, for instance units left to their fate.


OK, hope that cleared up a bit what I meant [:)]


RE: Play by Email (PBEM) for MWIF

Posted: Mon Jul 18, 2005 1:39 am
by Shannon V. OKeets
Wonderful stuff. So far I have been reluctant to even start thinking about the non-phasing player's response to naval movement and combat and you have given us a great start on that topic.

Rather than go into detail for each of your order types, I want to back off and try to see a general structure that might fit. By the way, you have done a good job of convincing me that we need a more sophisticated system than "simple standing orders for each unit" to make good decisions for the non-phasing player during naval actions.

My frame of reference going into this is the language I developed for the Board of Internal Medicine to simulate the human body responding to disease and treatment. To give the doctors the flexibility they needed to model all the complexity therein, I came up with a rule based system that had two basic types of variables: ordinal and numeric. For our purposes the numeric variables could range from 0 to 100. The ordinal variables were a sequence of phrases (e.g., full renal failure, partial renal failure, normal renal function). We could use something like: all out attack, strong attack, and weak attack (for describing an opponent's land combat against a single hex), and major offensive, minor offensive, mixed offense/defense, and defensive (for describing an opponent's overall land moves and announced attacks). The AI assistant (AIA) for the non-phasing player would measure the numeric variables for the opponent's actions (% of bombers committed, % of fighters committed, % of units face up in reserve, etc., or simple counts of the same). From these values, AIA would determine values for the ordinal values (My God, its an all out attack by the CW in North Africa!). The third step would be to use the ordinal values (e.g., he is doing a major offensive and has an all out attack on such and such a hex) to determine a repsonse (e.g., concede the hex, give it some support, give it maximum support).

I am thinking that the way I commit resources has a lot to do with how the enemy is behaving. If he has a lot of uncommitted units and is repositioning them, then I do not want to use my reserves, but rather wait for the massive attack likely to come in the next impulse. This comes up quite often at the beginning of a turn, when the opponent is repositioning his forces, bringing reinforcements up to the front, and generally getting set for wrecking havoc the next impulse.

The non-phasing player could adjust the definitions of what constitutes a major offensive, major fleet commitment, annoying level of strategic bombing, etc., in terms of the numeric variables. MWIF would have starting values for all of these so the player doesn't have to grapple with the complexity cold. However, he can modify them to reflect his own value system. Likewise, he can set the level of his response to major offensives, et al, in terms of how he commits his sparse resources.

So, to summarize, what I currently envision is a list of numeric variables (parameters) that can be used in rules to set ordinal values (level of enemy commitment). Based on the level of enemy commitment, the AIA would use a second set of rules to decide on a level of response, and from that issue orders to individual units. The non-phasing player controls this apparatus at three points: (1) the rules that set the level of enemy commitment, (2) the level of response to each level of enemy commitment, and (3) the priority for which units are used in a response. He could also always mark some units as untouchable by the AIA. Or specifically task some units for certain roles regardless of what the AIA decides.

As I often do, I have created a structure that is both abstract and contains a lot of different parts. These usually get pared down to something smaller and simpler as we put it to practical use.

If this doesn't seem too extreme, I could use it to build rules for the order types you gave in your post.

RE: Play by Email (PBEM) for MWIF

Posted: Mon Jul 18, 2005 9:58 am
by c92nichj
ORIGINAL: Incy
You need to get it down to very few emails/turn. When we play, we do 1 save/impulse, and about 2-3 for EOT, plus usually one for important DOWs (where setup/alignment is critical). The phasing player decides what the non-phasing player does unless there's something really critical going on. Decitions are subject to notes(on units) and general intructions. We also have some special rules, most notably that RTB can be changed once the non-phasing player resumes control (effectively, it happens at the start of the next impulse, so a chasnge in sequence of play).

In a real PBEM game, I suggest:
-change sequence of play, all RTB by non-phasing players happen at the start of next impulse/go. That actually changes the game rules/logic slightly (when returning units, it might be better known if a hex is safe or not). But the upside is huge, much less planning required, and complexity is much reduced.
-have AI make choices for the non-phasing player.(i.e taking over the job of the phasing player in our games)

I have also played a fair bit of WIF PBEM and I agree on Incy's experiences we have pretty much the same ones, especially the one about getting down the email's to a minimum, it is more important to get the game moving somewhat than play a perfect game, in PBEM you're units will not perform exactly as you want them to it is a tradeoff against speed that you will have to make, on the other hand your opponent will suffer the same penalties so it will probably even out.

So far I like waht I am seeing around the PBEM discussions, I think this is going to be a great game!




RE: Play by Email (PBEM) for MWIF

Posted: Mon Jul 18, 2005 11:52 am
by Greyshaft
ORIGINAL: Shannon V. OKeets
I am expanding on the idea of having Matrix Games (or some other third party) host a small program that facilitates PBEM.
Check out http://pcwargames.com and see their interface for Rise & Fall. It works quite well for a 6 player game... admittedly with a simpler turn sequence [:D]

RE: Play by Email (PBEM) for MWIF

Posted: Fri Jul 22, 2005 12:00 am
by petracelli
Hi

I tihnk that the PBEM should reflect the way the game is played and not look to change the mechanics of it.

I played with four peoplpe i met via the wif list a play by email game where by we were writing down where the units had moved to and resolving the combats on line. This included people in both the US and Europe and although we only got to early 1940 think it broke donw beacuse of the mvoing of coutners and writing them down and one guy having to pull out.

The ability of the computer is that you can have more than one game going on at any one time and the propsect of playing two or three wif games is great.

As for cheating would to begin with be playing with people i know and would trust them not to cheat. When we played by email just used an on line dice simulator which sent the rolls to everyone and assume you could incoporate the same system.

regards

Phil

RE: Play by Email (PBEM) for MWIF

Posted: Fri Jul 22, 2005 7:01 am
by c92nichj
ORIGINAL: petracelli
I think that the PBEM should reflect the way the game is played and not look to change the mechanics of it.

I played with four peoplpe i met via the wif list a play by email game where by we were writing down where the units had moved to and resolving the combats on line. This included people in both the US and Europe and although we only got to early 1940 think it broke donw beacuse of the mvoing of coutners and writing them down and one guy having to pull out.

How long did it take you to get to early -40's and how many interaction emails was required? Playing CWIF by email 39 and 40 goes quite quickly as usually there are quite onesided type of campaigns against opponents who dont use air (Poland, Denmark Netherlands, some attacks in China) . French campaign takes lonmger and when you get into russia things will really be slow unless you have some way to speed things up. Changed EOT sequence, and an AI-assistant for resolving non-phasing player stuff will make things a lot easier in my opinion.

RE: Play by Email (PBEM) for MWIF

Posted: Sun Jul 31, 2005 1:48 am
by Shannon V. OKeets
I have created this document based on the multiple threads about PBEM. If you would like a nice copy (with colors) that is in PDF format, send an email to: Steve@PatternDiscovery.us.
------------------------------------------------

Proposed Design for Play by Email (PBEM)
(as of July 30, 2005)

This is a first draft of the complete design for the PBEM system.

Background
As general background, MWIF controls what the player can do at any point in the game by proceeding through the sequence of play in the World in Flames’ Rules as Written 7 (RAW). During each phase/subphase the player is only able to make decisions, move units, build units, and so on, if those actions are appropriate for that phase/subphase. The player controls when a phase is complete by clicking on a “phase complete” button. Control is passed back and forth between the players by MWIF, and in some phases a player has nothing to do because MWIF is waiting on his opponent to move (or make some decision).

One of the concerns with PBEM is that it will take too long to play a game because of the numerous changes in control in the RAW sequence of play. If RAW is implemented faithfully for PBEM, there will be literally hundreds (or thousands) of emails needed to play a single game. To make the PBEM system more efficient, a revised sequence of play is needed that reduces the number of emails substantially.

Elements of PBEM
One of the big differences between playing MWIF live over the Internet and playing by email, is rolling the dice. During an Internet game MWIF can roll the dice and show the results to everyone immediately. In a PBEM game that is not possible; so a solution is needed to prevent the players from repeatedly rolling the dice until a favorable result is achieved. To do that, MWIF ships with eMWIF, a small program that runs separately from MWIF.

eMWIF exists for one purpose: to roll the dice and report the result to all the players in the game. eMWIF can be run on any host Internet server and Matrix Games runs a copy that is available to everyone. You can run eMWIF on some another system if you like. When you start a PBEM game, you ‘register’ it with eMWIF, identifying who is playing what countries. As you play the game there will be times when you need a random number (e.g., rolling for weather). At that point MWIF will send a query to eMWIF over the Internet, asking for a random number. eMWIF will validate that the player is in the game and that he is scheduled for asking for a random number for the specific event. By this I mean that eMWIF will know where in the sequence of play the players are and who should be doing what next. Once the request is validated, eMWIF will roll the dice and send the results to all players. This means that players cannot cheat since the dice are only rolled once. Note that the communications between MWIF and eMWIF are automated and require no action by the player.

At the start of a PBEM game each player will set up an ‘INI’ file that lists all the players in the game with their email addresses. It will also contain the Internet address of the eMWIF ‘dice roller’. Once the scenario, optional rules, and sides have been decided by the players, MWIF will register the game with the eMWIF dice roller.

During a PBEM game, each player will be running a copy of MWIF. Each copy will send emails to the other players in the game, as well as eMWIF. The emails will be generated by MWIF when the player clicks on “phase complete”. From the player’s point of view he could just as easily be playing over the Internet or playing solitaire. The process for completing a phase will be the same. However, the sequence of play will be different, as discussed in detail below.

Types of Email
The PBEM system operates with three types of email. The most common, Sequential, is when a player completes a phase and sends his decisions (e.g., moves) to the other player(s). This type of email transfers control to the other player. That is, the other player now becomes the phasing player and makes his decisions.

The second type of email, Simultaneous, occurs when multiple players are making decisions at the same time. For example, production is done simultaneously by all players. This second type does not transfer control directly from one player to another. Instead, MWIF waits until all the players have sent their emails denoting “phase complete”. Then, and only then, does it reveal the other players’ decisions/actions. What this means in practice is that a player may receive an email from an opponent (say, about production), but be unable to read its contents until he has sent off his own email that contains all his own production decisions. In a game with more than 2 players Simultaneous emails can cause delay because MWIF waits until everyone has sent in their emails.

The third type of email, Announcements, are generated by MWIF. These are generated when MWIF determines: who has the initiative at the start of a new turn, that the end of turn has occurred, and that the end of game has occurred.

Standing Orders
In order to eliminate emails, most decisions by the non-phasing player are handled using Standing Orders (SO). Each player selects a specific standing order from a list and sets its parameters. When a player completes a phase, he is prompted by MWIF to review his SOs to make sure they are up-to-date. MWIF uses those SOs to make decisions when the opponent is the phasing player.

SOs occur in many places and the choices from which to choose will be different for each place. At this point, the choices and their parameters have yet to be worked out. The portion of MWIF which executes SOs is referred to as the AI Assistant (AIA). The AIA makes decisions on behalf of the player, but is [indirectly] under the control of the player.

Nomenclature
The references to the rules in the sequence of play are to RAW 7. The emails are labeled by game segment:
S1 - S3 are for setting up units.
W1 - W3 are for declarations of war.
P1 is for passing.
A1 is for air actions.
N1 - N5 are for naval actions.
L1 is for land actions.
E1 - E8 are for end of turn/game.

PBEM Sequence of Play
What follows is a very detailed list of the sequence of play for PBEM and the emails that are generated by the players and MWIF. All emails are colored blue. Branching logic is colored red and refers to the numbers in the left hand margin. Emails to eMWIF are colored purple. Standing Orders are colored green. Be sure to read the notes at the end.

---------------------------------------------------- Start of Game
&#8729;&#63568; Email communications to decide who is playing, scenario, optional rules, bidding for countries, and choosing countries (MWIF facilitates bidding if so desired). Game is registered with eMWIF.
---------------------------------------------------- Set Up
&#8729;&#63568; Email S1 from Italy: 1 => 3.1
1 Setup (Rules 24.1)
2 Reinforcements (Rules 4.0)
2.1 Force pool changes (Rules 4.1)
2.1.1 Remove Air Units (Rules 4.1.3)
2.1.2 Replacement naval units (Rules 4.1.4) Option 67
2.2 Placing reinforcements (Rules 4.2)
3 Lending Resources (Rules 5.0)
3.1 Trade agreements (Rules 5.1)
&#8729;&#63568; Email S2 from all Allies: 1 =>3.1
&#8729;&#63568; Email S3 from Japan & Germany: 1=> 3.1
--------------------------------------------------- Action Stage
&#8729;&#63568; Email W1 from side with the initiative: 5 => 7.4 (scenarios always state who starts with the initiative)
5 Action stage (Rules 7.0) - repeat 6 through 12 until end of turn
6 Weather, only when player with initiative is phasing player (Rules 8.0) - eMWIF
7.1 Declare War (Rules 9.0)
7.1.1 US entry check (Rules 9.4); roll is made immediately and USA player decides where to place a chit the next time he is the phasing player - eMWIF
7.1.2 Neutrality pacts (Rules 9.5) - Checked by MWIF
7.1.4 Control new minor countries (Rules 9.7) - SO
7.1.5 Aligning minor countries (Rules 9.8)
7.1.6 Japanese occupation of Indo-China (Rules 9.10)
7.2 Nazi-Soviet pact (Rules 19.5)
7.3 Soviet border rectification (Rules 19.6)
7.3.1 The USSR claims the Finnish borderlands (Rules 19.6.1)
7.3.2 The USSR claims Bessarabia (Rules 19.6.2)
7.4 The Ukraine (Rules 19.12) Option 62
&#8729;&#63568; Email W2 from non-phasing player to set up reserves (e.g., attacked minors such as Poland) and respond to Soviet border claims: 7.1.3, 7.3 - in some cases SO are used instead.
7.1.3 Calling out the reserves (Rules 9.6)
7.3 Soviet border rectification (Rules 19.6)
7.3.1 The USSR claims the Finnish borderlands (Rules 19.6.1)
7.3.2 The USSR claims Bessarabia (Rules 19.6.2)
&#8729;&#63568; Email W3 from phasing player: 7.5 => 11
7.5 Choose action (Rules 10.0)
--------------------------------------------- Movement and Combat
One of more of the following Action Phases occur depending on the action chosen by the phasing player. Note that parts of the Air Actions can occur during Naval and Land Actions.
--------------------------------------------- Pass Action
&#8729;&#63568; Email P1 from phasing player: 8.1
8.1 Passing (Rules 11.1)
Go to 12
--------------------------------------------- Air Action
&#8729;&#63568; Email A1 from phasing player: 9.1 => 9.15
9.1 Combat air patrol, CAP (Rules 14.2.1)
9.2 Port attacks (Rules 11.2) see X.1 => X.5 in Air Action
9.3 Naval air missions (Rules 11.3) see X.1 => X.5 in Air Action
9.4 Strategic bombardment (Rules 11.7) see X.1 => X.5 in Air Action
9.5 Carpet bombing (Rules 11.8) see X.1 => X.5 in Air Action
9.6 Ground Strike (Rules 11.9) see X.1 => X.5 in Air Action
9.7 Rail movement (Rules 11.10)
9.8 Air transport (Rules 11.12) see X.1 => X.5 in Air Action
9.9 Paradrop (Rules 11.15) see X.1 => X.5 in Air Action
9.10 Shore bombardment (Rules 11.16.2)
9.11 Ground support (Rules 11.16.4) see X.1 => X.5 in Air Action
9.12 Aircraft rebases (Rules 11.17)
9.13 Air resupply (Rules 11.18.1) see X.1 => X.5 in Air Action
9.14 HQ reorganization (Rules 11.18.2)
9.15 TRS resupply (Rules 11.18.3)
Go to 12
--------------------------------------------- Air Combat
The sequence X.1 => X.5 takes place when any of the actions listed in X.4 occur
X.1 Committing air units to combat
X.1.1 Non-phasing player flies CAP to hex or sea box (Rules 14.2.1) - SO
X.1.2 Phasing player flies air units to hex or sea box (Rules 14.1)
X.1.3 Non-phasing player flies air units to hex or sea box (Rules 14.1) - SO
X.1.4 Phasing player flies interceptors (Rules 14.2.1)
X.2 Air to air combat (Rules 14.3)
X.2.1 Phasing player arranges fighters and bombers (Rules 14.3.1)
X.2.2 Non-phasing player arranges fighters and bombers (Rules 14.3.1) - SO
X.2.3 Roll for non-phasing player’s attacks (Rules 14.3.2) - eMWIF
X.2.4 Choose planes lost, damaged, and/or cleared through (Rules 14.3.3) - SO
X.2.5 Roll for phasing player’s attacks (Rules 14.3.2) - eMWIF
X.2.6 Choose planes lost, damaged, and/or cleared through (Rules 14.3.3) - SO
X.2.7 Phasing player decides whether to continue (Rules 14.3.3)
X.2.8 Non-phasing player decides whether to continue (Rules 14.3.3) - SO
If both players decide to continue air to air combat, go to X.2.1. Otherwise
X.3 Anti-air (Rules 11.2, 11.5.9, 22.4.2) Option 3
X.3.1 Anti-air combat on attacker’’s planes - eMWIF
X.3.2 Anti-air combat on defender’’s planes (occurs in naval air attacks) - eMWIF
X.4 Air bombardment (port attack, naval air attack, ground strike, ground support, strategic bombing, or carpet bombing), paradrop, or air supply - eMWIF
X.5 Return to base
X.5.1 Phasing player returns planes to base (Rules 14.3.2)
X.5.2 Non-phasing player returns planes to base (Rules 14.3.2) - SO
--------------------------------------------- Naval Action
&#8729;&#63568; Email N1 from phasing player: 10.1 => 10.4.1
10.1 Port attacks (Rules 11.2) see X.1 => X.5 in Air Action
10.1.1 Search - eMWIF
10.1.2 Surprise points - SO
10.2 Naval air missions (Rules 11.3) see X.1 => X.5 in Air Action
10.3 Naval movement (Rules 11.4)
10.3.1 Task forces (Rules 11.4.3)
10.3.2 Naval transport (Rules 11.4.5.)
10.3.3 Naval interception (Rules 11.4.6) - SO
10.4 Naval combat initiated by phasing player (Rules 11.5)
[&#8729;&#63568; Email N5 from phasing player: 10.4.1], for multiple naval combat rounds and naval combats
10.4.1 Adding naval air units by phasing player (Rules 11.5.3)
&#8729;&#63568; Email N2 from non-phasing player: 10.4.2 => 10.4.6
10.4.2 Non-phasing player adds naval air units (Rules 11.5.3)
10.4.3 Non-phasing player commit subs (Rules 11.5.4)
10.4.4 Non-phasing player search (Rules 11.5.5) - eMWIF
10.4.5 Non-phasing player chooses sea box, when permitted (Rules 11.5.5)
10.4.6 Non-phasing player uses surprise points, when permitted (Rules 11.5.6)
&#8729;&#63568; Email N3 from phasing player: 10.4.7 => 10.4.13
10.4.7 Phasing player chooses sea box, when permitted (Rules 11.5.5)
10.4.8 Phasing player uses surprise points, when permitted (Rules 11.5.6)
10.4.9 Choose combat type (Rules 11.5.7) - SO
10.4.10 Naval surface combat (Rules 11.5.8) - eMWIF
10.4.11 Naval air combat (Rules 11.5.9) see X.1 => X.5 in Air Action
10.4.12 Submarine combat (Rules 11.5.10) - eMWIF
10.4.13 Phasing player takes and inflicts losses in naval combat, when permitted
&#8729;&#63568; Email N4 from non-phasing player: 10.4.14 => 10.4.16
10.4.14 Non-phasing player takes and inflicts losses in naval combat, when permitted
10.4.15 Phasing player aborts naval combat (Rules 11.5.11) - SO
10.4.16 Non-phasing player aborts naval combat (Rules 11.5.11)
If both sides decide to continue naval combat in this sea area, go to 10.4.
Otherwise
If more sea areas were selected by the phasing player go to 10.4 (for the next sea area). Otherwise
10.5 Naval combat initiated by non-phasing player (Rules 11.6) - SO
Repeat same sequence as for 10.4
Go to 12
--------------------------------------------- Land Action
&#8729;&#63568; Email L1 from phasing player: 111 => 11.10

11.1 Rail Movement (Rules 11.10)
11.2 Land Movement (Rules 11.11)
11.2.1 Overrun (Rules 11.11.6 )
11.2.2 Forced Air Rebase - SO
11.2.3 Forced Naval Rebase - SO
11.2.4 Overstacked Losses - SO
11.3 Air Transport (Rules 11.12)
11.4 Unload Land Units from Ships (Rules 11.13)
11.5 Invasion (Rules 11.14) see X.1 => X.5 in Air Action
11.6 Paradrop (Rules 11.15) see X.1 => X.5 in Air Action
11.7 Land Combat (Rules 11.16)
11.7.1 Land Combat Declaration (Rules 11.16.1)
11.7.2 Shore Bombardment D (Rules 11.16.2) Option 38 - SO
11.7.3 Shore Bombardment A (Rules 11.16.2)
11.7.4 Emergency HQ Supply (Rules 2.4.2) Option 6 - SO
11.7.5 HQ Support Defender (Rules 11.16.3) Option 13 - eMWIF - SO
11.7.6 HQ Support Attacker (Rules 11.16.3) Option 13 - eMWIF
11.7.7 Ground Support (Rules 11.16.4) see X.1 => X.5 in Air Action - SO
11.7.8 Ignore Notional Unit - SO
11.7.9 Land Combat Resolution (Rules 11.16.5)
11.7.9.1 Choosing Tables - SO
11.7.9.2 Rolling the dice for combat results - eMWIF
11.7.9.3 Choosing Losses - SO
11.7.9.4 Path of Retreat
11.7.9.5 Advance after combat
11.7.9.6 Forced Air Rebase - SO
11.7.9.7 Forced Naval Rebase - SO
11.7.9.8 Overstacked Losses - SO
11.8 Air Rebase (Rules 11.17) see X.1 => X.5 in Air Action
11.9 Air Supply (Rules 11.18.1) see X.1 => X.5 in Air Action
11.10 Reorganization (Rules 11.18)
11.10.1 HQ Reorganization (Rules 11.18.2)
11.10.2 TRS Supply (Rules 11.18.3)
Go to 12
--------------------------------------------- Combined Action
This action choice is a combination of 9, 10, and 11 above.
Go to 12
--------------------------------------------- End of Turn Test 12 Last impulse test (Rules 12) - MWIF decides
If not end of turn, switch who is phasing and non-phasing and go to 5.
Otherwise
--------------------------------------------- End of Turn
End of Turn Stage (Rules 13)
13.1 Partisans (Rules 13.1) Option 46 - eMWIF
&#8729;&#63568; Email E1 from MWIF to both players announcing End of Turn (and Partisans, if any)
&#8729;&#63568; Email E2 from both sides: 9.1 (if partisans appeared)
&#8729;&#63568; Email E3 from both sides: 9.2 => 9.3.3
13.2 Entry markers (Rules 13.2) - eMWIF
13.3 US entry (Rules 13.3) - part of the USA (only) email
13.3.1 Entry markers (Rules 13.3.1) - eMWIF
13.3.2 US entry options (Rules 13.3.2)
13.3.3 US entry actions (Rules 13.3.3)
&#8729;&#63568; Email E4 from side that had the initiative this turn: 9.4
13.4 Return to base or stay at sea (Rules 13.4)
&#8729;&#63568; Email E5 from side that did not have the initiative this turn: 9.4
13.4 Return to base or stay at sea (Rules 13.4)
&#8729;&#63568; Email E6 from both sides: 9.5 => 14, 2 => 4
13.5 Final reorganization (Rules 13.5)
13.5.1 Use oil (Rules 13.5.1) Option 48
14 Production (Rules 13.6)
14.1 Breaking down units (Rules 22.4.1) Option 2
14.2 Building units (Rules 13.6.5) - eMWIF randomly selects units from force pool
14.3 Intelligence (Rules 22.1) Option 63
14.4 Factory Destruction (Rules 22.2) Option 30
14.5 Reforming units (Rules 22.4.1) Option 2
15 Peace (Rules 13.7) - MWIF decides
15.1 Conquest (Rules 13.7.1) - MWIF decides
15.2 Allied support (Rules 13.7.2) - MWIF decides
15.3 Mutual peace (Rules 13.7.3) - either side can offer mutual peace. If this happens then the other side needs to respond with an email either accepting or rejecting the offer.
15.4 Vichy declaration (Rules 13.7.4)
15.4.1 Creation (Rules 17.1)
15.4.2 Determine control (Rules 17.2)
15.4.3 Setup Vichy units (Rules 17.3)
16 Liberation (Rules 13.7.5)
17 Surrender (Rules 13.7.6)
18 Victory check (Rules 13.8) - MWIF decides
If End of Game, go to 19 below.
Otherwise
--------------------------------------------- Reinforcements & Initiative
2 Reinforcements (Rules 4.0)
2.1 Force pool changes (Rules 4.1)
2.1.1 Remove Air Units (Rules 4.1.3)
2.1.2 Replacement naval units (Rules 4.1.4) Option 67
2.2 Placing reinforcements (Rules 4.2)
3 Lending Resources (Rules 5.0)
3.1 Trade agreements (Rules 5.1)
4 Initiative (Rules 6.0) - both players provide standing orders for rerolls and deciding who has the initiative to start the next turn - SO
&#8729;&#63568; Email E7 from MWIF to both players announcing who has initiative
Go to 5 above
--------------------------------------------- End of Game
19. End of game
&#8729;&#63568; Email E8 from MWIF to both players announcing who won
------------------------------------------------

Notes
I. Air combat can occur in 3 places during a Naval action, 5 places during a Land action, and 9 places during an Air action. For each of these ‘places’ there can be several combats (e.g., several ground strikes). Clearly this has the potential for making PBEM take a long time. Therefore, I have removed from PBEM the options: #22 Bounce, #51 En-route aircraft interception, and #57 Limited aircraft interception. I have also required Standing Orders for all non-phasing player decisions during air combat so the air combat sequence can be completed without any emails. These decisions detract from keeping PBEM faithful to WIF, so I do them reluctantly. However, I believe they are essential to keep PBEM from taking excessively long to play (i.e., dozens of emails per impulse).

II. S1 - S3 are based on the Global War scenario. These may be different for the other scenarios.

III. W2 does not occur unless the phasing player declares war and the non-phasing player needs to set up units in response. Additionally, if there are Standing Orders for how to set up units for the small minor countries (e.g., Iran), then this email can also be skipped. If W2 is not needed, then the phasing player combines W1 and W3 into a single email.

IV. The Pass, Air, and Land actions are done with a single (one, 1, uno) email. Naval actions might take a lot of emails because there are several for each round of each combat. However, naval combat is much less frequent than land and air combat. In addition the build point cost of losing ships is high. Because of this expense the players should have more control in deciding the type of combat, how to use surprise points, losses, and return to base. Finally, control of sea areas is vital for maintaining supply to units, preparing for and defending against invasions, and for shipping resources to factories. Given all these crucial factors, the relatively high number of emails for naval combat seems warranted.

V. As the phasing player proceeds through his turn and request die rolls from eMWIF, MWIF builds the email that is later sent to the opponent. Each email will contain all the decisions (moves) that the phasing player made. The phasing player is still able to undo moves/decisions right up to the point where he either: (1) requests a die roll from eMWIF, or (2) takes an action that causes a SO to be activated. For example, when the phasing player tries to move surface naval units through a sea area that the other side could possibly search, then he is committed to that move as soon as he exits the sea area. This is because passing through a sea area entitles the non-phasing player to perform a search. The decision whether to search or not is made by the AIA on behalf of the non-phasing player. It does not matter whether the AIA, using the SO, decides to search or not. Simply because the SO was consulted by the AIA means that the move can no longer be undone.

VI. Overruns can result in air and naval units having to rebase. The non-phasing player can just let the AIA make these decisions. Alternatively, he can use a SO to give a rebase destination (hex or prioritized hex list) for each of his units prior to the phasing player’s move, just in case they get overrun. Likewise he can let the AIA decide which units to eliminate if overstacking is caused when units have nowhere else to retreat.

VII. In land combat, choosing tables and choosing losses is very important. Therefore, the standing orders for these decisions will include a variety of ways for the player to instruct the AIA how to make them.

VIII. In air combat, choosing tables and choosing losses is very important. Therefore, the standing orders for these decisions will include a variety of ways for the player to instruct the AIA how to make them.

IX. I am assuming that Hidden Task Forces (Optional rule #21) are not permitted.

X. One of the things that I do as a player, while waiting for my opponent to move, is think about what I am going to have my units do next. To facilitate this activity for PBEM players who want to study a game while waiting for slow opponents, I am designing a preplanned decisions capability into MWIF. [Opponents are always way too slow, while we are always properly careful. Any errors in judgment we make are because we were hurried by impatient opponents.] By preplanned decisions (PD) I mean the ability to move units around on the map, plan out your production, or any other aspect of the game. Any moves/decisions made as PD don’t actually happen until you ok them later. As an example, you are playing Germany in Barbarossa and have just inflicted devastating attacks on the USSR during your first impulse. While waiting for the USSR player to figure out his moves and send them back in an email, you can move the USSR units around on the map (“I think he will do this.”) and move your units around in response. Essentially you are planning out your moves. When the USSR email finally arrives, your game map will be restored so all the units are in their proper hexes and then updated with the USSR moves. At that point you can call up your PD and MWIF will display them to you one decision at a time, asking whether you still want it to happen. You can say yes or no. You will be informed by MWIF of any decisions that became invalid because of the opponents actions. There are a lot of details I need to work out for PD, but I think they would make PBEM more enjoyable and maybe even faster since players could make some obvious decisions in advance (e.g., what to build).

RE: Play by Email (PBEM) for MWIF

Posted: Sun Jul 31, 2005 7:54 am
by Froonp
I. Air combat can occur in 3 places during a Naval action, 5 places during a Land action, and 9 places during an Air action. For each of these ‘places’ there can be several combats (e.g., several ground strikes). Clearly this has the potential for making PBEM take a long time. Therefore, I have removed from PBEM the options: #22 Bounce, #51 En-route aircraft interception, and #57 Limited aircraft interception. I have also required Standing Orders for all non-phasing player decisions during air combat so the air combat sequence can be completed without any emails. These decisions detract from keeping PBEM faithful to WIF, so I do them reluctantly. However, I believe they are essential to keep PBEM from taking excessively long to play (i.e., dozens of emails per impulse).
May I suggest that you code Bounce & En-route intercept into the PBEM game too, but that you STRONGLY advise the PBEM player from choosing that options, warning them that it will slow the game very much ?

RE: Play by Email (PBEM) for MWIF

Posted: Sun Jul 31, 2005 8:18 am
by Froonp
X. One of the things that I do as a player, while waiting for my opponent to move, is think about what I am going to have my units do next. To facilitate this activity for PBEM players who want to study a game while waiting for slow opponents, I am designing a preplanned decisions capability into MWIF. [Opponents are always way too slow, while we are always properly careful. Any errors in judgment we make are because we were hurried by impatient opponents.] By preplanned decisions (PD) I mean the ability to move units around on the map, plan out your production, or any other aspect of the game. Any moves/decisions made as PD don’t actually happen until you ok them later. As an example, you are playing Germany in Barbarossa and have just inflicted devastating attacks on the USSR during your first impulse. While waiting for the USSR player to figure out his moves and send them back in an email, you can move the USSR units around on the map (“I think he will do this.”) and move your units around in response. Essentially you are planning out your moves. When the USSR email finally arrives, your game map will be restored so all the units are in their proper hexes and then updated with the USSR moves. At that point you can call up your PD and MWIF will display them to you one decision at a time, asking whether you still want it to happen. You can say yes or no. You will be informed by MWIF of any decisions that became invalid because of the opponents actions. There are a lot of details I need to work out for PD, but I think they would make PBEM more enjoyable and maybe even faster since players could make some obvious decisions in advance (e.g., what to build).
[&o]

That's the greatest idea since Standing Orders !!!!
I could advocate that this idea should be also kept for the TCP/IP games too, as the slow player syndrome can happen there too.

One last thing, about Standing Orders, there should be a dialog that appears just before you end up your current phase asking you whenever you're also finished with your standing orders too. It could also display a list (a table) showing the units with standing orders and a maybe even what their standing orders are.

Best Regards

Patrice

RE: Play by Email (PBEM) for MWIF

Posted: Sun Jul 31, 2005 8:27 am
by Shannon V. OKeets
ORIGINAL: Froonp
I. Air combat can occur in 3 places during a Naval action, 5 places during a Land action, and 9 places during an Air action. For each of these ‘places’ there can be several combats (e.g., several ground strikes). Clearly this has the potential for making PBEM take a long time. Therefore, I have removed from PBEM the options: #22 Bounce, #51 En-route aircraft interception, and #57 Limited aircraft interception. I have also required Standing Orders for all non-phasing player decisions during air combat so the air combat sequence can be completed without any emails. These decisions detract from keeping PBEM faithful to WIF, so I do them reluctantly. However, I believe they are essential to keep PBEM from taking excessively long to play (i.e., dozens of emails per impulse).
May I suggest that you code Bounce & En-route intercept into the PBEM game too, but that you STRONGLY advise the PBEM player from choosing that options, warning them that it will slow the game very much ?
Well, I'll put them on a "maybe" list instead of a "definitely not" list.

The bounce routine has so many options that writing a SO for it would be complicated. The enroute interception option provides more ways to defend against bombing missions and therefore it also makes writing a SO more complex.

These optional rules would add more realism to PBEM, but at the expense a lot more work on the part of the players defining SOs. I just don't see most players using them. If they are only going to be used by a few grognards, then I would just as soon omit them from PBEM.

RE: Play by Email (PBEM) for MWIF

Posted: Sun Jul 31, 2005 8:28 am
by Grotius
I also like the idea of planning orders while waiting for the other person's turn. Neat.

RE: Play by Email (PBEM) for MWIF

Posted: Sun Jul 31, 2005 3:45 pm
by Shannon V. OKeets
ORIGINAL: Froonp
That's the greatest idea since Standing Orders !!!!
I could advocate that this idea should be also kept for the TCP/IP games too, as the slow player syndrome can happen there too.

I am glad you like it. Now I just have to code PD so the game interface handles them nicely.
ORIGINAL: Froonp
One last thing, about Standing Orders, there should be a dialog that appears just before you end up your current phase asking you whenever you're also finished with your standing orders too. It could also display a list (a table) showing the units with standing orders and a maybe even what their standing orders are.

Patrice

From the 1st draft:
Standing Orders
In order to eliminate emails, most decisions by the non-phasing player are handled using Standing Orders (SO). Each player selects a specific standing order from a list and sets its parameters. When a player completes a phase, he is prompted by MWIF to review his SOs to make sure they are up-to-date. MWIF uses those SOs to make decisions when the opponent is the phasing player.

How to display the standing orders has to be defined. Hey, standing orders themselves have to be defined.

The former is part of the game interface. Indeed, I scheduled the PBEM design task early because I knew we would need it for the game interface design.

The latter is the next task for the PBEM design.