Matrix Games Forums

ORIGINAL: moopere

ORIGINAL: Grognot

(2) the differing transport mechanisms. PBEM, in fact, does use TCP/IP. Considering that with the small player base of a niche, complicated wargame not well-suited to Ritalin addicts, you're probably going to have substantial delays *anyway*, it's not clear that PBEM itself causes any problems whatsoever unless you're using a poor e-mail system which regularly delays mail or loses attachments.

And, since you don't actually have to use e-mail to transfer the .pbm files, but can use the transport mechanism of your choice (CVS, for instance), that's not really a problem that requires an in-game solution, either.

Yep, and this is what the TCP/IP promoters seem to have missed. If you send me an email right now I'll likely get it within the next 30 seconds. Logically then, if all 7 players are gathered at their PC's right now we can play the game using the PBEM infrastructure but in 'real time' just as quickly as if there were a direct client to client network based system implemented.

I'd like to see someone actually tell me -how- the much hyped TCP/IP direct play model is faster or better? We might actually be arguing over interface in my humble opinion, the assumption possibly being that a TCP/IP implementation would hide from players all the work currently required with attachments and files.

Cheers, M.

Yep, and this is what the TCP/IP promoters seem to have missed. If you send me an email right now I'll likely get it within the next 30 seconds. Logically then, if all 7 players are gathered at their PC's right now we can play the game using the PBEM infrastructure but in 'real time' just as quickly as if there were a direct client to client network based system implemented.

I'd like to see someone actually tell me -how- the much hyped TCP/IP direct play model is faster or better? We might actually be arguing over interface in my humble opinion, the assumption possibly being that a TCP/IP implementation would hide from players all the work currently required with attachments and files.

Cheers, M.

The difference of having TCP/ip play is that it would be real time and not send a turn and wait days for next turn. TCP/IP would create an environment that is more like playing the FtF variety of the game which was and is more fun than the sterile PBEM way of playing. You could also add a voice server into the mix and talk to each other as the game is going. That is the way I would play. Live game one or twice a week and enhancing with Ventrilo voice communication along with the live game.

In average you will spend more time downloading/ziping/switching programs/attaching files/copying files etc before and after your phase than you spend actually playing it out. PBEM in EiA have an extreme overhe
 
As a comparasson:
 
In the client server model its a slow period after a big war on average a phase takes 2 minutes to execute, there is 6 players before your turn 6x2=12 minutes, just enough time to go fetch a coffee or to discuss your next move with ur ally on the TS server.
 
PBEM model, it still takes 12 minutes to execute the phase but even with all players online and vigilantly monitoring there emal program it takes 5 extra minutes at best to do the administrative tasks before and after the turns. 5x6=24 + 12 = 36 minutes.
 
Say you have a 3h session you all agreed on and we assume that the mail servers your using are perfectly flawless. With TCP/IP you could at best manage 12 phases in those 3 hours. With PBEM you could manage 4.
 
Im not saying that the numbers are realistic but even during the best circumstances PBEM is significantly slower.
 
The difference is ofc less in a more busy part of the game.
 
 

ORIGINAL: zaquex



A TCP/IP implementation is best served by a client server model. The server should preferable be online 24/7, then at anytime any player could log in to the server see where the game is up to. All game mechanisms should be run on the server and the players machine should only act as an interface to provide input and output to the players in essence it would be a hotseat game with a remote interface over TCP/IP.

exactly...

ORIGINAL: timewalker03
The difference of having TCP/ip play is that it would be real time and not send a turn and wait days for next turn. TCP/IP would create an environment that is more like playing the FtF variety of the game which was and is more fun than the sterile PBEM way of playing. You could also add a voice server into the mix and talk to each other as the game is going. That is the way I would play. Live game one or twice a week and enhancing with Ventrilo voice communication along with the live game.

If you are waiting days for an email then your net connection would have to be so bad that you couldn't play by TCPIP anyway. If your net connection is good, and, as I say in my original post all 7 players are at their terminals at the same time then you could get 30 second turnaround on players emails/turns.

