Play by Email (PBEM) for MWIF

Play by Email (PBEM) for MWIF (Full Version)

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

Message

Shannon V. OKeets -> Play by Email (PBEM) for MWIF (7/12/2005 8:29:32 PM)
Play by Email (PBEM) for MWIF Summary This post starts a discussion on PBEM for MWIF. It contains four sections: motivation, random numbers, cheating, and minimizing the number of emails. You might wonder why I am choosing to start a thread on PBEM before one on the game interface. After all, the game interface is much more interesting and everyone will have opinions on good and bad features. The reason PBEM comes first is that it will probably require a different processing logic (i.e., code) to support a sequence of play that minimizes the number of emails. I need the design of the sequence of play locked in before designing the game interface. The interface will support the sequence of play and for that reason depends on the definition of the sequence of play. The question for this thread, and it’s future associated threads, is how to do PBEM for MWIF. I have some ideas. For purposes of this discussion I am assuming that there are only two players: A and B. If PBEM can be worked out for two players, then extending it for multiple players shouldn’t be that hard. These ideas are not as well thought out as I would like, so feel free to be critical, but be gentle in your critiques. Hopefully we can evolve all our ideas into a final design for PBEM. Motivation There are some players who believe working on a PBEM capability is a waste of time. Two reasons are usually given: (1) most players will have little interest and (2) the game would have to be changed too much to make PBEM viable. Indeed, as Greyshaft commented, to follow the WiF sequence of play exactly could make a PBEM game play in real time - that is, it would take 6 years, plus or minus a couple of weeks, to complete a game. However, there will be Players who value the PBEM version because it gives them flexibility in scheduling their playing time. This applies to individuals who live in remote areas of the globe and will have difficulty finding opponents within their time zone for simultaneous play over the Internet. This also applies to people who can only fit in an hour or so during lunch or in the evening rather than the 4 hours (suggested minimum) for an on-line session playing the Internet version. As for how long one game will take, I use to play chess by snail mail and I would typically have 2 dozen games in progress at any one time. With only one move a week, each game would take over a year, but I was playing chess every day because of the sheer number of games I had going. When I played Diplomacy by email, I had two games in progress simultaneously, which kept me busy communicating with the 6 other players in each game. It seems likely to me that some players will have more than one game of MWIF going at once and I intend for MWIF to be able to identify which emails are for which games and keep everything straight without the players having to worry about such matters. Random Numbers The first problem is how to generate random numbers for the myriad of dice rolls such that each player’s MWIF copy performs the rolls identically yet neither player can ‘test’ different actions using the computer to see how the dice are going to land. MWIF has to be able to roll the dice and yet it cannot be able to roll the dice, lest it permits a player to cheat. I have not played wargames by email (only Diplomacy once upon a time, which does not require a random number generator) and I am not familiar with the current approaches taken to this problem. Given my ignorance, forgive me for putting forth one solution that I believe is viable. But before I do that, let me digress into the issue of random numbers. If you have no interest in the randomness of random numbers, I strongly suggest you skip ahead to the next paragraph! On random numbers in general, I was trained by a PhD in statistics to be very leery of the randomness of pseudo-random number generators (RNGs). When I need software to create random numbers I use two random number generators and a matrix. Just to get started, I have both random number generators produce several thousand random numbers which I discard immediately. I then have the first (RNG1) produce 10,000 numbers which I place in a 100 by 100 matrix. When the simulation needs a random number, RNG2 produces an I index (0 to 99) and a J index into the matrix, and returns the number it finds at that location. RNG1 produces a new random number to fill the hole in the table. The use of two RNGs and the matrix look up procedure add another level of disassociation from the internal workings of the CPU’s hardware. My paranoia is that the hardware will loop after only a small number of iterations instead of (2 to the N) minus 1, like it is suppose to. Cheating I have a way for MWIF to generate dice rolls without either player being able to cheat. Player A sends a set of decisions to Player B via email. When B‘s copy of MWIF reads the email containing A’s decisions, it will automatically generate a random number (based on time of receipt) for the dice roll(s) and send an email to A containing the dice roll(s). The important thing here is that MWIF will not show neither A’s decisions nor the result of the dice roll(s) to B until after it is sure the email with the dice roll(s) was send to A. A needs B to roll the dice; the dice depend on time of B’s receipt; and B doesn’t know what has happened until after A is assured of seeing the same dice results. I think this is bullet proof against the standard cheat of saving a copy of a game before rolling the dice and restoring to the older version if the results don’t go the way you want them to. Another possibility is as follows. During a game, A and B will be exchanging a lot of emails. MWIF could always embed random numbers in the messages at time of transmission so they would be available if needed. This would all be invisible to the players; they would not have to record any numbers on paper or some such. Internal to the game in progress, or saved game, MWIF would keep track of all these numbers and use them for dice rolls whenever necessary. From the players’ point of view, they would simply be unable to get the dice to roll until the opponent sends back an email. Minimizing the number of emails The PBEM version should offer the option of changes in the sequence of play to reduce the number of emails needed to play through a turn. Using this option would mean that the game would not be a ‘pure’ replication of WiF, though we should be able to get it reasonably close. If the players agree that a strict adherence to RAW 7 requires too many emails to resolve a turn, then MWIF could offer the option of “standing orders”. This seems to be a viable alternative for committing, for example, fighters. Each fighter (either by unit or stack of units) would have standing orders to perform certain actions in response to the phasing player’s actions (i.e., the opponent’s move). One action might be to defend a hex, or area, against strategic bombing, paradrops, port attacks, etc.. While making these assignments for all your air units might seem a daunting task at first, it would occur incrementally during play with players merely modifying previous standing orders as new units arrive or conditions change. During slow turns (e.g., winter weather conditions) very little would need to be done. A player could specify up to three or four standing orders (with a priority list) for each unit/stack of units. This would take the non-phasing player out of the communication loop for decision making. However, he would still need to be involved for generating dice rolls. We don’t want the phasing player to be able run test attacks to discover what the standing orders are. To that end, the standing orders for the non-phasing player’s units would have to be encrypted with the non-phasing player providing the key once the phasing player commits to a set of attacks. MWIF might have to encrypt the standing orders multiple times using a different key for each action segment. This means that the phasing player would learn about fighters committed to port attacks only when he attacks ports. Even after attacking ports he would not know what fighters were committed to defending ports except for those he attacked. When he goes on to the next action segment and commits more of his planes, he would receive the second key from the non-phasing player for, say, defending against strategic bombing. The way I see this working is the non-phasing player issues standing orders and sends them (encrypted) to the phasing player. The phasing player proceeds through the action segments and he commits to a set of attacks. He sends them to the non-phasing player who returns one of the keys for the standing orders, as well as the dice roll(s). Both players can then resolve combats. The phasing player then proceeds to the next action segment. The non-phasing player does not have any decisions to make; he is simply providing dice roll(s) and the keys to his standing orders as the phasing player proceeds through all the action segments. I hope I can find a way to have email automatically answered without human involvement. If I can, then it will be the non-phasing player’s mailbox that acknowledges receipt of attack orders. The non-phasing player would not have to be involved at all. The phasing player could proceed merrily away conducting all his attacks and discovering the non-phasing player’s standing orders along the way. Meanwhile, the non-phasing player’s mailbox would be accumulating all the phasing player’s attack orders. When the non-phasing player next fires up his copy of MWIF, the program will automatically go to his mailbox and retrieve all the orders that have accumulated there and update his copy of the game. Stepping back a bit and looking at the game sequence overall, I see a few quick emails between players to bring in reinforcements, decide initiative and weather, and place convoys. The meat of the turn will be the action segment where the players alternate being the phasing player: declaring war, choosing action types, conducting naval operations, land operations, and reorganizations. If we can minimize the number of emails needed for naval and land impulses, we will have done a good job. I don’t believe we can hope to merge the naval and land actions into a single email because invasions depend on the outcome of naval combats and so does supply for land units. If we try to compress these further, we would be making substantial changes to the game and run the risk of making a big mess of things. WiF evolved over many years and I was very impressed with the care taken to make the evolutions incremental improvements without damaging the early structure of the design. I guess I come down on the side of minimal changes to the rules. Where we propose changes, it would be best if we gave the players the option of using the changes or staying closer to the rules in WiF. Conclusion I would like your opinions on all of this. If I have not made my ideas clear, let me know that too. If we can get a master design for PBEM (e.g., standing orders) then we can go on to define what the individual elements should be. For example, what would be the standing orders for the non-phasing player’s air, land, and naval units. I don’t want to venture into those details though until we reach agreement on the master design. I thank you for your attention and involvement. Steve

