The CMx2, PBEM poll

[Wartgamer]

I think that the bottom line is that PBEM could be a reality if the designers kept an open eye for it and developed ways to convey situational awareness without all the CLOGGING.

[hoolaman]

Originally posted by aka_tom_w:

Can someone please tell me why TCP/IP is not threatened the same way PBEM is?

There has not been ONE word of discussion about how or if TCP/IP play will or might be impacted, BUT somehow the game files might be too big for PBEM but "no problem" for TCP/IP??

I say this because Steve has lumped TCP/IP in the same "no problem" category as solo play or LAN play or hotseat head to head play.

Does this not at least make some other folks here besides me curious?

(confused)

:confused:

-tom w

I'll second that. I asked the same question in one of the other PBEM threads.

If a PBEM file ends up being 10+ MB surely an internet connection will need to transfer a similar 10+ MB every turn? This would make TCP/IP even MORE tedious and impractical than PBEM if data transfers were exceedingly large.

That would mean, if I assume correctly, that there would be NO remote play at all. The options would be LAN (maybe also a problem) and hotseat and thats it.

Is there some technical trick I am missing here?

[karch]

I only play PBEM because of the limited time I have available. I turn around maybe 5-10 turns a week. That's all I have time for.

I hope the only limitation ends up being file size. It's a compromise I could live with. With current broadband speeds ( sorry modem users) I'd guess the biggest PBEM file size that would be manageable is arount 100MB or so... and if upload/download speeds keep increasing, that could jump to 200MB+ per movie file and I'd sure still play.

Otherwise I would end up playing agains the computer (which I already do when I get a spare moment). I maybe play 2-4 IP games a year. Because of my schedule, 9-10 hr workday, 2hr commute each way and trying to be a dad, it's nearly impossible for me to play someone else live. It's not just a decision of how I like to play, it's really the only way I can play against another human.

BUUUUUT. I think I'd still buy it because it would be such a better game. So mark me as a disgruntled buyer.... and would probably get 2-3 other friends to buy it. FWIW

[karch]

as for potential LAN issues, my guess is that they will go back to BOTH comptuers computing the turn if they can get the calculations to be identical with different processors/OSs. I seem to recall that was the original plan for TCP/IP, but the math they were using ended up being slightly different (rounding differences) and occasionally you'd get different results from 2 players computing the same movie. Tank A shoots at Tank B. Player 1 calculates a miss, player 2 calculates a HIT. Rare, but made them change the IP play to one player calculating and sending the result over IP.

SO, I'd guess the HUUUUUGE file size is irrelevent for IP play if this is the case. And this just gave me an idea....

