Okay, I just have to add something here since this is all about Improving Your Odds. I think we can all agree that the attacker has an ever so slight advantage over the defender in the Long-run, and therefore has no noticable advantage during a particular move or even during a particular game.
So for me I have found that the best way to improve the odds is to maniupulate the system to gain an extra card.
This, combined with sound strategy skills, will result in a statistical advantage over the long run. This does not ensure a win by any means, but it does just what this thread is all about... IT IMPROVES THE ODDS.
It's a bit complicated to explain without a whiteboard, but if you REALLY want to know how I've improved the odds for myself, then keep reading.
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 why I mostly play 6 player std escalating games.
And why I always seem to have 1 more card than you.
