Co-op Needed!

[Doug Williams]

Neither do I Steve. Thanks for the explanation.

[glitch]

A few human players, each commanding a platoon in realtime with an optional overall commander giving objectives/orders to the players, against other human teams or ai would be fantastic.

but don't bet the farm on it

[purpheart23]

+1 for co-op. Betting the farm doesn't make much business sense that's true, but if you really wanna test how loyal your customer base is.... you'd do it. Come on Steve.... do it.

[poesel]

Not necessarily. I think it would be pretty fun to have players commanding a Platoon sized force in RealTime. WeGoers would probably hate it, but RealTime I think it would be really fun. And that is well within the scope of the current game environment.

I wouldn't hate it. Just saying

I just noticed that Coplay for RT is much more complex than for Wego and I was (naturally) only thinking about Wego Coplay.

In fact Wego Coplay is already possible with some limitations. For example in a 2v2 each side shares a password. Each team agrees who plays which unit. Player 1 moves his units and saves the game. Then sends the savegame to player 2 of the same team. He finishes the turn and sends it to the other team and so on.

The limitation is of course that you see all units and orders of your co-commander which takes aways lots of the fun. That's probably the reason nobody does it.

Of course I do not know how much work it would be to tweak CM to have more than one friendly side but I'm pretty sure its much less for Wego than for RT. Maybe that's a route to introduce that feature and see how much support it gets.

[SlowMotion]

In this user made WEGO CoPlay wouldn't only one player per side see the movie?

[poesel]

In this user made WEGO CoPlay wouldn't only one player per side see the movie?

Since a side shares a password they can both see the movie (assuming a shared dropbox folder). But one had to wait for the others savegame to give orders. Some discipline would be necessary to pull that off.

The waiting is of course inherent in Coop Wego.

[SlowMotion]

So basically a clumsy WEGO CoPlay is possible now. Quite a bit extra work, but it might be interesting to see what kind of results you'd get. Trying to synchronize movement of units controlled by 2 players would be one tricky thing. Especially if planning was done using text only.

[Vinnart]

Not knowing Sudden Strike3, what kind of problems were there?

Up until Sudden Strike 3 the series was immensely popular for at least 5 yrs or so selling 2 million copies (at least this is what they claim). Of the entire series Sudden Strike 2 was their most realized, and most popular version. To find, and join games players used the Sudden Strike lobby in Gamespy Arcade. People would post their IP address there, and players would put that IP in the game to join.

When Sudden Strike 3 came out it had much better graphics than it’s predecessors, but that was it! Command and control wise they took some steps backward, and their greatest mistake that caused it to fail was the piss poor support for what made it popular in the first place, which was Co-Op multiplayer. They abandoned Gamespy, and tried a lobby feature that was in the game. It sucked! It did not show games listed, so no one could find games to join. Hence it failed. Talk about stupid decisions. Fireglow put all that work making the game, and failed to have support for the very thing that made it a hit in the first place.

[Destraex1]

To restate what I say every time this comes up...

Conceptually I would *love* to have CoOp for CM. In fact, I originally designed CMx2 in 2004 to be CoOp from the ground up. But that got abandoned very quickly because the work necessary to pull it off is massive. Given a choice between a massive effort for CoPlay and a massive effort into the gameplay itself... it's a no brainer. Until we've basically run out of ways to dramatically improve the game for 100% of our customer base, we will not divert such huge resources towards any minority feature. And CoPlay will definitely be a minority option. Maybe less so after some major changes to the core of the game first, so those have to happen first.

The only way this will be shortcut is if a military client funds the resources necessary to make it happen. From a military standpoint a few hundred thousand bucks is chump change, but to us it's an extremely risky venture with absolutely less payback potential than other things we could do with the same amount of money.

Yes, but those games are inherently designed for cooperative play. It's been 15 years since anybody wanted to play a FPS solo. Hell, who here remembers "LAN Parties" when people used to bring their clunky desktops and CRT monitors over to someone's house or place of work to hook together for a 10 hour marathon gaming session? I do

What do you mean remember! I am going to a LAN in a few weeks. These days though the wives prefer to plan on not being their when the beer & fun starts... its not like the old days when all of the bachelors could just drop in with a PC with less than an hours notice.

Still its a good time and most of us are old enough to remember the original COD played at a LAN.