Froonp -> RE: Play by Email (PBEM) for MWIF (7/12/2005 8:55:58 PM)
quote: If the players agree that a strict adherence to RAW 7 requires too many emails to resolve a turn, then MWIF could offer the option of “standing orders”. This seems to be a viable alternative for committing, for example, fighters. Each fighter (either by unit or stack of units) would have standing orders to perform certain actions in response to the phasing player’s actions (i.e., the opponent’s move). One action might be to defend a hex, or area, against strategic bombing, paradrops, port attacks, etc.. Just one remark to add to the eventual "to do" list. If the "standing orders" are to be coded into the game, you need to also code some sort of copy / paste of those "standing orders" between units to allow a player to quickly assign already existing "standing orders" to newly arrived units, or to other units. You also need to have some sort of printer friendly report of all "standing orders" assigned to all units. Anyway, basically, even if I do not intend to play MWiF by email, I am seduced by the "standing orders" approach (which looks like the "non-phasing menu" already proposed by Panzerjaeger". I'm not finished reading the post, I go back to it. Regards Patrice

pak19652002 -> RE: Play by Email (PBEM) for MWIF (7/12/2005 10:30:00 PM)
I would like to add my voice to those who believe PBEM is an important option to include in MWiF. I can only speak for myself, but I believe the majority of my playing time will be PBEM and I would be willing (reluctantly) to sacrifice certain game elements to see a workable PBEM function come to fruition. Reasons: 1) I cannot commit a regular block of hours to play the game. I must squeeze in playing time around work and family. 2) Many of my group (Cyberboard) are overseas, making it even harder to schedule common playing time. 3) WiF is (arguably) more fun to play with more than two players. Coordinating playing time with four or five other people will magnify scheduling difficulties even further. 4) I don't mind games "dragging" on for several months. I'm sure there are those who do, but I'm not one of them. I simply play several games at once and my dance card is easily filled! So, I am very glad you are making a strong effort to include this capability. Keep up the good work! Peter