As I suspected, what we're really talking about here is all the stuffing around with files...saving them here not saving them there..making sure the extensions are correct...blah, blah, blah. The interface to PBEM could be made seamless if desired with EiA picking up all emails with a certain encoded (or other) string in the subject from the default email program.

Cheers, M.

ORIGINAL: timewalker03

To make a quick summary of TCP/Ip play what I was told is that if enough people want it then it will be implemented sooner than later. I was told some other things about it, but it can be done but there are other fixes needed first which is understandable. Also most decisions come down to what the EiA forum community wants. If many people are against having TCP/IP then that will slow down the implementation of the feature. If people really want the feature then they need to express it sooner than later. As I told Marshall and his response change my feelings about the game completely that it would be more important to bring about IP play and less on AI Play In my opinion. I have voiced my concern to him and the answer was very reasonable.

Personally I'm not for or against. I actually don't see the point and my arguments so far revolve around this position. We're asking Matrix to perform significant work, and really guys its not trivial, to implement something that I struggle to understand as being a better communications model than we already have.

Now, as I say in my previous email, if what we're really talking about is making the PBEM interface to the human somewhat easier/faster/neater then sure, I'm all for it and that programming work would be trivial in comparison to building up a whole client/server IP based system.

Cheers,
Mooepre.

ORIGINAL: zaquex

ORIGINAL: moopere

ORIGINAL: zaquex

Playing a TCP/IP based game with more than 6 participants is in itself nothing strange; millions of players do it every day.

I'm not a big gamer in general so this surprises me. For my benefit, can you name a single title where about 6 known players all arrive at their computers at the same time for the same length of time in order to game together as a game of this type requires?

Its fairly common in games like EVE, WoW, CS etc but its besides the point there is no requirement to have 7 players online for the game to progress no more than it is for a PBEM game and it will never progress slower than a PBEM game.

I play WoW and CS and I have a different experience to you obviously. Getting even 4 of my mates to promise to turn up is easy, having them -actually- turn up and for a long enough time period to make it worthwhile is where the theory falls down.

Note that its not a problem at all to find 6 or more ad-hoc players at any time of the day or night, the problem is getting 6 named/known guys who have real lives to deal with as well as game playing. I'll admit that this problem might be mainly due to my age bracket though....still, whats Matrix's average buying client? 15, 35 or 55?

Cheers,
Moopere

ORIGINAL: moopere

If you are waiting days for an email then your net connection would have to be so bad that you couldn't play by TCPIP anyway. If your net connection is good, and, as I say in my original post all 7 players are at their terminals at the same time then you could get 30 second turnaround on players emails/turns.

As I suspected, what we're really talking about here is all the stuffing around with files...saving them here not saving them there..making sure the extensions are correct...blah, blah, blah. The interface to PBEM could be made seamless if desired with EiA picking up all emails with a certain encoded (or other) string in the subject from the default email program.

Cheers, M.

1. Not true. Your bandwidth capability has very little to do with how fast or how slow you receive emails. There are queues from the server ends, etc.

2. How much more complex would it be to implement a TCP/IP Client/Server environment within EiA than to create a "seamless interface" where EiA directly grabbed emails with some "encoding" directly from your email account. How would this work if you used hotmail or yahoo? Would EiA start, log onto my email account and then grab this file? What kind of security issues are there? If not, would it just grab the files whenever I opened my email account? If so, what would be the point?

I know occations where ive been sent 3 mails and two arrives within minutes but the third arrives after 6 hours - its not common a mail takes this long but it happens. There is also issues with some email accounts having limited storage space.

ORIGINAL: NeverMan

ORIGINAL: moopere

If you are waiting days for an email then your net connection would have to be so bad that you couldn't play by TCPIP anyway. If your net connection is good, and, as I say in my original post all 7 players are at their terminals at the same time then you could get 30 second turnaround on players emails/turns.

As I suspected, what we're really talking about here is all the stuffing around with files...saving them here not saving them there..making sure the extensions are correct...blah, blah, blah. The interface to PBEM could be made seamless if desired with EiA picking up all emails with a certain encoded (or other) string in the subject from the default email program.

Cheers, M.

1. Not true. Your bandwidth capability has very little to do with how fast or how slow you receive emails. There are queues from the server ends, etc.

