Conquer Club

p1 and p2 are on a team. p3 and p4 are on a team.

Lets say that in the previous round p2 almost eliminated p3, and p4 almost eliminated p1.

p1 has 4 cards, 1 territory, and that territory is adjacent to p3 who also has just 1 territory, but has 5 cards.

If p1 does not use his set and takes p3 out he obviously gets p3's cards, making 9 cards total.

What if p1 doesnt cash any of his 9 cards, and p2 (who happens to have 4 cards) takes his partner (p1) out. Will he get his partners 9 cards?

If not, is 9 cards the maximum amount that a player can hold at a time... by way of eliminating other players?

Nope, the most cards you can be holding while the game is still playing is 21.

Would you mind explaining how? I can't think of any circumstances where that would happen.

I assume it's when you take someone out in freestyle before they've cashed in their cards... extremely unlikely but nonetheless possible

6 player game, it can be sequential or freestyle. For this example I will use freestyle.

Player A has 4 cards, and eliminates Player B who had 5 cards. Player A now has 9 cards.
Player C logs on while Player A is deciding how to use his cash-ins. Player C starts his turns with 4 cards, doesn't cash in, and eliminates Player A. Player C now has 13 cards.
Player D logs on while Player C is deciding how to use his cash-ins. Player D starts his turns with 4 cards, doesn't cash in, and eliminates Player C. Player D now has 17 cards.
Player E logs on while Player D is deciding how to use his cash-ins. Player E starts his turns with 4 cards, doesn't cash in, and eliminates Player D. Player E now has 21 cards.
Now if Player F were to log on and eliminate Player E, he would have 25 cards but the game would be over.

So, the most possible cards you can have while still playing is 21.

I suppose in the sequential example it would require every player to eliminate their opponent and then run out of time before cashing their cards. I suppose this is possible, if there are any players out there who actually play like this I'd like to be in a game with them though!

When you take someone out and you have 5 or more cards after you take the person out, you have to turn in.

atr1989 wrote:When you take someone out and you have 5 or more cards after you take the person out, you have to turn in.

Yep, nobody is denying that.

AK_iceman wrote:6 player game, it can be sequential or freestyle. For this example I will use freestyle.

Player A has 4 cards, and eliminates Player B who had 5 cards. Player A now has 9 cards.
Player C logs on while Player A is deciding how to use his cash-ins. Player C starts his turns with 4 cards, doesn't cash in, and eliminates Player A. Player C now has 13 cards.
Player D logs on while Player C is deciding how to use his cash-ins. Player D starts his turns with 4 cards, doesn't cash in, and eliminates Player C. Player D now has 17 cards.
Player E logs on while Player D is deciding how to use his cash-ins. Player E starts his turns with 4 cards, doesn't cash in, and eliminates Player D. Player E now has 21 cards.
Now if Player F were to log on and eliminate Player E, he would have 25 cards but the game would be over.

So, the most possible cards you can have while still playing is 21.

ohh!, got it... now the question is: has this ever happened?

yosevuk wrote:ohh!, got it... now the question is: has this ever happened?

I'd be astonished if it has...

Oh, my bad I misread the post

Genghis Khan CA wrote:

yosevuk wrote:ohh!, got it... now the question is: has this ever happened?

I'd be astonished if it has...

well if people can loose say 29 or 32 to say 6 armies on a single country like me or others who have lost over 50 men attacking say 9 or 12 like ive heard from others, than yes its possible.

I just lost about 15 men in one country attacking about 6 single men in other countrys....which to me seems like I would be more likely to be hit by lighting about 4 times.


so yes it is, and get out your rain coat.

xtratabasco wrote:well if people can loose say 29 or 32 to say 6 armies on a single country like me or others who have lost over 50 men attacking say 9 or 12 like ive heard from others, than yes its possible.

I just lost about 15 men in one country attacking about 6 single men in other countrys....which to me seems like I would be more likely to be hit by lighting about 4 times.


so yes it is, and get out your rain coat.

Why do dice rolls have to infiltrate every thread, no matter how irrelevant?

No one disputes that it is possible in theory, however given it requires 4 players in a row to take out a player whilst he is deciding how to use his cash ins, and for each of those players to have 4 cards, it would be extremely unlikely in practice.

This isn't just a matter of lucky or unlucky dice rolls, it requires a perfect set up on the board and players who stop for a significant period before cashing their cards, oblivious of a tactic which they themselves had just used to eliminate an opponent and get cards.