c92nichj -> RE: Play by Email (PBEM) for MWIF (7/12/2005 11:52:32 PM)
I have spent the last two years playing WIF over PBEM, first using CWIF and now I use cyberboard. I also been a frequent PBM player using snail mail in the past everything from sportgames to Diplomacy. As you havent played WIF using PBEM I try and explain what communication typically is involved in a game turn. An email is with a game file attached is typically only sent once/impulse and once for each side during end of turn. So for a long summer turn with 12 impules, 6 Axis moves and 6 Allied moves plus 1 Allied EOT and 1 Axis EOT would be sent. But the interaction does not stop there, the non-phasing player do need to have some to say about the phasing players actions. It doesn't not happen every impulse but some impulses it happens more than once. Occasions when you would need the other player: - How to spend suprise points in a naval combat and if you want to abort it. - Sometimes intercept's against more important groundstrikes/portattacks/stratbombing. - If you want to defend an important hex that is being attacked, HQ-support, Ground Support, defensive shore bombardment This type of communication is usually not in the form of an attached game file but rather a quick email, chatwindow or a phonecall. I like cyberboard more than CWIF in regard to the EOT moves, specifically because you have the opportunity to not strictly follow the sequence of play, much like how you do it in a face to face game, each player does it at his own speed, building, final reorg, return to base, also reinforcements are done in this file. This was a rather long post I will get back to your questions in another post. Regards, Nicklas

Gaius Varro -> RE: Play by Email (PBEM) for MWIF (7/13/2005 12:15:44 AM)
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

Shannon V. OKeets -> RE: Play by Email (PBEM) for MWIF (7/13/2005 12:28:20 AM)
quote: ORIGINAL: c92nichj I have spent the last two years playing WIF over PBEM, first using CWIF and now I use cyberboard. An email is with a game file attached is typically only sent once/impulse and once for each side during end of turn. So for a long summer turn with 12 impules, 6 Axis moves and 6 Allied moves plus 1 Allied EOT and 1 Axis EOT would be sent. But the interaction does not stop there, the non-phasing player do need to have some to say about the phasing players actions. It doesn't not happen every impulse but some impulses it happens more than once. Occasions when you would need the other player: - How to spend suprise points in a naval combat and if you want to abort it. - Sometimes intercept's against more important groundstrikes/portattacks/stratbombing. - If you want to defend an important hex that is being attacked, HQ-support, Ground Support, defensive shore bombardment This type of communication is usually not in the form of an attached game file but rather a quick email, chatwindow or a phonecall. I like cyberboard more than CWIF in regard to the EOT moves, specifically because you have the opportunity to not strictly follow the sequence of play, much like how you do it in a face to face game, each player does it at his own speed, building, final reorg, return to base, also reinforcements are done in this file. Nicklas I intend to start 4 additional threads on PBEM: Air, Land, and Naval (movement and combat), and Other. Your help in identifying areas of these which are particularly sensitive in a PBEM game would be appreciated. But ... First I want to define a structure for PBEM communications. For example, you state that the attached game file should only be sent once per impulse. I see that as part of the structure. Another part of the structure you mention in your post is the "quick reply". And lastly, having the End of Turn (EOT) handled in a looser fashion than in WIF, so it can be done in a single email, also relates to the structure of the PBEM communications. What are your thoughts on "standing orders" for the non-phasing player? Is there something comparable to them that you currently use? How do you determine what the dice rolls are?

