Jump to content

Steiner14

Members
  • Posts

    1,410
  • Joined

  • Last visited

Posts posted by Steiner14

  1. 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.

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

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

    :D

    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.

  3. 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!

  4. 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

  5. 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?

  6. I cannot understand the attitude here on the forums that if something negative (and easily fixable, that would in no way jeopardize the tactical part of the game, but enhance it further!) is pointed out by the reviewers, it's shot down immediately by claiming the said reviewer is incompetent when it comes to tactical "serious" wargames. Seriously

    The review of a car should focus on it's color and if the door-handles are painted? Are you a girl? I call this BS. A car review has to deal with the motor, it's construction and durability, with the chassis's durability, the seat ergonomics but not the usual ADVERTISEMENT GARBAGE that is used to fill the pages!

    If a reviewer of CMFI is complaining about a sound option and similar flyspecks and not analyzing or describing the best infantry model in the whole wide world, then this is almost a definition of stupidity par excellance to me.

  7. Yeah, we keep meaning to get around to this. At least I'm pretty sure we can soon add a quick and dirty toggle in the prefs file at the very least.

    Steve,

    what do you mean? To switch background noise off only during command phase or in general?

    If it is not too much of a hassle, a volume slider for the background noise would be fantastic. Sometimes i'd really like to listen to the action on my studio monitors, but i can't stand the very loud "background" sound. It reduces the impact unnecessarily when a cannon is fired at real high volume. :D

  8. 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.

  9. However he is reviewing it compared to AAA titles with unlimited resources really.

    And sh.t infantry and running around that is called "tactical combat" but has nothing to do with real world tactics...

    How stupid must someone be not to recognize the important aspects?

    When he stated "Battlefront is really behind the time" because of PBEM and no central server after he moaned about the campaigns i decided not to watch it any longer. I'm not willing to spoil a scenario because of a "reviewer" who is focusing at flyspecks to set the tone instead to EDUCATE teh reader/viewer and set the focus of the viewer / reader correctly that this reviewed game has hands down the world's best and finest infantry model and is the best software for tactical warfare ever and the rest compared to it is childish kiddy gaming. A sim VS games. A giant VS a show of absurdities and insults of intelligence.

    But since every review has to be the same, begin and end with the same topics, every idiot noit capable to make a decent review is following this path because everyone does so... This IMO completely wrong approach to focus on flyspecks instead of delivering the IMPORTANT INFORMATION to the readers is the reason, why games for the braindead with their impressive SHOW without any useful content have such a huge advantage over intelligent, interesting and good software if it is not as polished as the garbage.

  10. I would love to see Co-op. Imagine playing a huge PBEM battle with say, 8 players.

    It's already not so easy to find adequate PBEM-players, that fit from skill level, turn rate and reliability.

    Now imagine the lenght of turns if a multiple of 2 would be involved.

    Also imagine how few games would become finished and how many would suffer from disappearing players, once one side gets problems. Imagine the "fun" after an incompetent player lost 50% of his tanks and disappears, to take over the game and play a hopeless game, caused by someone else, to the end.

    And them imagine, after some nice experiences of the human kind, how many players would be left playing CO-OP after one year.

  11. I'm very impressed. The game is more responsive, graphics are faster AND look better, the hotkey-menu is excellent and the action feels more realistic, fluid and logical.

    Adjustable waypoints are a dream. Action groups. Yeah! Armor cover arc. Heavenly.

    My impression is, that even the pathing of vehicles has been improved. At least i haven't noticed any silly minute long turning sessions.

    I also have the slight impression, that units in big houses show a more realistical behaviour in the case of incoming fire (better self preservation?).

    IMO the whole action feels more organic.

    And playing the Italians is an interesting thing! So much to learn.

    Amazing how the different nations feel different in a natural way. Great how the different doctrine of different nations can really be felt by the player and also results in slightly different tactics.

    I also like the new order menu.

    And what difference the shaders make, when watching the pixelsoldiers.

    But there are also a few things i don't like. What i'm missing badly - and the adjustable waypoints remind me all the time about it now - are moving-paths being clickable: clicking a path IMO should select the unit like in CMx1.

    In conjunction with this i think it would be even better if no unit is selected, and if "Show all paths" is activated, that all paths are shown (like in CMx1).

    I'm also still sceptical, if the 60mm mortars are modelled correctly. In the game they still are extremely effective against entrenched units. Every ATG still seems to be toast within 1 minute. I don't know what the reason is, why they are like Wunderwaffen. Maybe the protection of entrenched units against mortar fire is to weak? Or is the spreading pattern still too less? Or a combination of both?

    Currently the 60mms are a 100% guarantee to get rid of every entrenched ATG within one minute.

    I also have the impression, that entrenched ATGs (but also other units) still can be IDd to easy. In combination with the 60mm über-mortars defenses still seem to easy to crack.

    Regarding the learning effect: i'm still missing badly a unit data window. Wouldn't it be fantastic not only to have the old CMx1 unit data back, but also a second page with a short history of the unit? I know, Steve has stated that they don't have time to fill the content, but if a unit data window was available, i'm sure the community would fill it in no time with content.

    The graphics engine also seems to be much faster and to scale better with an increasing size of maps.

    A very, very nice product. I bet it will become wargame of the year 2012.

  12. Yes, and that last bit you said is the key to a great scenario designer. He's the guy that figures out how to use the array of Victory Conditions to best direct the player's motivations, for example. Or how to design maps to optimize a certain flavor of battle yet not make it look deliberate. If all you have is a hammer and a sledgehammer, it makes lightly attaching something with screws a very difficult proposition.

    Can this be interpreted that you will not artificially restrict the designer's tools, to prevent bad designers making bad scenarios, but to give the designers mighty tools and let them decide how useful and intelligent they use them?

    E.g. i'm thinking of reinforcements that can be triggered by various variables. Although potentially awful in the hands of bad designers, but in the hand of good designers, the player probably wouldn't even notice it.

×
×
  • Create New...