Email queues, yes sure, but you can't really use corner case problems to make a point like this. I could also say that occasionally packet loss or routing problems will cause issues with IP connections as well.

Most decent email hosts will turn emails around in seconds and that includes time to check at the server end for virus' as well. I have a gmail account for instance which is hosted on an enormously busy server yet still turns emails around in less than a minute.

ORIGINAL: NeverMan
2. How much more complex would it be to implement a TCP/IP Client/Server environment within EiA than to create a "seamless interface" where EiA directly grabbed emails with some "encoding" directly from your email account.

Very much more. Many powers of magnitude more complex I'd suggest.

Any decent 'code hacker' could probably write something up in a couple of weekends in python which bolts onto the front of EiA in order to do as I suggest in my email above to 'clean up' the PBEM inteface. Matrix could do it even quicker because they'd not have to reverse engineer anything. But mind now we're talking about cleaning up a somewhat clunky interface to humans, not really reprogramming any part of the game proper.

ORIGINAL: NeverMan
How would this work if you used hotmail or yahoo? Would EiA start, log onto my email account and then grab this file? What kind of security issues are there? If not, would it just grab the files whenever I opened my email account? If so, what would be the point?

Well, the point, apparently, is that folks involved in this thread hate waiting days and days for each game turn to complete and imagine that we need to bolt on a whole new communication method to get around the problem. I'm just suggesting that email is already pretty quick and perhaps what we're really complaining about here is the interface of the existing PBEM system.

You would use your 'default' emailer to pick up your email - so there are no security issues there that don't already exist with your favourite email application. EiA could then scan the subject field of your emails looking for something distinctive that tells it that the email is destined for one of its PBEM games. After this its just a matter of splitting out the attached files and plonking them into the required spots in the filesystem (after a bit of sanity checking obviously).

If you had your email app looking for new mail every 30 seconds and EiA looking every 30-35 seconds then you would get the effect of direct TCP/IP connections so long as all players are actually there and sending in their moves....Its really PBEM of course, but with a no mess interface.

We should all realise by now that PBEM works as fast as the group using it. If someone wants to think about his move for 24 hours TCP/IP connections are not going to help you.

Best regards,
Moopere.

ORIGINAL: zaquex

I know occations where ive been sent 3 mails and two arrives within minutes but the third arrives after 6 hours - its not common a mail takes this long but it happens. There is also issues with some email accounts having limited storage space.

Yes, sure. As I mention above though, theres not a lot of point using corner case problems in this type of discussion.....I can also say that sometimes a router goes down and a player 'disappears' from a direct tcpip connection as well. These days, generally, email is pretty reliable. If your email host is rubbish and you want to play quickly using PBEM then get a better email host....there are a bazillion free ones out there and most work well enough for this task.

Best regards, Moopere

As I stated before that Marshall has silenced my criticism of the game since this feature has not yet been implemented. I now know for a fact that it wouldn't take much for it to be implemented and as I stated right now there are more pressing things needed to be done to get the game up to speed with the fixes needed.

Like I also stated earlier as with most things that involve the game it is up to the forum community to request this feature. If many speak up then it will come sooner than later. If not it will be much later that it come. Also as with many TCP/IP games direct hosting from Host to client computer is all that is needed. Since the Host will only be using bandwidth when a player is sending info then the host sending info back to the 7 players to update the client comps, speed will be quick and people on cable or fast dsl will be quickest to send and receive info.

Moopere just so you understand where I am coming from this info is straight from Marshal via PM. If Marshall give me an OK then I will paste the PM here to see his words exactly on this, but until then my info is directly from the source. People need to stop saying that this feature will be time consuming and difficult. As I stated before it will not, but first things must come first.

ORIGINAL: moopere

ORIGINAL: NeverMan

ORIGINAL: moopere

If you are waiting days for an email then your net connection would have to be so bad that you couldn't play by TCPIP anyway. If your net connection is good, and, as I say in my original post all 7 players are at their terminals at the same time then you could get 30 second turnaround on players emails/turns.

As I suspected, what we're really talking about here is all the stuffing around with files...saving them here not saving them there..making sure the extensions are correct...blah, blah, blah. The interface to PBEM could be made seamless if desired with EiA picking up all emails with a certain encoded (or other) string in the subject from the default email program.