macgregor -> RE: Play by Email (PBEM) for MWIF (7/13/2005 4:47:56 AM)
I have a fear that no matter what player A programs his units to do, a pattern will become visible to player B, who will ultimately be able to take advantage of this. The only way I've seen this work for PBEM games is when both phasing and non-phasing players are forced to select from various mission types. In TOAW these would be 1-air superiority(half the planes attack anything that flies going after fighters first),2- ground support(!/2 planes support attacks/defense on the ground) 3- Interdiction(planes attack units moving along roads -try to avoid air to air combat) and 4-rest(recoup losses). First an overall air superiority ratio is determined based on air to air strength totals within range of a given hex.Forgive me Steve, but I don't see how MWiF can compete with a game like this, designed from the outset as PBEM. If you're lucky, you'll wind up with a global TOAW with something like...CCAW for the naval aspect. All I ask is that at some point, you get around to making a decent World in Flames for the computer using TCP/IP for synchronous play because in my opinion, you're either going to get something with alot of 'horses for the course'-i.e.-cheater loopholes, laborious to continually re-program -to avoid being exploited,or you're going to have to change the game quite drastically. Whatever you do on this I figure I'll still have to buy it along with the game I want -and I'm not happy about that. Maybe I'm just a TOAW player. But so far, you haven't shown me anything that'll come close to that for PBEM. Though maybe that's just me. I should probably keep my mouth shut.

Shannon V. OKeets -> RE: Play by Email (PBEM) for MWIF (7/13/2005 5:37:21 AM)
quote: ORIGINAL: macgregor I have a fear that no matter what player A programs his units to do, a pattern will become visible to player B, who will ultimately be able to take advantage of this. ... Player A can change his standing orders at the beginning of every impulse if he wants to. They do not have to stay the same. I see standing orders more like making the decisions on how to respond before the opponent moves. When playing WIF, and waiting for the other player to decide what to do, I usually figure things out in advance. For example, as the CW I have a stack of ships sitting in England dedicated to the task of intercepting the German navy if it should put to sea. As the German I have some fighters sitting in Germany for the express purpose of intercepting strategic bombing raids. When fighting in France, I have my tactical planes slotted for either ground strikes or ground support and some of them are for this impulse while others are for the next impulse. Of course, in over the board WIF I can always change these planned assignments on the fly (pun intended) to either take advantage of openings or prevent an unexpected disaster from occuring. Most of the dynamics of my moves take place when I am the phasing player. As the non-phasing player I am more of a gadfly trying to annoy the phasing player. It is rare that I get an opportunity to do anything exciting as the non-phasing player. Because of this, I believe taking the micromanagement of units out of the hands of the non-phasing player and requiring him to give standing orders will not have that much impact on the game dynamics. I am not certain of this though. --------------------------- As to the amount of time PBEM adds to get MWIF on the market, I have put about a half a month in the schedule for writing the PBEM capability and testing it. Most of the work is in the design, not the coding. If the design is good then debugging it should be relatively easy. The way PBEM, or any other aspect of MWIF, could throw a wrench in the production schedule is if the design doesn't work out. Then, I would have to go back to the code and either rip out what has already been written or else try to mend (I believe the term patch might be familiar to everyone) the existing code. Right now I am instigating and monitoring these threads - which should be visible to everyone. I am also reading through and commenting CWIF and making some small changes to the code - which should only be visible to Chris, if anyone. I can't really start making major changes in CWIF, turning it into MWIF, until I have a much better understanding of how CWIF stores every aspect of the game in progress and performs the thousand of steps required to support the game mechanics. It will probably take me into August to get a good enough understanding to start on major modifications - such as coding changes to how the map and units look on the screen. My little self-hypnotic mantra is: "make the design good, eliminate rewriting the code, make the design good, eliminate rewriting the code, ..."