If you can guarantee both players can calculate the movie EXACTLY the same... (don't shoot me) what if you don't ever actually send the movie file between players? You actually email the file after you plan your moves but ..JUST.. before you calculate the movie. You email your planned moves only. No results.

The planned moves must be MUCH smaller than the movie file. If we're sure both players will calculate the result the same way... you end up emailing a much smaller file... calculating the movie upon receiving it, and then watching it.

Steve... any way something along these lines could bring the horse back to life?

[ March 05, 2005, 03:42 PM: Message edited by: karch ]

[aka_tom_w]

"If you can guarantee both players can calculate the movie EXACTLY the same."

Well I am not a programmer

BUT

They tried that before and like you said rounding errors in cpu's that don't do MATH EXACTLY the same way were suggested to be the cause of that problem.

Sorry, but I am not sure what is different this time around?

:confused:

-tom w

[Wartgamer]

They don't have to calculate. One side always calculates. It develops several databases and the movie can be assembled from those databases.

[Battlefront.com]

Jon,

In terms of making the fallacy come true, designing and building the game in it's entirety, and only then trying to figure out how to include various modes of play seems to be a good way to go about it. And that seems to be what you're saying Steve. You've identified that file size might be a problem, but you've said you aren't going to do anything about it until it's to late to do anything about it. Good plan.

You are either quite thick or you aren't reading my posts. I'll give you the benefit of the doubt one more time, but that's it. If you don't "get it" after this explanation then I'll be left with the other choice

The problem that MIGHT kill off PBEM is file size. There is no practical way to determine what the file size will be until we're done coding the game's core engine. Period.

With me so far? Good!

OK, so if file size is the potential PBEM killer, and we can't predict file size ahead of time. what options does that leave us with? Only two:

1. We can code the game as we see fit and then see if PBEM is viable.

2. We can identify the parts of the game system that could potentially add up to excessive file size and cut them out before coding them in a kind of preemptive strike.

Still with me? Great!

So, if PBEM is a feature that we must absolutely, under pain of death, support in a usable format... we must cut out features before we begin otherwise we risk spending a ton of resources and time for absolutely no gain. Customers will get excited about features that will be slashed out, and in general disaster would befall us. Or... we not absolutely gurantee PBEM and make the best game possible and HOPE that it doesn't preclude PBEM support.

Hopefully you will finally, FINALLY, understand that this is the decision that faces us right now. No other options exist, despite your link that indicates the opposite.

Actually, to be honest, I'd be stunned if that was your plan, but it's the distinct impression you've given in your posts on this topic.

It is our plan because there is no other plan available. The part of the plan that you've skipped over, however, is the part where we said "well, PBEM is important but not as important as all these other features. Therefore, we will proceed to build the best game possible even though we understand that there is a risk, but not a certainty, of PBEM being lost in the process."

Now, in an effort to be constructive: could you explain how you expect TCP will work if you can't get Async to work? Isn't the same amount of data pushing required in either case?

I've already explained this somewhere in one of these God awful PBEM threads. Two major things:

1. TCP/IP uses binary data transfer. PBEM files must be converted to text for email transfer. The latter adds about 33% overhead to the data, and there isn't a thing we can do about it.

2. There are all sorts of tricks we can do to have some data transfered back and forth between the systems while people are in the Orders Phase. These tricks are unavailable for PBEM play because it is inherently impossible to do so.

Having said that, yes... in theory (as with any game) we could produce something that will make TCP/IP impractical as well. We can't do anything about that either, at this stage, but if it does happen we have more options available to us than we have for PBEM.

Also, how do you envisage CoPlay being played - is getting more than two people to schedule a TCP CoPlay session realistic? I know people will do it - heck, CoPlay is probably the most interesting feature of CMx2 I've yet seen - but will they do it often? Will lots of people do it, if they have to go back to the bad old days of board-gaming game-scheduling?

Look at the explosion of massive multi-player ONLY games. We don't have fears about CoPlay being unused. The thought of a CoPlay PBEM game though... ouch! Bad enough when one person takes 2-3 days to send back a file... just imagine 16 people being stuck waiting for that one person. Blech

So, for example, the only change to map data sent might be "new shellhole size 3 at 145-68; rubble light building at 147-67". That's it. Since everything else is the same, it just gets lifted out of the file on the local machine. Same for ammo counts and morale states, etc.

Check out the size of a CMx1 scenario file to see how much savings would be had compared to a PBEM turn in the thick of battle for that scenario. The scenario file size is pretty much the same as the savings you are talking about gaining.

Oh, one last point - Async players, almost by definition I should think, don't mind waiting for long file downloads. TCP players would mind, I imagine.

Totally agree on that point.

Steve

[RMC]

Originally posted by Hoolaman:

If a PBEM file ends up being 10+ MB surely an internet connection will need to transfer a similar 10+ MB every turn? This would make TCP/IP even MORE tedious and impractical than PBEM if data transfers were exceedingly large.

That would mean, if I assume correctly, that there would be NO remote play at all. The options would be LAN (maybe also a problem) and hotseat and thats it.

Is there some technical trick I am missing here?

The technical trick is client/server computing.

One player hosts the game and his machine is the server that adjudicates everything. Data is constantly being sent between the machines, but it doesn't add up to the big file of PBEM because only one machine needs to do the calculations. The server can send only what the client needs to be able to see what is happening.

So a more complex simulation underlying CMX2 may not be suitable for PBEM, but TCP/IP would still be feasible.

[aka_tom_w]

yes..

Good thinking

this is pretty much what Steve has suggested above.

So TCP/IP appears somewhat "safe" at the moment.

Phew.... Thats a Relief

-tom w

Originally posted by RMC:

</font><blockquote>quote:</font><hr />Originally posted by Hoolaman:

If a PBEM file ends up being 10+ MB surely an internet connection will need to transfer a similar 10+ MB every turn? This would make TCP/IP even MORE tedious and impractical than PBEM if data transfers were exceedingly large.

That would mean, if I assume correctly, that there would be NO remote play at all. The options would be LAN (maybe also a problem) and hotseat and thats it.

Is there some technical trick I am missing here?

The technical trick is client/server computing.

One player hosts the game and his machine is the server that adjudicates everything. Data is constantly being sent between the machines, but it doesn't add up to the big file of PBEM because only one machine needs to do the calculations. The server can send only what the client needs to be able to see what is happening.

So a more complex simulation underlying CMX2 may not be suitable for PBEM, but TCP/IP would still be feasible. </font>

[Battlefront.com]

Tero,

I for one am not even trying to say that PBEM is the game. What I am saying is that PBEM is the sole feature that keeps me playing CMx1 games. I do not support the (supposed) argument that it is not worth your while to produce a product without PBEM capability. But since I do not play FPS or simulator games online I find it hard to imagine I would start playing CMx2 online just because it is so absolutely wonderful.

This presumes, of course, that there is not much fun to be had in the single player experience. I can't say with absolute certainty how much better CMx2's will be than CMx1, but I know it will be clearly better.

IMO supposing I or others subscribed to your version of the PBEM fraction mission statement would mean I would not be equally surprised if you started converting CMx2 to PS2 and XBOX. ?

If it were feasible to do this, we would. Inherently we are a game developer... not a PC game developer. We are only the latter out of necessity since game boxes, as neato as they might be, are not up to the task of a CM type game.

But obviously you have some sort of signs and portents of things to come, otherwise you would not have brought this entire issue up.

Sure we do. We understand that with the introduction of various features we are increasing the data processing by a huge amount. What we don't know, and can't know, at this point is what the practical implications might wind up being.

So, in theory, you could make a save of a TCP/IP game and, again in theory, make that file transferable between systems ? ?

No. There would be no movie playback in that case, just the final state of the turn. Not an option.

IIRC CMx1 does not work in native OSX.

Correct because OSX did not exist when we wrote the code. So again, you put up a big stuffy strawman

Yep. And I as I have pointed out before SMTP/IMAP is not the only method of transfer available.

Of course if some sort of FTP server arrangement worked, that would be fine by us. But then it isn't PBEM any more.

I work in a mixed platform environment and while there are no (major) problems doing file sharing between OSX and MS server platforms I have not seen a workstation-workstation filesharing between OSX and W2K/XP work without extensive preparations.

[Battlefront.com]

Some of you remember well about the CPU rounding errors we experienced in our early CMBO TCP/IP code. Worked slick as heck, and as it should have, except for certain specific CPU combinations. Sloppy processors made for a messy situation that Charles, at the time, felt he couldn't code around so we went with the brute force method. I don't know if things are any better 5 years later, but if so... then TCP/IP is a super snap to do.

Steve

[Battlefront.com]

Meant to answer Karch's question that if we can do processing on multiple systems instead of a single one, can't that be done for PBEM too? As far as I know, and remember I am not the programming geek of this family , the answer would be yes. All PBEM really does is mimic the handoffs between two computers, though with the asynch limitations (i.e. many little packets of info can't be practically swapped by email, they have to be stored up and sent in one go).

I honestly don't know if we can overcome the mistakes of others (i.e. rounding errors), but it is something Charles will of course be looking into at some point. We aren't all that hopeful about this, since it SHOULD have worked the first time, but who the heck knows...

Steve

[JonS]

Originally posted by Battlefront.com:

With me so far? Good!

OK, so if file size is the potential PBEM killer, and we can't predict file size ahead of time. what options does that leave us with? Only two:

1. We can code the game as we see fit and then see if PBEM is viable.

2. We can identify the parts of the game system that could potentially add up to excessive file size and cut them out before coding them in a kind of pre-emptive strike.

Still with me? Great!

Yes, sure I'm with you, but you keep trotting out your false dilemma. There is a third option:

3) We (you) code the game as we (you) see fit and, knowing that file size might be a potential problem, actively seek creative ways to reduce the file size throughout the development process.

Not wait till the end. With me so far? Great!

Jon

[jeffsmith]

Theoretically that is all well & good

but I think what Steve is trying to tell us (numerous times in fact)

is that #3 is just another construct of #2 (unacceptable to BFC)

and the opposite of #1

[Malakovski]

Originally posted by Battlefront.com:

1. TCP/IP uses binary data transfer. PBEM files must be converted to text for email transfer. The latter adds about 33% overhead to the data, and there isn't a thing we can do about it.

Whoa. Hang on a second. Stop the presses. Did you just mention a 33% difference as a deal breaker for PBEM?

That's rediculous. Any amount of data that is transferrable via TCP plus 33% is still going to be something a dedicated (fanatical?) PBEM devotee would be able to transfer. Any amount of data plus 333% would still be doable.

Are we getting all worried for nothing? I mean, these turn files will literally have to be hundreds of megabytes for asynchronous play to be impractical, assuming broadband (no problem for me and many opponents) and alternate data transfer methods (FTP, and so on, also not a problem).

So...I know just glancing at the proposed features it's obvious there is going to be a lot more data, but it is really a reasonable fear that we are going to be looking at, say 200 MB or more turn files? And if they're that big, then text encoding is moot, and some other compression algorithm can be used.

Sure, there's a good chance, maybe almost a sure thing that turn files will be more than 10 MB, and therefore not easily transferrable by normal email, but wouldn't it be better to say, "an alternate method of asynchronous play is likely to be necessary" rather than the stark and panic-inducing "PBEM may not make it?" Because unless there is so much uncompressible data that one minute of action is many hundreds of megabytes of data, which seems very unlikely, asynchronous play will be perfectly possible, and we're all getting in a huff for nothing.

So let's drop the word "email" for the moment. I could care less how the data is transferred, so long as it's asynchronous. Do you really think there is any reasonable chance that one turn of compressed data will be more than 200 MB? Come on. You could probably model nuclear weapons on at atomic level and end up with a data file smaller than that! You can put a freaking encyclopedia on freaking floppy disks, and one minute of largely abstracted (and even if it's 1:1 with 1m terrain, it's still largely abstacted) WWII combat can't fit into 200 MB?!

Because that is what it is going to take for asynchronous play to be impossible. I guess I don't have anything to worry about after all...

[Wartgamer]

3) We (you) code the game as we (you) see fit and, knowing that file size might be a potential problem, actively seek creative ways to reduce the file size throughout the development process.