Cheers, M.

1. Not true. Your bandwidth capability has very little to do with how fast or how slow you receive emails. There are queues from the server ends, etc.

Email queues, yes sure, but you can't really use corner case problems to make a point like this. I could also say that occasionally packet loss or routing problems will cause issues with IP connections as well.

You could say that and it also applies to email, since it is ultimately going over the same phsyical connections.

Most decent email hosts will turn emails around in seconds and that includes time to check at the server end for virus' as well. I have a gmail account for instance which is hosted on an enormously busy server yet still turns emails around in less than a minute.

I haven't experienced this. I know of quite a bit of emails I have sent that didn't get received for a few hours and vice-versa.

ORIGINAL: NeverMan
2. How much more complex would it be to implement a TCP/IP Client/Server environment within EiA than to create a "seamless interface" where EiA directly grabbed emails with some "encoding" directly from your email account.

Very much more. Many powers of magnitude more complex I'd suggest.

Any decent 'code hacker' could probably write something up in a couple of weekends in python which bolts onto the front of EiA in order to do as I suggest in my email above to 'clean up' the PBEM inteface. Matrix could do it even quicker because they'd not have to reverse engineer anything. But mind now we're talking about cleaning up a somewhat clunky interface to humans, not really reprogramming any part of the game proper.

ORIGINAL: NeverMan
How would this work if you used hotmail or yahoo? Would EiA start, log onto my email account and then grab this file? What kind of security issues are there? If not, would it just grab the files whenever I opened my email account? If so, what would be the point?

Well, the point, apparently, is that folks involved in this thread hate waiting days and days for each game turn to complete and imagine that we need to bolt on a whole new communication method to get around the problem. I'm just suggesting that email is already pretty quick and perhaps what we're really complaining about here is the interface of the existing PBEM system.

You would use your 'default' emailer to pick up your email - so there are no security issues there that don't already exist with your favourite email application. EiA could then scan the subject field of your emails looking for something distinctive that tells it that the email is destined for one of its PBEM games. After this its just a matter of splitting out the attached files and plonking them into the required spots in the filesystem (after a bit of sanity checking obviously).

If you had your email app looking for new mail every 30 seconds and EiA looking every 30-35 seconds then you would get the effect of direct TCP/IP connections so long as all players are actually there and sending in their moves....Its really PBEM of course, but with a no mess interface.

Again, personally, I dont use an "email app", I use yahoo. A lot of people use systems like that. So basically you are saying that I would have to login to my email account and leave it open for EiA to check? Not sure how advantageous that would be since at that point I could just check it myself. No security issues? I'm a little skeptical on that, but given, probably no more than using a TCP/IP connection, so I will moot that.

We should all realise by now that PBEM works as fast as the group using it. If someone wants to think about his move for 24 hours TCP/IP connections are not going to help you.

TCP/IP is faster, period. You are trying to argue that an email conversation is faster than live chat and you are wrong, sorry.

Best regards,
Moopere.

TCP/IP client/server would be the best possible model.
 
BTW this works extremely well for games like Dominions and Civ4 Pitboss for example. It's tried and true. Those of us who have experience with will assure you that it is far superior to PBEM.
 
TBH so far, PBEM in EiANW is a massive pain. Even if the game sticks with PBEM this could be very much improved. As of now it seems unlikely most 7 player games will get out of the first year of play.

Dominions was designed from the get-go as a WEGO system with randomized interleaving, and thus is completely irrelevant to how to optimize a board game that not only isn't WEGO, but deliberately uses turn sequencing as a game-balance mechanism.  Furthermore, there's more to do in many EiA phases -- more complicated negotiations, analysis of what's changed, looking for high-forage routes, planning purchases, checking for double-move vulnerabilities and computing blockade-running odds... that make the game inherently quite slow.

Complaining about the transport mechanism as the bottleneck as rather similar to attempting to make a Corolla into a racing demon by replacing the ignition with keyless entry.  Tapping a button might be faster than turning a key, but that's not the bottleneck.  Amdahl's Law, after all.