Greyshaft -> RE: Play by Email (PBEM) for MWIF (7/13/2005 7:41:44 AM)
quote: For purposes of this discussion I am assuming that there are only two players: A and B. If PBEM can be worked out for two players, then extending it for multiple players shouldn’t be that hard. I disagree on this point. In a two player Axis/Allied game the game state is simple binary logic… either it is my turn (I do some stuff) or it isn’t (I wait). I’m not sure that assumption fully covers the following scenario: * Three human players on the same side, say CW, USA and USSR playing against the AI which is controlling Japan and Germany/Italy. How do you handle CW and USSR both trying to move a land unit into the same hex in Germany? * Going to the other extreme with all Nations controlled by separate players could create quite complex air battles since all players involved in an air battle must assent to the queuing of their air units. How do you confirm that all players on (say) the Allied side have assented to the combat queue? Random Numbers: I used a system of taking the computers date.time when I roll the dice and then taking (say) the 10th significant digit of that number. That would give me a number corresponding to milliseconds which would be impossible to predict or duplicate even for the fastest mouse-clicker. Maybe I missed something about the way computers process date.time? Cheating: I like the automated email idea but it might stumble because there can be an awful lot of dice rolling in a single impulse and many of those rolls must be consecutive rather than simultaneous ie you can “roll” all ground strikes at the same time but land combats cannot be done until the final result of all the ground strikes is known. Therefore you will still need to generate multiple (dozens?) of emails per impulse. Not sure how this will work with disconnected play while travelling by train etc. Also need to ensure compatibility with different email systems so the whole email process is transparent to the user. Perhaps preventing game saves in the middle of an impulse will persuade players that its not worth cheating. You might succeed in your desperate attack on Leningrad the second time around but since you would be forced to replay the ENTIRE impulse then there is a chance that you would lose the favourable Strategic Bombardment attack which succeeded so well the first time. I’m not sure I’m completely in favor of this idea but maybe its worth discussing. Possibly allow a game setup option to permit the AI to handle all player decisions in resolving air combats including abort/kill/abandon combat decisions. The player then just throws his planes at the hex for a ground strike just waits for the final result. This permits players to play the realtime (6 year!) game by deselecting that option, but also allows other games to proceed more quickly.

Shannon V. OKeets -> RE: Play by Email (PBEM) for MWIF (7/13/2005 8:26:40 AM)
quote: ORIGINAL: Greyshaft quote: For purposes of this discussion I am assuming that there are only two players: A and B. If PBEM can be worked out for two players, then extending it for multiple players shouldn’t be that hard. I disagree on this point. In a two player Axis/Allied game the game state is simple binary logic… either it is my turn (I do some stuff) or it isn’t (I wait). I’m not sure that assumption fully covers the following scenario: * Three human players on the same side, say CW, USA and USSR playing against the AI which is controlling Japan and Germany/Italy. How do you handle CW and USSR both trying to move a land unit into the same hex in Germany? * Going to the other extreme with all Nations controlled by separate players could create quite complex air battles since all players involved in an air battle must assent to the queuing of their air units. How do you confirm that all players on (say) the Allied side have assented to the combat queue? Random Numbers: I used a system of taking the computers date.time when I roll the dice and then taking (say) the 10th significant digit of that number. That would give me a number corresponding to milliseconds which would be impossible to predict or duplicate even for the fastest mouse-clicker. Maybe I missed something about the way computers process date.time? Cheating: I like the automated email idea but it might stumble because there can be an awful lot of dice rolling in a single impulse and many of those rolls must be consecutive rather than simultaneous ie you can “roll” all ground strikes at the same time but land combats cannot be done until the final result of all the ground strikes is known. Therefore you will still need to generate multiple (dozens?) of emails per impulse. Not sure how this will work with disconnected play while travelling by train etc. Also need to ensure compatibility with different email systems so the whole email process is transparent to the user. Perhaps preventing game saves in the middle of an impulse will persuade players that its not worth cheating. You might succeed in your desperate attack on Leningrad the second time around but since you would be forced to replay the ENTIRE impulse then there is a chance that you would lose the favourable Strategic Bombardment attack which succeeded so well the first time. I’m not sure I’m completely in favor of this idea but maybe its worth discussing. Possibly allow a game setup option to permit the AI to handle all player decisions in resolving air combats including abort/kill/abandon combat decisions. The player then just throws his planes at the hex for a ground strike just waits for the final result. This permits players to play the realtime (6 year!) game by deselecting that option, but also allows other games to proceed more quickly. I had never considered multilpe players against the AI, though it is a logical possiblity given the design I envision. Taking your comments in turn ... Two allied players try to move land units into the same hex when the land units cannot stack. My knee jerk response to this is to prevent both the units from moving, and any repercussions that result from that. The thought is that the allied players should coordinate better. A more generous response might be to have a team leader even for PBEM. MWIF running on the team leader's computer would check for these kinds of things once it has seen everyone's orders and kick them out for correction before making the moves definitive. You have a good point that there are some instances where allied players need to communicate and coordinate, even if they are the non-phasing side. I would place the responsibility for resolving the combat queue instructions in the hands of the team leader. Even if the team leader has examined all the standing orders there may still be problems. So let's suppose that the defenders are flying ground support with fighters to protect an important hex and the total number of planes involved exceeds 10, a mix of fighters and bombers for both sides. Now if there were only one player per side, the standing orders should take care of this situation. We could even force the phasing player to enter the equivalent of standing orders so he doesn't have an undue advantage. But how to handle two players on the same side, each of whom has issued standing orders for his planes? Essentially the question is how to make the decisions of which of our planes, and the opponent's planes, to kill, damage, abort, and clear through. Also whether to continue the combat or call the whole thing off. I don't have an answer at the moment. I would propose delaying further analysis until we can work out in detail the possible standing orders for planes. Therefore I would like to move this to the thread on PBEM Air - coming soon to a computer near you! I still like the idea of a matrix that is filled, and kept filled, using a psuedo-random number generator. Your suggestion of the date.time millisecond is a good one and could be used as the seed for the second random number generator (which sets the indices into the matrix). I am reluctant to only use date.time for random numbers because of the need in some cases of drawing several random numbers at once. The Indy10 email routines are pretty straight forward. They use SMTP (System Mail Transfer Protocol) and Pop3 (Post Office Protocol, version 3). The former sends emails and the latter retrieves them. Am I naive to assume these will work with most email systems? Creating dozens of emails should not be that big a problem unless players' mailboxes get too full. The emails would all be quite tiny, so it is a question of the number of emails rather than the disk space they take up. I'm sorry, but taking Leningrad (or Gibraltar) is worth any other bad rolls that happen during a turn. Given the option, I would be sorely tempted to keep trying to roll the perfect dice to achieve either of those goals, regardless of other outcomes. And my honesty is legendary![:D] The option of putting all the little decisions in the hands of the AI strikes me as a good one. The players should have the ability to select and deselect that option as the game progresses. There should also be other alternatives to choose from. Good ideas, thanks. If we keep kicking this around, maybe we can find/design something that will work well.