[Steiner14]

poesel71,

very interesting ideas. I think it could be helpful to develop a simple and well working co-op-methodology for the current system, so in case PBEM-players who would like to try it, could easily take a finished concept.

One big problem i see with co-op PBEM now, is the time- factor until the oponent responds. Right now PBEM turn rates already are too much for many players, but with every new player that is added with co-op-play, the time would add. Two players one side, double the time for each turn, three players x3, four players x4. :eek:

1. A simple system to reduce turn times dramatically

I think i have found a solution, how the problem of adding up delay times with every co-op-player could almost completely be eliminated. With a simple token-mechanism. A token-mechanism is a mechanism, to share resources used by several participants (think of a bus in a computer and several components using it).

For PBEM it would work that way:

Let's say a side has finished the turn and sent it.

Player B discovers the file in his mailbox first, and he would have time to plot his moves, but ofcourse he doesn't know, when player A will have time to plot his moves and so he has to wait. Awful.

Solution: As soon as one player on one side wants to plot his moves, he notices via email the other players that he is now plotting moves (he has taken the "token"). If he has not received an email from another player who already claimed the token, he now is in possesion of the token. The plotting for all other players is now locked. The other players receiving his Token message also know, that they have to wait, until they either receive a new saved file from this player, or that the working player gives back the "token" without sending a saved file.

To optimize the system even further, the token-message should include an estimation of the player who takes the token, when he thinks he will have finished his plotting and send out the file and give back the token:

For example:

Player A checks his inbox. Turn received and no other player has claimed the token. He writes an email:

TOKEN Player A - expect file within 60 minutes.

Or:

PLOTTING LOCKED by Player A - expect file within 60 minutes.

When he finishes his turn, he saves the file and sends it via mail:

TOKEN FREE or PLOTTING UNLOCKED

Since the token is now free whatever player now grabs the "token" again, blocks all others from working on their turn again.

2. File naming

A simple but strict nomenclature is necessary, that confusion is reduced to a minimum and that allows with a simple look at the filenames, immediately to know the status of the game and which player still has not yet plotted his moves.

I made only the best experiences with "ScenarioName000" or similar namings. Two digits are to few, four are unnessarily large.

To deal with several players on one side, i'd suggest each player receives a letter before the battle starts: A, B, C,...

The naming of the saved file from player B would be "ScenarioName000B".