Genghis Khan CA wrote:

xtratabasco wrote:well if people can loose say 29 or 32 to say 6 armies on a single country like me or others who have lost over 50 men attacking say 9 or 12 like ive heard from others, than yes its possible.

I just lost about 15 men in one country attacking about 6 single men in other countrys....which to me seems like I would be more likely to be hit by lighting about 4 times.


so yes it is, and get out your rain coat.

This isn't just a matter of lucky or unlucky dice rolls, quote]



Well these rolls dont have anything to do with luck or unluck because they are generated by a computer, the problem is that the rolls they generate are indeed illogical, impossibly repeated over and over and over agian and just plain insane......

Ive been playing this game on a board and online for 25+years and have never ever lost all of my 16 men to 6 individual pcs.


but you have a point these are apples and oranges.

AK_iceman wrote:6 player game, it can be sequential or freestyle. For this example I will use freestyle.

Player A has 4 cards, and eliminates Player B who had 5 cards. Player A now has 9 cards.
Player C logs on while Player A is deciding how to use his cash-ins. Player C starts his turns with 4 cards, doesn't cash in, and eliminates Player A. Player C now has 13 cards.
Player D logs on while Player C is deciding how to use his cash-ins. Player D starts his turns with 4 cards, doesn't cash in, and eliminates Player C. Player D now has 17 cards.
Player E logs on while Player D is deciding how to use his cash-ins. Player E starts his turns with 4 cards, doesn't cash in, and eliminates Player D. Player E now has 21 cards.
Now if Player F were to log on and eliminate Player E, he would have 25 cards but the game would be over.

So, the most possible cards you can have while still playing is 21.

Actually in a Battle Royal, it can be a way more, depends which map would be played.

yosevuk wrote:ohh!, got it... now the question is: has this ever happened?

Yep! The reason AK knows about it is because it was discussed and tested. I don't know the game number but it does work.

And yes, in theory you could do it in a battle royale (good luck getting everyone to coordinate). However the math on the max number of cards including battle royales woud get quite complicated.

Keep in mind that for each player to start the round with 4 cards (and one player with 5 cards) they would have needed to attack throughout the game, and therefore some players would be eliminated. It would of course be maximized on World 2.0, but the exact number I can't really figure out.

I think the ideal strategy would be eliminating the players on countries that have many borders (ie china) so then each neighboring player could attack that same country without eliminating more people. Ugh, the math is a bit tedious but this will probably bother me until I figure it out.

Special note to all those that like to exploit the card system...
Do not try this while trying to manipulate an extra card... it will result in the loss of the all your cards.

(and for the record, this is NOT cheating... it is exploiting a weakness in the system... some choose to manipulate double-turns in freestyle games, some choose to manipulate the score by playing team games with low ranked players, and manipulating the system to gain an extra card is no worse).

For those who don't already know about this, I'll be happy to walk through it again, but it is a bit complicated to explain without a whiteboard.

First off, it doesn't work with flat rate, and it doesn't work with team games. Here 's why... it is all about the Cyclomatic Code Complexity within this site. The simple part to explain is that on this site the code complexity is defined by control flow, and obviously there are different ways of measuring complexity (e.g. data complexity, module complexity, algorithmic complexity, call-to, call-by, etc.), and although these other methods are effective in the right context, it seems to be generally accepted that control flow is one of the most useful measurements of complexity, and high complexity scores have been shown to be a strong indicator of low reliability and frequent errors. That's simple enough, but it's what we do with it that's so cool... This measure provides a single ordinal number that can be compared to the complexity of other games. Because of static software metrics intended to be independent of language and language format, Cyclomatic Code Complexity becomes a measure of the number of linearly-independent paths through a program module and is calculated by counting the number of decision points found in the code. Stay with me people... I use a Lutz Roeders Reflector which basically allows the user to point his Reflector tool at any Common Langauge Runtime (CLR) assembly, and it will then de-compile this creating an entirely reflected treeview with all the objects from the source assembly shown, with code. Yes with code. Great stuff. Basically you can use this tool to see how any valid CLR (assuming it has not been obfuscated) assembly works. Anyway the up shot of it, is that we get a boolean to say that the current file is valid or not, that is all we care about at the moment. So if the file requested is not a valid CLR type an error message is shown, and nothing else is done. However, if the input file is a valid CLR file, it is then checked to see if the file is a "System" assembly, and if it is... eureka! I get an extra card. Ok so thats pretty much all there is to it.