c92nichj -> RE: Play by Email (PBEM) for MWIF (7/13/2005 11:52:16 AM)
quote: ORIGINAL: Shannon V. OKeets I intend to start 4 additional threads on PBEM: Air, Land, and Naval (movement and combat), and Other. Your help in identifying areas of these which are particularly sensitive in a PBEM game would be appreciated. But ... Air: Normally my opponent would do the intercepts and battles alone, using trying to do what is best for me: Say for example that a my opponent strat bomb Berlin and I have a fighter based there, it is pretty lilely that I would have intercepted with it and fight out the battle, so my opponent does that for me (in a computer game the AI could do it). However there are cases when things are not that clear cut, for example a fight over Gibraltar with lots of planes on both sides, do I save some until next impulse, do I continue the air fight even though my odds are not that good, Gibraltar is at stake here, I might want to take bigger risks. It is difficult for a computer to understand if a hex is important or not, Maybe it could be possible for to mark certain hexes for air battle where I don't allow the AI cannot take control (my opponent doesn't have to know which hexes). If I also can state at what odds level I want to continue a fight and change it on a a hex basis, for example abort the fight if odds at +2/-2 Land: There are not many things that the non-phasing player needs to do during land movement, the only thing I can think of is HQ, Art -support during attacks. But I typically know if I want to do defensive support before my opponent move, so a standing order would work well here. Naval: Based on experience this is the area which is most difficult to deal with, since it takes ages to build new ships and a sunk CV or Transport loaded with troops have a big impact on the game. Maybe you also could mark sea areas where you don't want the AI to handle seabattles, and instruct your fleet to intercept units that are weaker/equal/marginally stronger than your fleet. quote: What are your thoughts on "standing orders" for the non-phasing player? Is there something comparable to them that you currently use? How do you determine what the dice rolls are? Standing orders are ok, we don't really use them but in a computer game I think it would be fine. Dice rolls have been done in two ways, first when I used CWIF, we just trusted each other to make the roll, now when playing on cyberboard we use ACTS http://acts.warhorsesim.com/index.asp which rolls dies for you on an internet server and makes it impossible to cheat on die rolls, I like that better. Not that I dodn't trust my opponent earlier on but that it is impossible to cheat makes it easier accept a 10% chance success on invading Gibraltar.