Not wait till the end. With me so far? Great!

True. An example is the 1m^2 resolution of the map. In another thread, the designer said that might have to be bumped up if it chokes the cpu. It should also be 'sized' for other considerations beyond gagging the cpu. Its effect on solo play crunch time for starters and other game considerations also. Just loading or saving a game may take considerable time.

Its like when you paint or sculpt something. You can't have your face up against the canvas/stone. You have to step back and take in the whole thing as it is being developed.

[Wartgamer]

If a squad is 1:1 represented, that means each soldier in that squad has to have a position on the map. This changes with respect to time so its another state/time database choker. A running man may actually go 2-3 meters every second. Will 1m^2 resolution really allow speeds to be represented?

Will the game need to track each man's speed? Will movement rate be a 1:1 trackable quantity? Each man is supposedly being tracked for ammo, status (pinned, etc), perhaps fitness. Position must be tracked. Posture (prone, kneeling, etc) also? Facing? Which unit or fireteam he is in?

Does this mean that there will be 1:1 databases for each soldier??

All these state/time database CLOGGER's are going to add up.

[ March 05, 2005, 09:27 PM: Message edited by: Wartgamer ]

[Jaws]

Finally finished the doll...

C

[Marco Bergman]

Originally posted by Battlefront.com:

1. TCP/IP uses binary data transfer. PBEM files must be converted to text for email transfer. The latter adds about 33% overhead to the data, and there isn't a thing we can do about it.