The player who finishes a turn by clicking the red button, could add a "Z" (it's highly improbable that ever more than 25 players will play on one side... )

From this naming convention it becomes immediately clear, from which player a turn is missing.

ScenarioName003A

ScenarioName003B

ScenarioName003Z

ScenarioName004B

This file list shows: File003: turn was finished.

File004 is in progress and waiting for player A plotting his moves.

3. The Turn System

To keep the turn rate as fast as possvile, it is good if all players of the opposing side receive the finished turn at once.

The one who is the first who wants to plot his moves, simply uses the token-system and sends out a short token notice to his "comrades" like explained above.

4. Avoiding conflicts between players

To avoid endless discussions or even conflicts within one side, a clear hierarchy should be applied before the first move is plotted:

Each side must agree on one player, who has the final word in the case of different opinions or about tactics.

5. Optional: A Dedicated Tactical Leader

Maybe an interesting experience of this kind of co-op-play could be, if a tactical leader not plotting any moves, is commanding, while players are fullfilling his tactical orders - or try to do so. The tactical leader does not participate himself in plotting moves, he issues orders or receives suggestions/ideas/comments.

I have two options of the tactical leader in mind:

Option 1: The Weak Tactical Leader

He has the last word on tactics, but he has no possibility to correct the turns of his players. He is acting more as a supervisor. When the last player has plotted his turns and finsishes the turn by pressing the red button, the WTL receives only the results when the oponent has responded and afterwards can give his orders to his players.

To increase his influence, probably it will be necessary to give him competences to sanction a player, if this player does not follow the given orders. For example he could take away the command from one player for a certain amount of turns and give it to another player, or plot the turns himself - or even to exclude players from the rest of the battle.

Option 2: The Absolute Tactical Leader

In this concept only the TacLeader is allowed to press the red button to finish turns!

He has the last word and in case that a player is ignoring orders, he can demand from the player to correct his moves and resend the savefile to finish the turn.

This co-op-play would result in slower turn rates, because only the Tactical Leader can finish turns and send them out to the oposing side and not the last player sending it out immediately after finishing his plots.

Feel free to criticize and contribute. I'm sure soon we will have a simple, solid and practical co-op-procedure in no time -without the need for BFC to spend any development time.

[SlowMotion]

Steiner14:

1-3: I think something like this could be interesting, BUT it should not use email. Instead Dropbox or other similar system for file transfers. IMO the system that has to do with whose turn it is, which players still need to plot their moves and all file copying should be done with a simple application that maybe somehow interacts with H2HH. If done manually some player would probably break the system somehow sooner or later by using wrong file names or some other way.

4-5: conflicts between players - this is where things get interesting

[Steiner14]

Steiner14:

1-3: I think something like this could be interesting, BUT it should not use email. Instead Dropbox or other similar system for file transfers.

Good idea. But it needs that all players of one side have dropbox installed. As long as it is free, i guess it is not a big problem.

If a turn is finished (red button pressed and file saved) the file either can be sent directly to the players of the other side via email or it could be made public via dropbox and the email contains only the link to the next turn.

So as organizational prerequisites we have:

1. Every player of each side must agree either on using email or using Dropbox. If one player does not use Dropbox, it can't be used.

2. All of the oponent players must agree on how the turns are exchanged: either directly via email, or with a public link on Dropbox.

3. Every player exchanges email adresses of all his "comrades" and from all oponents. This is necessary that all oposing players receive the notification of the new turn immediately. Because of a token system nobody has to wait for a certain order of players plotting their moves.

To avoid confusion in the email-adress-book, i'd suggest a formalized naming like CMFI_ScenarioName_Player'sLetter_PlayerName

e.g:

Name: CMFI_NiscemiHighway_A_poesel71

Adress: poesel71(at)gmx.net

Name: CMFI_NiscemiHighway_Oponent_C

...

To adopt the token system to Dropbox:

On Dropbox a folder called "Token" is created and a TXT-file called "_MAP BLOCKED" is stored in it. The underscore in the filename is only to make sure, that the token file will always be listed first in an alphabetical order.

If a player wants to plot his moves, he simply moves the "_MAP BLOCKED" file from the "Token" folder to the Dropbox folder.

If he is a nice guy, he will add a line of text like mentioned before "23:16 MAP LOCKED by Player A - expect my file within 60 minutes."

If another player now looks in the dropbox, he sees the file "_MAP BLOCKED". He opens it and ideally sees, when the currently working player will have it back up.

When player A has finished his plots, he saves and uploads the savefile

NiscemiHighway002A to dropbox.

and moves the token "_MAP BLOCKED" back into the "token" folder.

Ideally he also sends out an email notifying his co-players of a new file.

The next player logging in sees that the map is not blocked and a new file has been uploaded.

He moves the token from the subfolder in the main folder, adds his time estimation and plots his moves.

In the case of a modus with no Absolute Tactical Leader, the last player finishes the turn and follows the procedure that was agreed upon with the oposing side at the beginning. Either he sends every oposing player the file directly via email, or he sends a link to the public dropbox file.

IMO the system that has to do with whose turn it is, which players still need to plot their moves and all file copying should be done with a simple application that maybe somehow interacts with H2HH.

Sure this would be great, but i started this to find out how a solid, robust and practicable co-op-system could work. Once the rules and the concept have proven solid, it can immediately be tested by us and with the gained experience be refined and adopted.

Once a solidly working system has been found, a software helper would be the icing on the cake. But first we need a proven well working methodology.

If done manually some player would probably break the system somehow sooner or later by using wrong file names or some other way.

I hope this will not be a big problem, because co-op is more for experienced PBEM players. My experience is, they are not chaotic and unrealiable persons. After the first handful of moves or so, i'm quite confident that things will run quite smoothly.

4-5: conflicts between players - this is where things get interesting

I think this can become VERY interesting. Especially for players who already know PBEM and want a new experience.

Nevertheless i'm convinced someone with the last word is needed.As long as things are running well in the game, everything is easy, but once things went wrong or a disaster has become unavoidable, when a battle really becomes problematic and a player makes mistakes, while others are doing fine, there is an authority needed to keep things friendly, civil, together - and probably running as expected).

An open discussion about tactics or the moves and decisions of players would not be excluded with the presence of an authority.

Additionally to the organizational aspects i also want to take a look how the recruiting for CO-OP-games could be done in a way, players as early as possible can estimate what they can expect:

IMO the most important factor to keep things going as expected is the turn rate. It is the slowest player who determines the speed of the game. It's no problem if a player has not much time - as long as the others know about it previously and can adopt their expectations accordingly BEFORE the game has started. There are lots of players who only have time at saturdays or sundays - or other players only during the week - while other players can play every day.

Therefore i think the estimated turn rate on which days and the time zone would be critical.

And ofcourse which side a player wants to play.

Additional infos like skill level against AI and/or humans and the preferred arm of the services probably is better suited for the private communication, once a team is set up.

Personally i have always enjoyed most to play double blind. It is wonderful not to know what the battle will bring and what the oponent has. Since this is a gentleman's way to play, i'd also judge this information as very important in the recruiting phase.

To sum up the suggested recruiting info so far we have:

The turn rate the others can expect from you.

The days in the week you can participate.

Your timezone.

Do you prefer to play double blind (you're a gentleman and do not inspect the scenario and do not look at the forces of your enemy - if you know a scenario already you say so)?

Anything missing?

[Steiner14]

From this naming convention it becomes immediately clear, from which player a turn is missing.

ScenarioName003A

ScenarioName003B

ScenarioName003Z

ScenarioName004B

This naming convention does not work because it is not clear, what is the latest file.

The correct convention is ADDING each player's letter to the existing filename:

2 players:

ScenarioName003AB - this file contains the orders of both players.

ScenarioName003B - this file only from player B.

5 players:

ScenarioName003ABCD - E is missing!

ScenarioName003ABCDE - this file contains the moves of all 5 players!

ScenarioName003BCD - contains the orders of players B, C, D

ScenarioName003CD - C was the second

ScenarioName003D - D was the first player who plotted his moves

[Steiner14]

A first draft for an explanation and rule system:

Combat Mission Co-Op-play

What is Co-Op-play? Co-Op stands for co-operative multiplayer.

It means, that more than one player is playing one side! The forces of each side are split over several players. Each player receives a command about certain units and the players have to try to achieve the tactical goal by following the commands given to them by their commander.

How is it played? It uses CM's PBEM mode.

How many players can participate? Unlimited.

Isn't the waiting time for each turn increasing with each additional player? Not with the explained system. The turn rate is only affected by one single player - the one with the lowest turn rate and not by the number of players participating. This is achived with a token-system.

Prerequisites: e-mail, optional and highly recommended: Dropbox

Every player participating needs at least e-mail. For the most convenient and hassle free gaming experience also an installation of DROPBOX is recommended (www.dropbox.com).

It is a free software storage-system, that allows to store the game-files externally, easily accessible to all players with permissions.

Recruiting players:

If somone wants to play a co-op-game, he usually will have to announce it in a forum.

For a good gaming experience it is important that before a game is started, the players know what they can roughly expect.

An example Co-Op-advertisement in a forum could look like this:

Thread title: CMFI Co-Op-multiplayer recruiting!

Description:

Players interested to participate in a co-op-multiplayer PBEM battle wanted!

For those unfamiliar with co-op-play:

Instead of one player controlling all forces of one side, the command of the forces is split among several players. Please read this (link to this PDF) documentation for explanations and rules.

Wished Co-Op-size: 3 vs 3 players.

File exchange system: Dropbox required.

No absolute CMx2 beginners.

Only reliable players that are man enough to lose and do not leave a game.

Your name here

Participation: Saturday and Sunday. No turns from Mo - Fr.

"Double blind" playing style preferred (this means we play a scenario we don't know and we do not look at the oponent's forces - since it's a gentleman's agreement gentlemen are needed).

Preferred commanding system: Normal Commander and the Dedicated Commander concept are elcome.

I'm available as: player, normal commander, dedicated commander

My preferred side: Axis.

The scenarios i want to play/My scenario suggestions:

CMFI ScenarioXY. (Allied attack, 45 minutes, medium).

When enough players are reporting the players have to agree on one battle.

Then the players of every side have to agree on their commander (usually the thread-starter will be one).

Then the commander of each side is named in the thread.

Then the commanders ask their players to send them a private message with their e-mail address.

Once the commander has received all e-mail-addresses from his players he designates every player on his side a unique letter, beginning with B (A is reserved for the commander himself).

To avoid confusion in the e-mail-adress book after several battles or in the case of ongoing simultaneous battles, we suggest the following simple nomenclature for the address book:

CMgame_ScenarioName_Side_PlayerID_ForumName

e.g.

CMFI_NiscemiHighway_Axis_A_John

CMBN_D-Day_Alld_C_Peter

Once the commanders have received all e-mail adresses from their players, and they have assigned the email names, they exchange all adresses and namings with the commander of the other side (the reason for doing so, will become clear later, when the turn mechanism as broadcast mechanism will be explained).

Once the commander has received all e-mail-adresses also from the oposing side, he puts them all together and sends them to his players. The result is that everyone has the emails from everyone. Thanks to the above nomenclature there will be no confusion. A finished list for a 3vs3 multiplayer game could look like this:

CMFI_NiscemiHighway_Axis_A_John: john.c@aol.com

CMFI_NiscemiHighway_Axis_B_Fred: ffkld.k@yahoo.com

CMFI_NiscemiHighway_Axis_C_Michael: tank.c@google.com

CMFI_NiscemiHighway_Alld_A_Peter: lkdjf.sdsc@aol.com

CMFI_NiscemiHighway_Alld_B_Jeff: jeff.so@aol.com

CMFI_NiscemiHighway_Alld_C_Mark: qwer.sbgf@gmx.com

Then the commanders advise the players to add the given names and their respective addresses to the e-mail contacts.

With every player receiving the e-mail addresses of all other players the recruiting phase is finished.

What is left to do now, is the commanders have to agree which side will begin.

The commander of the beginning side chooses the PBEM password and shares it with his players.

The tactical challenge is about to begin

The commander loads the file, chooses his side, saves the file and shares it with his players:

CMFI_NiscemiHighway_setup

Now it is open to the group to determine which player will command which forces. Now is the time to speak openly about personal strenghts and weaknesses in CM! In the case of no agreement, the commander has the last word and decides.

Once the sub-commanders are assigned, the tactics should be discussed and defined. Again, the commander has the last word, but everyone is invited to share his ideas and insights.

But players must be aware that the commander's tactical decisions turn into definitve commands!

How much freedom or how defined the orders from a commander will be, is his decision. Make the best out of it.

The competences of the Commander

The commander of one side is not only the one who has the last word about the tactics, he also has the right to warn players and even penalize players for not following their orders.

The commander can even decide to remove the sub-command from one player for a certain amount of time (e.g. Player C suspended for 3 turns), and he can designate any other player or himself to take over the sub-command, or, in the case of severe misbehaviour, he can even completely exclude players.

In the case of the exclusion of a player he can also be exclude the player from any further access to the Dropbox to prevent sabotage or revenge acts of mentally instable persons.

In the case of no longer participating players (not necessarily because of misbehaviour!), all players (also the players of the oposing side) must be informed, that the email should be removed from the notification list.

In most cases the exclusion will strictly be for tactical or private and not behavioural reasons. In this case the player still can be seen as part of the community and can be given the chance to passively keep watching the battle, e.g. by being capable to still log in to the Dropbox and loading replays.

In the case of players who ask to resign because they feel they do not match the standards, they should be honored from the others.

Command system with a Dedicated Commander

For the players who are seeking the experience of a dedicated tactical commander, who does not participate in commanding units directly and therefore influence the realization of his tactical decisions directly, this system is offered.

The D.C. must concentrate on the tactical development and how well he explains his plans to the players and how well they are able to fullfill his orders.

In the case of a (temporary) exclusion of a player, the D.C. is NOT ALLOWED to take over the command of the excluded player's units! This is to prevent that experienced D.C.s exclude not so good sub-commanders with their decisive units at tipping points of a battle and take over the command directly to influence the outcome positively.

A D.C. must designate a playing sub-commander the free command, recruit a new player.

Now it's time to take a look how turns are generated:

A simple system to reduce turn times dramatically: a token

A token-mechanism is a conflict solving mechanism, to share resources used by several participants (think of a bus in a computer and several components using it, but only one component is granted acceess at a time).

With a game system, where each player must plot his moves before the next player can continue, each player would increase the time to finish a turn! To prevent this, a simple token-system is used: the player who wants to plot moves, can do so, if no other player is already plotting his moves.

In general the system works that way, that each player adds his moves but DOES NOT finish the turn (press the red finish button in the game). Instead every player simply saves the game once he has completed his orders with his unique ID. This saved file is shared among the other players and every player who wants to plot his move next, loads the latest file, plots his moves and saves it again. Only the player who plots his moves as the last one, is the one who finishes the turn by pressing the red button. That's the final file that is shared with the oponents.

We explain two suggestions for this system in detail: One system that only uses e-mail and a more comfortable system using Dropbox.

The e-mail only token system

Let's say a side has finished the turn and sent it.

Player B discovers the file in his e-mailbox first.

In a normal system with a fixed sequence, player B would have to wait until player A finished his plotting. Player C would be forced to wait for A and B, etc.

The solution with a token:

As soon as one player on one side wants to plot his moves, he notices via e-mail his other players (not the opposing players! ) that he is going to plot moves. He is taking the virtual "token", he blocks other users from plotting their moves now.

The other players receiving his token message now know, that they have to wait, until they either receive a new saved file from this player, or that the working player gives back the token without sending a saved file (maybe questions have arised and he wants to ask his commander first a few things).

To optimize the system even further, the token-message should include an estimation of the player who takes the token, when he thinks he will have finished his plotting and send out the file and give back the token:

For example:

Player A checks his inbox. A new turn was received and no other player has claimed the token. He immediately writes an email to all his "comrades":

PLOTTING LOCKED by Player A - expect my file within 60 minutes.

When he finishes his turn, he saves the file (but he does NOT press the red button until he is the last player) and sends it via mail:

PLOTTING UNLOCKED by Player A (attachement file XY).

Since the token is now free the plotting is allowed again and whatever player comes next can again grab the "token" til the last player grabs it, finishes his plotting presses the RED BUTTON and sends out the finished turn to all oponents.

The Dropbox token system

Those not familiar with dropbox should visit www.dropbox.com.

It's a free program, that offers an external storage place. Instead of sending files with e-mails, the files are uploaded to the Dropbox and shared among the players. If a turn is finished an ready to be sent to the oponents, there are two possibilities:

Either it is sent via e-mail, or it is done via Dropbox: Dropbox allows to make files publicly accessible. If Dropbox is also used for sending files to the oponent, only a link to the file is shared.

On the Dropbox a folder called "Token" is created and a TXT-file called "_MAP BLOCKED" is created and stored in it. The underscore in the filename is only to make sure, that the token file will always be listed first in an alphabetical list.

If a player wants to plot his moves, he logs on to the Dropbox account and simply moves the "_MAP BLOCKED" file from the "Token" folder to the Dropbox folder.

If he is a nice guy, he will add a line of text similar to the e-mail only system like "23:16 MAP LOCKED by Player A - expect my file within 60 minutes."

If another player now looks in the dropbox, he would see the file "_MAP BLOCKED" at the top of the file list. He opens it and ideally sees, when the currently working player will probably have his turn finished and uploaded his file.

When player A has finishes his plots, he saves (does NOT press the RED BUTTON) and uploads the savefile e.g. NiscemiHighway002A to dropbox and moves the token "_MAP BLOCKED" back into the "token" folder!

Ideally he also sends out an email notifying his co-players of a new file at the Dropbox.

The next player logging in sees that the map is not blocked (since the file is in the Token-subfolder) and a new file has been uploaded.

He moves the token from the subfolder into the main folder, adds his time estimation and plots his moves.

The last player finishes the turn and follows the procedure that was agreed upon with the oposing side at the beginning. Either he sends every opposing player the file directly via email, or he sends a link to the public dropbox file.

File naming

A simple but strict nomenclature is necessary, that confusion is reduced to a minimum and with a simple look at filenames immediately the status of the game and which player has not yet plotted his moves becomes clear.

Therefore we strongly suggest to give each player a letter before the battle starts: A, B, C,...

Where A is reserved for the commander.

Every player adds his letter at the correct alphabetical position to the savefile (Player B adds a B, player C a C,...)

The file name should at least include the scenario's name and a three digit turn number and appendix the player IDs.

e.g.

CMFI_ScenarioName003

CMFI_ScenarioName003_A

CMFI_ScenarioName003_AB

CMFI_ScenarioName003_ABC

CMFI_ScenarioName005_BC

CMFI_ScenarioName005_C

This file list shows: File003: the turn has been finished (a three player co-op-game A, B, C).

Turn 005 currently is in progress (no file with plots from all three players).

Player C and Player B have already plotted their moves, player A is missing.

The latest file is the one with the highest turn number and the most letters (exception are the finished turns, which contain no letter-appendices but only the turn number).

In this example: CMFI_ScenarioName005_BC

So player A will load this file.

Every player who wants to plot his moves, simply searches for the highest turn number with the most letters as appendix.

A co-op-turn with 3 players where all have participated must end with three letters: ABC.

4 players: ABCD, 5 players: ABCDE.

If a letter is missing, this means the moves of this player are missing.

e.g. 6 players per side:

The moves of Players C and E are missing: CMFI_ScenarioName037ABDF

Player F has plotted his moves as first: CMFI_ScenarioName025F

Good Luck!

[SlowMotion]

Good idea. But it needs that all players of one side have dropbox installed. As long as it is free, i guess it is not a big problem.

IMO Dropbox is better than email in every way for handling 10+MB turn files, so if some player still uses email he should switch to Dropbox. Thus we can skip organisational prerequisites 1-2. #3 - all dropbox folder users are already listed in folder access list, so I hope that's enough.

To adopt the token system to Dropbox:

On Dropbox a folder called "Token" is created and a TXT-file called "_MAP BLOCKED" is stored in it. The underscore in the filename is only to make sure, that the token file will always be listed first in an alphabetical order.

If a player wants to plot his moves, he simply moves the "_MAP BLOCKED" file from the "Token" folder to the Dropbox folder.

If he is a nice guy, he will add a line of text like mentioned before "23:16 MAP LOCKED by Player A - expect my file within 60 minutes."

If another player now looks in the dropbox, he sees the file "_MAP BLOCKED". He opens it and ideally sees, when the currently working player will have it back up.

When player A has finished his plots, he saves and uploads the savefile

NiscemiHighway002A to dropbox.

and moves the token "_MAP BLOCKED" back into the "token" folder.

Ideally he also sends out an email notifying his co-players of a new file.

The next player logging in sees that the map is not blocked and a new file has been uploaded.

He moves the token from the subfolder in the main folder, adds his time estimation and plots his moves.

In the case of a modus with no Absolute Tactical Leader, the last player finishes the turn and follows the procedure that was agreed upon with the oposing side at the beginning. Either he sends every oposing player the file directly via email, or he sends a link to the public dropbox file.

I hope this will not be a big problem, because co-op is more for experienced PBEM players. My experience is, they are not chaotic and unrealiable persons. After the first handful of moves or so, i'm quite confident that things will run quite smoothly.

My experience is that a system that is as simple to use as possible will be used by most people. The more can be automated with SW, the better.

So I made this UI draft of how playing CoPlay could look with such utility application, which would take care of all this file copying, game and player status tracking etc.

A game can have 3 states: either you're waiting for a turn file from opponent team, 1 or more players of your own team need to plot their moves or one player is currently plotting his moves.

How to plan turns? I think players should be able to discuss and draw the plan, so here a VERY simple draft of a planning application.

You'd take a screenshot from game map and save it to a file. This would be used as background image for drawings.

At first you could draw lines and text over this 2d image. Both could be moved later, so the setup phase plan could be edited as game progresses.

You could use text as landmarks and then discussing different parts of the map would be much easier.

http://i194.photobucket.com/albums/z213/r31070021/cmsc/cmmplanner_map2_edited.jpg

[Steiner14]

I'm currently writing a complete step-by-step COOP-guide that covers the e-mail-only and the Dropbox system.

I will have finished it roughly in 1 hour.

[Steiner14]

https://dl.dropbox.com/u/96409796/CM%20COOP04.docx

Anything missing, wrong or unclear?

[SlowMotion]

I'm too lazy to play this suggested CoPlay manually.

If some utilities would exist, then I think it could be worth trying.

[Steiner14]

I'm too lazy to play this suggested CoPlay manually.

If some utilities would exist, then I think it could be worth trying.

That's exactly my suspicion. People are demanding HUGE features from BFC, or a software that makes everything automatically, but are not really interested in it. Because demanding is one thing, but testing to find out, what is necessary to get it, is another pair of shoes.

I already see with the slightest problem appearing during a fully automated COOP-MP, e.g. a player not responding or disappearing, they would lose interest immediately and simply disappear, too.

Therefore my suspicion is, that a working manual system that only attracts people really interested in COOP-play will keep the mass, that only tries things out and disappears as fast as it appeares, away, and would probably deliver better results and more finished games, than the best automated system.

[Steiner14]

Here's the latest version (slight corrections and improved explanations):

https://dl.dropbox.com/u/96409796/CM%20COOP05.docx

[SlowMotion]

That's exactly my suspicion. People are demanding HUGE features from BFC, or a software that makes everything automatically, but are not really interested in it. Because demanding is one thing, but testing to find out, what is necessary to get it, is another pair of shoes.

I already see with the slightest problem appearing during a fully automated COOP-MP, e.g. a player not responding or disappearing, they would lose interest immediately and simply disappear, too.

Therefore my suspicion is, that a working manual system that only attracts people really interested in COOP-play will keep the mass, that only tries things out and disappears as fast as it appeares, away, and would probably deliver better results and more finished games, than the best automated system.

I do understand that CoPlay is a feature that would be used by few people and that's why BFC concentrates on features that would improve game play for most people. But still I think that even this "community made CoPlay" could work. For some *really* dedicated players this manual process of yours could work, but for many more some SW assistance would be required to keep them playing even one scenario until end. I didn't do those draft pictures just for this discussion's sake, I'm sort of tempted to try what kind of implementation I could do. So I'm not demanding them from BFC, rather requesting. And if they have their reasons not to do a proper version, maybe some community members can do a hack version. Not as nice as what BFC could do, but maybe useful anyway.

[Steiner14]

I didn't do those draft pictures just for this discussion's sake, I'm sort of tempted to try what kind of implementation I could do.

I you would have spent 5 minutes to read through the draft you would have noticed, that a token-system is necessary if turn times should not multiply with each participating player.

So how can you think you can help to develop anything, if you are not even willing to dive into the topic and learn the associated problems?

The 10 pages are a description for the admins and cover all cases i have recognized so far and are written extremely lenghty for easy understanding. They also contain every single step a admin and commander has to do from writing on the forum up how he should organize the files and emails.

The rules for a normal player could probably be condensed into three short sentences.

[SlowMotion]

Now how do you know whether I have dived into this topic or not?

I did read quite a bit, but commented just some. So that maybe other people could also write something as well. Normally I prefer using Dropbox and H2HH instead of email. So I'd like to do the whole process with as few emails as possible.

I'm positive that writing 3 different versions of one document during one day and expecting other people to read them all is not realistic. Maybe I'll go through this 5th version later, but not now.

[Steiner14]

Now how do you know whether I have dived into this topic or not?

From the useless diagram you posted. And that you wrote, that you were too lazy to read a handful of pages.

Only the usecase for such a software would probably be larger than the draft in words.

I'm positive that writing 3 different versions of one document during one day and expecting other people to read them all is not realistic. Maybe I'll go through this 5th version later, but not now.

There was not a substantial change, only small corrections of typos and hopefully even better explanations.

[SlowMotion]

From the useless diagram you posted. And that you wrote, that you were too lazy to read a handful of pages.

Only the usecase for such a software would probably be larger than the draft in words.

There was not a substantial change, only small corrections of typos and hopefully even better explanations.

The UI draft tried to show how simple this CoPlay can look to a player. One picture instead of several pages of text.

I didn't say I'm too lazy to read your document, but to PLAY CoPlay according to the manual process described in it. A long description of a manual process is nice to have as checklist, but most people won't use it unless it's simple enough. IMO this simplicity can be achieved only with some SW that needs to be written. And things like file naming are implementation details which should be hidden from users. Maybe described in another document.

You can of course test if some people are willing to play a one hour scenario according to your process. How well does it work in practise.

There was not a substantial change, only small corrections of typos and hopefully even better explanations.

But a reader doesn't know how much has changed. He needs to read it all to find out.