c92nichj -> RE: Play by Email (PBEM) for MWIF (7/13/2005 12:04:21 PM)
quote: ORIGINAL: Shannon V. OKeets Minimizing the number of emails The PBEM version should offer the option of changes in the sequence of play to reduce the number of emails needed to play through a turn. Using this option would mean that the game would not be a ‘pure’ replication of WiF, though we should be able to get it reasonably close. If the players agree that a strict adherence to RAW 7 requires too many emails to resolve a turn, then MWIF could offer the option of “standing orders”. This seems to be a viable alternative for committing, for example, fighters. Each fighter (either by unit or stack of units) would have standing orders to perform certain actions in response to the phasing player’s actions (i.e., the opponent’s move). One action might be to defend a hex, or area, against strategic bombing, paradrops, port attacks, etc.. While making these assignments for all your air units might seem a daunting task at first, it would occur incrementally during play with players merely modifying previous standing orders as new units arrive or conditions change. During slow turns (e.g., winter weather conditions) very little would need to be done. A player could specify up to three or four standing orders (with a priority list) for each unit/stack of units. This would take the non-phasing player out of the communication loop for decision making. Stepping back a bit and looking at the game sequence overall, I see a few quick emails between players to bring in reinforcements, decide initiative and weather, and place convoys. The meat of the turn will be the action segment where the players alternate being the phasing player: declaring war, choosing action types, conducting naval operations, land operations, and reorganizations. If we can minimize the number of emails needed for naval and land impulses, we will have done a good job. I don’t believe we can hope to merge the naval and land actions into a single email because invasions depend on the outcome of naval combats and so does supply for land units. If we try to compress these further, we would be making substantial changes to the game and run the risk of making a big mess of things. WiF evolved over many years and I was very impressed with the care taken to make the evolutions incremental improvements without damaging the early structure of the design. I guess I come down on the side of minimal changes to the rules. Where we propose changes, it would be best if we gave the players the option of using the changes or staying closer to the rules in WiF. Keeping down the number of emails will be key to get the game to progress at any speed, even with only one email/impulse. In my current game we are at 80 gamefiles passsed around since 9th june and we are doing EOT for M/J -40 (And we are playing at quite high speed with two mails/day). Another game I am spectator at had 103 files since mid March and they are only in M/A -40. [>:] WIF PBEM takes long time to play.

Shannon V. OKeets -> RE: Play by Email (PBEM) for MWIF (7/13/2005 5:04:26 PM)
quote: ORIGINAL: c92nichj ... Standing orders are ok, we don't really use them but in a computer game I think it would be fine. Dice rolls have been done in two ways, first when I used CWIF, we just trusted each other to make the roll, now when playing on cyberboard we use ACTS http://acts.warhorsesim.com/index.asp which rolls dies for you on an internet server and makes it impossible to cheat on die rolls, I like that better. Not that I dodn't trust my opponent earlier on but that it is impossible to cheat makes it easier accept a 10% chance success on invading Gibraltar. I logged into ACTS but couldn't see anything about World in Flames or automated dice rolls. Do you have more specifics?

c92nichj -> RE: Play by Email (PBEM) for MWIF (7/13/2005 6:31:07 PM)
quote: ORIGINAL: Shannon V. OKeets I logged into ACTS but couldn't see anything about World in Flames or automated dice rolls. Do you have more specifics? From: Peter Kanjorski Sent: den 12 juli 2005 08:52 To: Peter Kanjorski; Hjalmarsson, Nicklas; Kenneth Crist Subject: ACTS: Generic Game Module: 'KNP's WiF Game': Sir Peter action Die roll request Request: 10-sided die x 1 1 Message from Sir Peter: MJ40 Allied 10: Strat bomb brussels with 4 factors. +1 due to no intercept. A typical email we sould get from the ACTs server would look something like this. There is nothing specific to World in flames, you only send an email requesting a number of die rolls and write a message what they are for. The british bombraid on Brussles wasn't very succesful this time around. Try and se if you can access this link to view how our game have been performing so far, http://acts.warhorsesim.com/dynamic/journal.asp?id=11175

Shannon V. OKeets -> RE: Play by Email (PBEM) for MWIF (7/13/2005 6:52:19 PM)
quote: ORIGINAL: c92nichj Try and se if you can access this link to view how our game have been performing so far, http://acts.warhorsesim.com/dynamic/journal.asp?id=11175 This worked just fine. If you wanted to use two 10 sided dice for each roll, I see you could just ask for 2 rolls each time. There don't have to be any emails to the players. The results of all the die rolls and simply posted where everyone can read them. If possible I would like to have MWIF be self-contained and not rely on any third party for random numbers. This would also enable the drawing of the US Entry chits to be kept hidden from the Axis. Though I could probably come up with something to accomplish the latter using the ACTS die rolls.

pak19652002 -> RE: Play by Email (PBEM) for MWIF (7/13/2005 8:42:22 PM)
Steve: I read that you are a PBEM expert, but I can't remember if you have ever used Cyberboard's WiF gamebox. But, if not, you could spectate Nicklas and my game. It might give you some insight into the ebb and flow of WiF and ACTS in a multi-player (3) game. You would also see some of the problems we stoically tolerate to play WiF online in any form and some clever short-cuts that have been devised (not by me) to help speed things up! If you are interested, contact me off the board and I'll send you necessary files. If you have already been there and done that, then you already know what we're going through! Peter