Of course, you could attempt to prove people wrong by using a different transport mechanism like CVS.  'cvs update' from the shared repository, copy, boom.  Prove e-mail is the problem -- you've got the ability.  It's not like shared-file exchange is a novel program -- anybody who's ever worked on a non-trivial programming project with a team should know about version control systems.  Probably trivially scriptable for the client side -- could even write a daemon in Perl that'd periodically check and update.  And it still wouldn't save very much time, which is why I'm not going to bother to write such scripts or run a CVS server to do it.

Better is a redesign with no computation on the client and only trusted data transfer, but when you consider that every player sends the *same* data to all sides including the host, and that you can start with arbitrarily large armies because the game doesn't check (trivially doable with a hex editor), and that various illegalities can be committed (see, for instance, my screenshot of a Turkish AI collocating depots with mine, and collocating corps with mine -- without fighting or sieging -- when at war!), that should tell you that there's fairly limited verification going on.  Things like PBEM Quick Combat or naval-interception rolls (done client-side), likewise.  And as I pointed out, this isn't a transport issue -- it's a software architecture/design issue.

the way EIA is designed with the I GO U GO turn system tcp and email could in theory play at the same speed. as it stands, even if u were playin over tcp u would still have to wait for everyones turn which would take upwards of 1 hours in total i would guess. with pbem u could have everyone take their turns on the same night (would never happen right) and it would take roughly the same time.

the problem is the turn system. if it was wego then tcp would be perfect, but it aint so whats the point.

Actually; parts of EIA can be changed to a WEGO system - the diplomacy & econ phases
have no real need for sequential turns - either under PBEM or TCP.

ORIGINAL: tonedog

the way EIA is designed with the I GO U GO turn system tcp and email could in theory play at the same speed. as it stands, even if u were playin over tcp u would still have to wait for everyones turn which would take upwards of 1 hours in total i would guess. with pbem u could have everyone take their turns on the same night (would never happen right) and it would take roughly the same time.

the problem is the turn system. if it was wego then tcp would be perfect, but it aint so whats the point.

The problem is that if EiA was build on a I GO U GO frame, it was finished on a WEGO chrome : call to allies, DOW during movement for forced access or naval transport of enemy corp, naval interception, combined moves, retirement into cities, chit choice, combat reinforcement ...

In peace time it's a I GO U GO, during war time it's becoming a WEGO ... I wil let you made the choice of your goal to play EiA. For me it's the latter.[:D]

Missing this part is missing the spice of the game. Like taking a car and only have the 3rd gear. Will remain a corolla or a race car. You can use it and drive but you're missing a lot of opportunity.

Parallizing the diplomacy and economic phases may be helpful, but there's also some grounds for caution.

Splitting diplomacy into multiple parallel steps might be appropriate -- there is a certain sequence of events which you can't fully make conditional in advance, at least in the present UI.  For instance, whether one is willing to respond to a call to allies might depend upon what other DOWs were issued.  The same might hold for backing down on DOWs against minors.  There's a number of plausible dependencies there.

The economic phases impose some possible dependencies -- ship construction may provoke more ship construction, while the sudden recall of Turkish feudals to their home provinces may alter one's procurement plans.

There is an important philosophical question how to proceed with development of EiANM.
 
The original game is constructed around the constraints of a tabletop game and many of those constraints doesnt apply to a computerized game, some are even disruptive.
 
So a question I think matrix/marshall needs to think about is whats most important, to keep the game true to the original or to make an as good computer game as possible. I think this question is very important. There is an obvious risk that if the answer of this question isn't clear the program will end up as neither very true to EiA or as good as it could be.
 
I'm very split about what to prioritize and I cant make up my mind whats best path. On the other hand its not up to me its up to Marshall, Matrix and possibly ADG. In the end I would probably be happy with either although im sure whatever choice is made there will always be some that are upset. In any case I think this might be one of the most important question for them to answer.

ORIGINAL: NeverMan
TCP/IP is faster, period. You are trying to argue that an email conversation is faster than live chat and you are wrong, sorry.

Live chat? I thought we were talking about an IGOUGO gaming system? I assume that you -do- realise email is sent over tcp/ip as its transport protocol?