A while back I started to modifiy this to work with flat rate, but I don't think it would really be worth all the effort. So if you really want this for flat rate, let me explain how far I got and you could work on finishing it. You would have to revisit the treeview with ONLY valid namespaces and ONLY valid classes created. We would also have to find the NameSpaces object which contains the list of strings (for namspaces) and for each string of ucClass objects (for the classes). The list of ucClass objects are created by this and are then ready and waiting to be placed on a suitable code. But as yet we dont know what classes the user needs, it could be all of them, or it could be 1 of them or even none of them. It depends on what the user selects from the treeview on the mainform (frmMain.cs). And that's where I got stuck. So I looked and I looked for an answer. The only thing simliar at all, was GDI+ and in order to do something like this, a destination target needs to be created at the full string size, and then the viewable (onscreen) fragments are printed to individual page framements and saved into the destination image at the correct x/y co-ordinates. In order to do this the application has to programatically perform scrolling to get the next page fragment code to merge with the destination code. I managed to get this to work, but it was a complete nightmare, and there were definetly bugs everywhere, which resulted in losing more cards that I gained! So if there is anyone reading this that is totally rad and knarly at GDI+, and knows how to save the entire contents of a scrollable control to an exisiting code, please feel free to let me know. As for the above code, it is code that I am kind of 1/2 proud of, but would rather wasn't there. Do you know what I mean? After all, sometimes you just get completley stuck with trying to patch all these code fragments together, to form the final destination code.

So for these reasons, it only works properly with 6 player std escalating games.

And now you know why I only play 6 player std escalating games.

And why I always seem to have 1 more card than you.

Robinette wrote:For those who don't already know about this, I'll be happy to walk through it again, but it is a bit complicated to explain without a whiteboard.

First off, it doesn't work with flat rate, and it doesn't work with team games. Here 's why... it is all about the Cyclomatic Code Complexity within this site. The simple part to explain is that on this site the code complexity is defined by control flow, and obviously there are different ways of measuring complexity (e.g. data complexity, module complexity, algorithmic complexity, call-to, call-by, etc.), and although these other methods are effective in the right context, it seems to be generally accepted that control flow is one of the most useful measurements of complexity, and high complexity scores have been shown to be a strong indicator of low reliability and frequent errors. That's simple enough, but it's what we do with it that's so cool... This measure provides a single ordinal number that can be compared to the complexity of other games. Because of static software metrics intended to be independent of language and language format, Cyclomatic Code Complexity becomes a measure of the number of linearly-independent paths through a program module and is calculated by counting the number of decision points found in the code. Stay with me people... I use a Lutz Roeders Reflector which basically allows the user to point his Reflector tool at any Common Langauge Runtime (CLR) assembly, and it will then de-compile this creating an entirely reflected treeview with all the objects from the source assembly shown, with code. Yes with code. Great stuff. Basically you can use this tool to see how any valid CLR (assuming it has not been obfuscated) assembly works. Anyway the up shot of it, is that we get a boolean to say that the current file is valid or not, that is all we care about at the moment. So if the file requested is not a valid CLR type an error message is shown, and nothing else is done. However, if the input file is a valid CLR file, it is then checked to see if the file is a "System" assembly, and if it is... eureka! I get an extra card. Ok so thats pretty much all there is to it.

A while back I started to modifiy this to work with flat rate, but I don't think it would really be worth all the effort. So if you really want this for flat rate, let me explain how far I got and you could work on finishing it. You would have to revisit the treeview with ONLY valid namespaces and ONLY valid classes created. We would also have to find the NameSpaces object which contains the list of strings (for namspaces) and for each string of ucClass objects (for the classes). The list of ucClass objects are created by this and are then ready and waiting to be placed on a suitable code. But as yet we dont know what classes the user needs, it could be all of them, or it could be 1 of them or even none of them. It depends on what the user selects from the treeview on the mainform (frmMain.cs). And that's where I got stuck. So I looked and I looked for an answer. The only thing simliar at all, was GDI+ and in order to do something like this, a destination target needs to be created at the full string size, and then the viewable (onscreen) fragments are printed to individual page framements and saved into the destination image at the correct x/y co-ordinates. In order to do this the application has to programatically perform scrolling to get the next page fragment code to merge with the destination code. I managed to get this to work, but it was a complete nightmare, and there were definetly bugs everywhere, which resulted in losing more cards that I gained! So if there is anyone reading this that is totally rad and knarly at GDI+, and knows how to save the entire contents of a scrollable control to an exisiting code, please feel free to let me know. As for the above code, it is code that I am kind of 1/2 proud of, but would rather wasn't there. Do you know what I mean? After all, sometimes you just get completley stuck with trying to patch all these code fragments together, to form the final destination code.