Just for interest's sake, why are email files converted to text? Why can't they be in some weird CM binary format, or even compressed/decompressed by the game engine? I've always wondered about this. First thing I do with a PBEM file is zip it... due, no doubt, to being on 56K modem.

[Sergei]

Marco, e-mail is always text. If you send a file attachment, it is encoded to text by sender and then decoded by receiver back to binary.

[Berlichtingen]

A...

but I doubt I'd play it much

[Steiner14]

probably B - my time is way too precious than to waste it with TCP/IP.

PBEM is the only way i play CM since years.

VERY disappointed about that plans. Good bye CM.

[Spiny Mouse]

A

I've played CMx1 against the AI or TCP/IP on my home network against my kids many more times than in a PBEM.

Still, losing PBEM would be a great loss.

[GJK]

Well, I've read posts from page 1, and some from page 2 of this thread, and now the posts from page 9 - and in 230+ posts - poor Steve has had to repeat the same thing over and over again. In otherwords, nothing was accomplished with all this whining.

I thought it was pretty much a no-brainer to assume that TCP/IP play would involve streaming packets of data that could be transferred during orders plotting and even during movie playback phases, thus making the filesize pretty much a non-issue.

I can also see how huge filesizes could kill the possiblity of pbem games. I can understand BFC not making pbem a priority even.

