A few things...
Moderator: MOD_EIA
- MarshallEllis
- Posts: 5632
- Joined: Tue Oct 02, 2001 3:00 pm
- Location: Dallas
A few things...
Hey guys:
I am investigating a few things for more PBEM streamlining.
I am looking at ways to incorporate the sending of the email internally into the game. I think this could be done by using an external sender. QUESTION: Would this help? I think so but want your word...
I am also looking at an outside compression routine.
Together, these tools could compress, build the email with attachments then send. The compression tool could also decompress the turn files when they reach the commin folder.
Thoughts?
BTW: This would be after 1.08 (1.09, 1.10)
I am investigating a few things for more PBEM streamlining.
I am looking at ways to incorporate the sending of the email internally into the game. I think this could be done by using an external sender. QUESTION: Would this help? I think so but want your word...
I am also looking at an outside compression routine.
Together, these tools could compress, build the email with attachments then send. The compression tool could also decompress the turn files when they reach the commin folder.
Thoughts?
BTW: This would be after 1.08 (1.09, 1.10)
RE: A few things...
Please 
- DCWhitworth
- Posts: 676
- Joined: Sat Dec 15, 2007 1:20 am
- Location: Norwich, England
RE: A few things...
How would this work in terms of an email address ? Would you need an existing email client on your PC ? What email server does it send things to ?
I (and a lot of other people) use webmail based email for communication in the game, if I had emails coming from one source and game files from another that might be confusing if people start replying to the wrong address.
I'm not trying to shoot down your idea, just want to highlight some issues I think I can see.
I (and a lot of other people) use webmail based email for communication in the game, if I had emails coming from one source and game files from another that might be confusing if people start replying to the wrong address.
I'm not trying to shoot down your idea, just want to highlight some issues I think I can see.
Regards
David
David
- MarshallEllis
- Posts: 5632
- Joined: Tue Oct 02, 2001 3:00 pm
- Location: Dallas
RE: A few things...
This would utilize SMTP so if you use webmail then probably will do little for you. You would need to provide your email server credentials (Like you would to Outlook). It will NOT receive emails yet but only automate the outgoing stuff. I will option this so this is not a mandatory method.
- DCWhitworth
- Posts: 676
- Joined: Sat Dec 15, 2007 1:20 am
- Location: Norwich, England
RE: A few things...
ORIGINAL: Marshall Ellis
This would utilize SMTP so if you use webmail then probably will do little for you. You would need to provide your email server credentials (Like you would to Outlook). It will NOT receive emails yet but only automate the outgoing stuff. I will option this so this is not a mandatory method.
Thanks, I'm not too sure how much use I would find this. All the groups I am playing in use a website of some sort to exchange files rather than email.
Regards
David
David
- MarshallEllis
- Posts: 5632
- Joined: Tue Oct 02, 2001 3:00 pm
- Location: Dallas
RE: A few things...
Interesting indeed. I am aware of the websites in use for PBEM and maybe I can look into the automation of this process as well???
RE: A few things...
Either way would be a good addition: A mini email client and/or a way to communicate with a storage system somewhere.ORIGINAL: Marshall Ellis
Interesting indeed. I am aware of the websites in use for PBEM and maybe I can look into the automation of this process as well???
When you write it, keep the code modular, so you can "plug in" other products later. For example, many products can use a command-line interface for at least some of what they do. You could create smaller sub-modules to handle the differences between one vendor's product and the next. Some to start with would be the open-source or spec-ed traffic handlers, such as
LDAP
SMTP
FTP
TFTP
etc.
Note that there are some that are not email in that list. If you leave your options open widely, then you don't have to worry about using open-source code, because you can always replace the code if the vendor goes belly-up.
Another thing to consider is writing the game code minus actual mailers/traffic handlers, but allow customers to plug in their own (supported) traffic handlers. If someone uses Outlook over RPC, then you could allow Outlook over RPC as demand for it increased. If someone else wanted plain old smtp, you can "turn it on" later. Many product STANDARDs (LDAP, SMTP, etc) are effectively public domain, so you can write the code yourself. For others, the transmission protocols are public domain, but the code isn't. These would have to be "supported".
What pieces are necessary? At a minimum, you will need at least one of:
A) email send and email receive
B) file transfer send and FT receive
C) file compression and file decompression
D) etc.
Obviously, you could include more than one. And, if you've got someone on staff good with HTML, ASP, Java (puke!), etc., you could write your own versions.
NOTE: This kind of modularity would allow Matrix to later start a hosting server for the purpose of storing this information. Such a thing would provide an income stream for Matrix for EiANW and other games which may utilize it.
At LAST! The greatest campaign board game of all time is finally available for the PC. Can my old heart stand the strain?
- DCWhitworth
- Posts: 676
- Joined: Sat Dec 15, 2007 1:20 am
- Location: Norwich, England
RE: A few things...
This is starting to sound like too much work for too little return.
Regards
David
David
RE: A few things...
Oh, no. It Could be a huge return. Monstrous:
Once a reasonable automated method is in place to handle the email (zip, file storage, or whatever), other tools can be written against the server delivering up the data. So, effectively, it would be nearly trivial to automate the uploading and downloading of PBM (and possibly other) files.
Once that's in place, there could be a very fast transmission to the next player in line, which could then flag an alarm of some kind on that player's computer.
Yes, pushing the files to a server or mail client doesn't buy much except a little time. But, having them be there allows the game (or a tool bundled with the game, or even a tool written separately) manage the clock. Since the delay between the sending of a file and the receiving of the same file is measured in hours now, this would be a potentially massive reduction in time spent. Any kind of alarm flagging a player that it's now his turn again could potentially reduce this from hours delayed to single-digit minutes delayed (i.e. the time to actually take ones turn).
In the game where I was GB, I would wait for Spain at the diplo/reinforce boundary. He would take his turn, but we never knew when. Once he was done, I could almost immediately do my turn. However, I had to refresh and check the server first. Or, I had to have the email for that account open and ready to flag me. I just couldn't do that as often as would be needed for a rapid turnaround. But, give me an alarm, and it could be mere seconds until I would be in taking my turn.
This could potentially be even FASTER than theoretical IP gameplay, except when compared against IP's best-case scenarios. (NOTE: IP play, coupled with a full windowed-mode of the game, would eclipse this in terms of speed. However, IP play is a long ways away, and this is very do-able now.)
Once a reasonable automated method is in place to handle the email (zip, file storage, or whatever), other tools can be written against the server delivering up the data. So, effectively, it would be nearly trivial to automate the uploading and downloading of PBM (and possibly other) files.
Once that's in place, there could be a very fast transmission to the next player in line, which could then flag an alarm of some kind on that player's computer.
Yes, pushing the files to a server or mail client doesn't buy much except a little time. But, having them be there allows the game (or a tool bundled with the game, or even a tool written separately) manage the clock. Since the delay between the sending of a file and the receiving of the same file is measured in hours now, this would be a potentially massive reduction in time spent. Any kind of alarm flagging a player that it's now his turn again could potentially reduce this from hours delayed to single-digit minutes delayed (i.e. the time to actually take ones turn).
In the game where I was GB, I would wait for Spain at the diplo/reinforce boundary. He would take his turn, but we never knew when. Once he was done, I could almost immediately do my turn. However, I had to refresh and check the server first. Or, I had to have the email for that account open and ready to flag me. I just couldn't do that as often as would be needed for a rapid turnaround. But, give me an alarm, and it could be mere seconds until I would be in taking my turn.
This could potentially be even FASTER than theoretical IP gameplay, except when compared against IP's best-case scenarios. (NOTE: IP play, coupled with a full windowed-mode of the game, would eclipse this in terms of speed. However, IP play is a long ways away, and this is very do-able now.)
At LAST! The greatest campaign board game of all time is finally available for the PC. Can my old heart stand the strain?
RE: A few things...
I agree that if Marshall can find some way to make this happen to that it is fully automated, the return would be HUGE!!
That said, I don't use a client, I use webmail. Both of my groups use a file exchange site; HOWEVER, if an automated process could be found then there wouldn't be any need to the file exchange site, which would be great, IMO.
An automated process would significantly reduce the vast majority of overhead associated with this game.
That said, I don't use a client, I use webmail. Both of my groups use a file exchange site; HOWEVER, if an automated process could be found then there wouldn't be any need to the file exchange site, which would be great, IMO.
An automated process would significantly reduce the vast majority of overhead associated with this game.
- DCWhitworth
- Posts: 676
- Joined: Sat Dec 15, 2007 1:20 am
- Location: Norwich, England
RE: A few things...
I'm not seeing how an alarm triggered by an arriving file is any more effective than an alarm triggered by an arriving email ? I certainly spend much more time during a day with my email account open than my EiANW game open (I realise others on this list may behave otherwise [;)] )
Regards
David
David
RE: A few things...
ORIGINAL: DCWhitworth
I'm not seeing how an alarm triggered by an arriving file is any more effective than an alarm triggered by an arriving email ? I certainly spend much more time during a day with my email account open than my EiANW game open (I realise others on this list may behave otherwise [;)] )
I tend to agree, I don't think you need some separate "alarm".
-
Dancing Bear
- Posts: 1003
- Joined: Wed Feb 20, 2008 11:16 pm
RE: A few things...
forgive my ignorance, but I don't see how this makes the game faster (streamlined). I might spend a maximum of 5 minutes loading game files between turns, but i can spend days waiting for some other player in the sequence to play their turn. How is this huge?
Is this what we are talking about for streamlining? I'd rather see an autoforage function, a way to reduce file exchanges for seige battles, and a way to roll the date forward by a couple of months.
Is this what we are talking about for streamlining? I'd rather see an autoforage function, a way to reduce file exchanges for seige battles, and a way to roll the date forward by a couple of months.
RE: A few things...
ORIGINAL: Dancing Bear
forgive my ignorance, but I don't see how this makes the game faster (streamlined). I might spend a maximum of 5 minutes loading game files between turns, but i can spend days waiting for some other player in the sequence to play their turn. How is this huge?
Is this what we are talking about for streamlining? I'd rather see an autoforage function, a way to reduce file exchanges for seige battles, and a way to roll the date forward by a couple of months.
It's HUGE based on the "annoying" factor alone. It's not a big time saver from a game standpoint, it's a big time saver from a player standpoint.
Yes, I spend about 5 minutes managing files and about 1 minute playing the game. It'd be great if we could get that down to a nice 1:1 ratio.
There already is an autoforage button. And if you are refering to skipping land phases, going by your example that most of your time is spent waiting for others to get around to doing their turn then that isn't going to "streamline" much either.
The skipping function doesn't really save much time at all actually, I've always (and still do) felt this way... because like you said if it's 2 hours between your turn and the time the next player does his turn then how much time is really saved? You could have just taken the 5 minutes and done your turn and then waiting the 1 hour and 55 minutes.
-
Dancing Bear
- Posts: 1003
- Joined: Wed Feb 20, 2008 11:16 pm
RE: A few things...
Ok thanks Neverman, so streamlining in this case means reducing the annoyance factor only.
Yes, I guess I should have clarified in my post that by autoforage I did mean land phase skipping. At the risk of digressing into a discussion on skipping, your example is backwards. If you log on and the player two spots ahead of you (player A) has played his turn but the player immediately in front of you (player B) takes another 2 hours to play after you log on, then had player B skipped, your game would be 2 hours ahead (or 2 days if it takes 2 days for player B to get to his turn). This is more in line of what I was thinking for streamlining.
Yes, I guess I should have clarified in my post that by autoforage I did mean land phase skipping. At the risk of digressing into a discussion on skipping, your example is backwards. If you log on and the player two spots ahead of you (player A) has played his turn but the player immediately in front of you (player B) takes another 2 hours to play after you log on, then had player B skipped, your game would be 2 hours ahead (or 2 days if it takes 2 days for player B to get to his turn). This is more in line of what I was thinking for streamlining.
RE: A few things...
ORIGINAL: Dancing Bear
Ok thanks Neverman, so streamlining in this case means reducing the annoyance factor only.
Yes, I guess I should have clarified in my post that by autoforage I did mean land phase skipping. At the risk of digressing into a discussion on skipping, your example is backwards. If you log on and the player two spots ahead of you (player A) has played his turn but the player immediately in front of you (player B) takes another 2 hours to play after you log on, then had player B skipped, your game would be 2 hours ahead (or 2 days if it takes 2 days for player B to get to his turn). This is more in line of what I was thinking for streamlining.
This is only true if you are sitting around waiting to play your turn, which in my experience is not usually the case. Given that this is just my experience and yours might be totally different, but from my experience it goes more like this:
No one is sitting around waiting to do their turn, they usually do it at a certain time (usually the time of the day they have time to do it, for me that's most often nights). Also, most of the players in the group are in different time zones and have different schedules (some players can do their turn in the middle of the day, others in the morning), SO my example is more like that (let me clarify):
Player 1 does his turn at 6pm, Player 2 does his turn at 8pm and Player 3 does his turn at 10pm....
... what is the advantage to player 2 skipping? NONE, other than it saves player 2 some time but in this scenario it does NOT "streamline" PBEM at all and, again, in my experience, this has most often been the case.
-
Dancing Bear
- Posts: 1003
- Joined: Wed Feb 20, 2008 11:16 pm
RE: A few things...
Actually neverman, I thought your example is a good one to prove that skipping works.
Lets say the three players in your example are Austria (you goes at 6pm), Prussia (8 pm) and GB (10 pm).
Now these players go in this order in the diplomacy phase, but go in the reverse order in the reinforcement phase. For the reinforcement phase, the first one up is GB who goes at 10 pm, so no one else goes on the first day. On the next day Prussia goes at 8 pm, and still Austria can’t go because he logged on at 6. Finally on the third day, Austria can play his turn. So using the time periods in your example, it would take 3 days to do only half a reinforcement phase.
Now if Prussia skipped reinforcement, then you would save an entire day off your schedule. If Austria also skipped that would be 2 days, and GB would be three days. You could cut three days of “waiting” out of the schedule if these players used skipped, which is big time saver.
Your example might be a bit rigid, because players can usually log in a couple of times over an evening so there is often a 3 hour window where the above players would overlap partially. However, in the case where one player is on the Eastern seaboard, one is in California, and one is in Europe, which is not uncommon, then it is a good example because the time zone differences are bigger than 3 hours.
I think this is often why some phases seem to go fast and others are very slow. And it why land phase skipping is needed for those games where the time zone set up is terrible for the land phase where there is currently no skipping. Skipping can really help when players are in different time zones.
The same is true for players who log on infrequently, or rigidly at the same time ever day.
Lets say the three players in your example are Austria (you goes at 6pm), Prussia (8 pm) and GB (10 pm).
Now these players go in this order in the diplomacy phase, but go in the reverse order in the reinforcement phase. For the reinforcement phase, the first one up is GB who goes at 10 pm, so no one else goes on the first day. On the next day Prussia goes at 8 pm, and still Austria can’t go because he logged on at 6. Finally on the third day, Austria can play his turn. So using the time periods in your example, it would take 3 days to do only half a reinforcement phase.
Now if Prussia skipped reinforcement, then you would save an entire day off your schedule. If Austria also skipped that would be 2 days, and GB would be three days. You could cut three days of “waiting” out of the schedule if these players used skipped, which is big time saver.
Your example might be a bit rigid, because players can usually log in a couple of times over an evening so there is often a 3 hour window where the above players would overlap partially. However, in the case where one player is on the Eastern seaboard, one is in California, and one is in Europe, which is not uncommon, then it is a good example because the time zone differences are bigger than 3 hours.
I think this is often why some phases seem to go fast and others are very slow. And it why land phase skipping is needed for those games where the time zone set up is terrible for the land phase where there is currently no skipping. Skipping can really help when players are in different time zones.
The same is true for players who log on infrequently, or rigidly at the same time ever day.
RE: A few things...
I would be interested in the details of that, actuallyORIGINAL: Marshall Ellis
Interesting indeed. I am aware of the websites in use for PBEM and maybe I can look into the automation of this process as well???
RE: A few things...
One other thing on this, Marshall:
If you allowed one extra email address in the game configuration, for a "generic" location to send to, that would solve the "web-based email" issue. However, it would solve it for SENDING mail only. The game would check that entry, if populated, send the turn file (zipped) to that "public" email address (like gamename@groups.google.com or whatever).
Note that this also would provide a method of securing turns as well. In the time between the end of ones land movement and the beginning of land combat (naval as well), the game would have already posted the land movement file. So, security questions about this particular location would evaporate.
IF this were done correctly, then for games with "public" incoming mailboxes for the files, I would even support making this mandatory if the box is filled in by the host at game creation time (possibly allowing changes later?)
If you allowed one extra email address in the game configuration, for a "generic" location to send to, that would solve the "web-based email" issue. However, it would solve it for SENDING mail only. The game would check that entry, if populated, send the turn file (zipped) to that "public" email address (like gamename@groups.google.com or whatever).
Note that this also would provide a method of securing turns as well. In the time between the end of ones land movement and the beginning of land combat (naval as well), the game would have already posted the land movement file. So, security questions about this particular location would evaporate.
IF this were done correctly, then for games with "public" incoming mailboxes for the files, I would even support making this mandatory if the box is filled in by the host at game creation time (possibly allowing changes later?)
At LAST! The greatest campaign board game of all time is finally available for the PC. Can my old heart stand the strain?