I've got to hand it to you Robinette, you get a lot of reuse out of this card trick.

tahitiwahini wrote:

Robinette wrote:For those who don't already know about this, I'll be happy to walk through it again, but it is a bit complicated to explain without a whiteboard.

First off, it doesn't work with flat rate, and it doesn't work with team games. Here 's why... it is all about the Cyclomatic Code Complexity within this site. The simple part to explain is that on this site the code complexity is defined by control flow, and obviously there are different ways of measuring complexity (e.g. data complexity, module complexity, algorithmic complexity, call-to, call-by, etc.), and although these other methods are effective in the right context, it seems to be generally accepted that control flow is one of the most useful measurements of complexity, and high complexity scores have been shown to be a strong indicator of low reliability and frequent errors. That's simple enough, but it's what we do with it that's so cool... This measure provides a single ordinal number that can be compared to the complexity of other games. Because of static software metrics intended to be independent of language and language format, Cyclomatic Code Complexity becomes a measure of the number of linearly-independent paths through a program module and is calculated by counting the number of decision points found in the code. Stay with me people... I use a Lutz Roeders Reflector which basically allows the user to point his Reflector tool at any Common Langauge Runtime (CLR) assembly, and it will then de-compile this creating an entirely reflected treeview with all the objects from the source assembly shown, with code. Yes with code. Great stuff. Basically you can use this tool to see how any valid CLR (assuming it has not been obfuscated) assembly works. Anyway the up shot of it, is that we get a boolean to say that the current file is valid or not, that is all we care about at the moment. So if the file requested is not a valid CLR type an error message is shown, and nothing else is done. However, if the input file is a valid CLR file, it is then checked to see if the file is a "System" assembly, and if it is... eureka! I get an extra card. Ok so thats pretty much all there is to it.

A while back I started to modifiy this to work with flat rate, but I don't think it would really be worth all the effort. So if you really want this for flat rate, let me explain how far I got and you could work on finishing it. You would have to revisit the treeview with ONLY valid namespaces and ONLY valid classes created. We would also have to find the NameSpaces object which contains the list of strings (for namspaces) and for each string of ucClass objects (for the classes). The list of ucClass objects are created by this and are then ready and waiting to be placed on a suitable code. But as yet we dont know what classes the user needs, it could be all of them, or it could be 1 of them or even none of them. It depends on what the user selects from the treeview on the mainform (frmMain.cs). And that's where I got stuck. So I looked and I looked for an answer. The only thing simliar at all, was GDI+ and in order to do something like this, a destination target needs to be created at the full string size, and then the viewable (onscreen) fragments are printed to individual page framements and saved into the destination image at the correct x/y co-ordinates. In order to do this the application has to programatically perform scrolling to get the next page fragment code to merge with the destination code. I managed to get this to work, but it was a complete nightmare, and there were definetly bugs everywhere, which resulted in losing more cards that I gained! So if there is anyone reading this that is totally rad and knarly at GDI+, and knows how to save the entire contents of a scrollable control to an exisiting code, please feel free to let me know. As for the above code, it is code that I am kind of 1/2 proud of, but would rather wasn't there. Do you know what I mean? After all, sometimes you just get completley stuck with trying to patch all these code fragments together, to form the final destination code.

I've got to hand it to you Robinette, you get a lot of reuse out of this card trick.

Hey... it was a lot of work getting that to work... seems only fair to share it with everybody...
and yet I suppose only the most tenacious will actually read and understand it, let alone bother to put it to use.
(too bad a greasemonkey script can't work with this, eh?)

Robinette wrote:Hey... it was a lot of work getting that to work... seems only fair to share it with everybody...
and yet I suppose only the most tenacious will actually read and understand it, let alone bother to put it to use.
(too bad a greasemonkey script can't work with this, eh?)

Well, now that you mention it, I've heard rumors of something even more powerful than greasemonkey. I'm not promising anything, but it might just be possible...