Shannon V. OKeets -> RE: Play by Email (PBEM) for MWIF (7/14/2005 4:22:38 AM)
quote: ORIGINAL: pak19652002 Steve: I read that you are a PBEM expert, but I can't remember if you have ever used Cyberboard's WiF gamebox. But, if not, you could spectate Nicklas and my game. It might give you some insight into the ebb and flow of WiF and ACTS in a multi-player (3) game. You would also see some of the problems we stoically tolerate to play WiF online in any form and some clever short-cuts that have been devised (not by me) to help speed things up! If you are interested, contact me off the board and I'll send you necessary files. If you have already been there and done that, then you already know what we're going through! Peter Lies, lies, they are all lies. I am not a PBEM expert. Do you want to play for money? Actually, the full extent of my credentials in the PBEM world are convered in the few postings I have made to this thread. I am relying you, and others like you who have played wargames by email, to help with the design for MWIF PBEM. Let me know what has worked and what hasn't. If you have ideas and suggestions, even if you think they might be considered foolish by some, please post them here. I am a devotee of a strange school of thought that believes that even the worst ideas contain elements of insight into a problem - and thereby insight into possible solutions. It has worked for me countless times in the past. As to following your game, there are a vast number of things demanding my time at the moment. For example, there are some people who would like to see MWIF released before they die (I read that in one of the posts to this forum). Since I don't know the state of their health, I feel I should probably focus on writing code as much as I can lest I end up hearing his widow say: "He would have so much enjoyed playing this game. If only he were alive today." when MWIF is finally published. I'm really no good at all at funerals. Past the word along to others in the PBEM world to visit this forum and tell us what they think. The more the merrier.

Greyshaft -> RE: Play by Email (PBEM) for MWIF (7/14/2005 6:48:02 AM)
I think that the air combats will be comparatively easy to resolve and in the end could be simplified to where the attacker throws a bunch of attacking air units at a list of factory hexes/ports/ground units etc and then the defender throws up some fighters and then the AI figures out the results and lets the players rebase the surviving units. The part that I am avoiding is discussing the Naval combats [sm=Christo_pull_hair.gif] since each moving Naval stack could involve multiple movement * interceptattempt * movement intercept pickseabox * add air units * do combats * pick casualties * rinse * repeat phases, each of which requires player input. It may be possible to set up some scripting for the simple decisions but it will be a decision tree which puts a Banyan vine to shame[sm=00000116.gif]

Shannon V. OKeets -> RE: Play by Email (PBEM) for MWIF (7/14/2005 6:57:59 AM)
quote: ORIGINAL: Greyshaft I think that the air combats will be comparatively easy to resolve and in the end could be simplified to where the attacker throws a bunch of attacking air units at a list of factory hexes/ports/ground units etc and then the defender throws up some fighters and then the AI figures out the results and lets the players rebase the surviving units. The part that I am avoiding is discussing the Naval combats [sm=Christo_pull_hair.gif] since each moving Naval stack could involve multiple movement * interceptattempt * movement intercept pickseabox * add air units * do combats * pick casualties * rinse * repeat phases, each of which requires player input. It may be possible to set up some scripting for the simple decisions but it will be a decision tree which puts a Banyan vine to shame[sm=00000116.gif] Curious turn of phrase. The name of the building I live in Banyan Tree Plaza. I will start 4 more threads on PBEM tomorrow: Air, Land, Naval, and Other. We can ponder each of these in detail then.

Greyshaft -> The Banyan Tree (7/14/2005 10:56:58 AM)
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."

Shannon V. OKeets -> RE: The Banyan Tree (7/14/2005 7:09:03 PM)
quote: 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.

Shannon V. OKeets -> RE: Play by Email (PBEM) for MWIF (7/14/2005 7:26:29 PM)
quote: 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.

pak19652002 -> RE: Play by Email (PBEM) for MWIF (7/14/2005 9:17:29 PM)
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

Shannon V. OKeets -> RE: Play by Email (PBEM) for MWIF (7/16/2005 6:34:50 PM)
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?

Froonp -> RE: Play by Email (PBEM) for MWIF (7/17/2005 2:38:12 AM)
quote: 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.

Incy -> RE: Play by Email (PBEM) for MWIF (7/17/2005 3:46:06 AM)
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)

Shannon V. OKeets -> RE: Play by Email (PBEM) for MWIF (7/17/2005 4:08:42 AM)
quote: ORIGINAL: Froonp quote: 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.

Shannon V. OKeets -> RE: Play by Email (PBEM) for MWIF (7/17/2005 4:49:22 AM)
Good stuff. It makes me think about things in new ways. quote: 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. quote: -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. quote: 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.

Incy -> RE: Play by Email (PBEM) for MWIF (7/18/2005 2:15:49 AM)
quote: 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!). quote: 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 2RNG 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). quote:* -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. quote: 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 [:)]

Shannon V. OKeets -> RE: Play by Email (PBEM) for MWIF (7/18/2005 4:39:14 AM)
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.

Page: [1] 2 3 next > >>

Forum Software © ASPPlayground.NET Advanced Edition 2.4.5 ANSI

7.25