Do I want pbem? Yes, it's my only method of play at the moment for CMx1 games. Will I not buy CMx2 if there is no pbem? Can't say. I'll probably have a mini-protest at first, but temptation will overcome me and I'll wind up getting it. I'm sure BFC is counting on that from us.

No pbem would kill my vs human games though, I just don't care for TCP/IP. I hate that rushed feeling of turn plotting. I hate telling my playing opponent to hold on while I tend to real life issues, and I hate having to bypass my router because I can't get a solid connection otherwise.

And ok, sorry to call everyone whiners - guess I'm whining too in my own way.

[Malakovski]

Originally posted by GJK:

And ok, sorry to call everyone whiners - guess I'm whining too in my own way.

Yes, you are!

I wouldn't say it hasn't done any good though. Steve's posts have mostly been repetitious, but there have been some new bits now and then, and as a result I understand their position better. I still think it's dead wrong, that it's a betrayal of those who have been most devoted and loyal to them, blah blah blah, but at least now I know that it's not a crass economic decision, a pandering to gamers who like power-ups and god mode, or anything like that. It's just that for some reason Steven and the others think--and I don't know why, they seem like smart fellas you know, revolutionized strategy gaming and all that--decided PBEM was less important than other features. If you accept that, then Steve's resoning is perfectly solid.

However, all that may be moot. This has been my suspicion, and I'm getting more certain. I really hope Steve responds to my last post about whether this PBEM scare isn't all for nothing. Because it seems to me, either we're all getting worked up for nothing, or no form of multiplayer will be possible.

If TCP/IP is possible, that puts a limit on the data that needs to be transferred for one turn. Yes, you can use this and that trick to shrink it, but if we drop email as the delivery means for the async turns, you can use the same compression. As far as other tricks go, streaming and so on, unless both computers compute the turn with the same results--a trick which would work just as well for async--then one computer has to compute and then the data has to be sent. How long is this going to take? For TCP/IP to work, it can't take terribly long.

Therefore no matter what tricks you use to compress and stream the data, there is just no way an asynchronous play file is going to impractically large, if TCP is not going to be a problem also, and Steve seems to think it's not.

Therefore, if TCP/IP play works, asynchronous play will work. QED and all that. Some innovation will be required, but that's not exactly lacking in these parts.

So we may not be able to use email to transmit the asynchronous play file, but who gives a flying F how it's transfered? We can still play the same way we have been, which is, in my not-at-all humble opinion, and in the opinion of at least a few thousand others, the only way to play.

[ March 06, 2005, 07:06 AM: Message edited by: Malakovski ]