ORIGINAL: Marshall Ellis
Look to have something like this in 1.05-1.06
DancingBear's fix seems logical, but there is a big hole in it. We've discussed this before, and should again as you are getting ready to implement any changes.
The problem is that it doesn't matter to the person reloading the file whether the rolls are in order or not. He can just choose a different order for the battles, and see if the results are better. It's a step in the right direction, but not a complete fix. At least, with predetermined rolls, he can't just reload; he has to actually reload and make battles, to see what happens.
In addition to this, two other things need to occur. The first is that a trusted authority (see below) must be contacted once a person starts up the combat phase (or, ends the movement phase). Once this happens, some kind of token must change hands that allows the person to continue into the battle. Unfortunately, the only truly secure way to do this is to involve another person, since any attempt to make the trusted authority be present on the cheater's system means that he can overcome it.
The second is that the person can only execute the combat phase once when he sends out the token. Now, because of the complexity of this (the player can choose to fight battles in any order), this effectively means that either the token must be updated each time a battle event occurs, or else a new token must be sent. I think the latter is better, but see below.
Finally, the random number cannot be pregenerated just "100 in advance". The person could overcome the token method by fighting one battle at a time over and over, and intercept all the tokens except the one he wants to use. I think instead, a combination of die rolling processes must be invoked. First, each area on the map should have a short list of predetermined die rolls attached to that location. So, now, changing the order does no good. Instead, he would have to abandon a battle if the rolls were determined to be bad for our friend the cheater. But, he can't do that if he's already passed a token.
Is this secure? No, nothing is. But, it's easily coded (except adding the pool of random rolls to each area on the map, possibly), and should be able to be added in stages. This would allow us to test out each piece of the security puzzle by itself, and make sure it doesn't damage other things inadvertently.
OK, I promised a discussion on tokens above. A token is simply a construct (file or database key in this case). A copy of the token is kept by the phasing player's copy of the game. This construct is created uniquely, in a similar fashion to how the PBM files are names. But, since the token is a lot more specific in its usage, that means that the uniqueness has to come down to something akin to the date and the system clock. This has the drawback of allowing people to change their time stamp as a way of hacking the code, but there are very few people who could pull something like that off ...
IF the token is encrypted. Even public-domain 40-bit encryption would be enough for all but the most determined hackers. And, testing out the theories would require many tokens, which means many months of playing. If they're THAT desperate, I'll just let them win. But, for the first pass, encryption should be left out for debugging purposes. It can be coded, but not turned on (should be coded to make sure it doesn't break something else).
Anyhow, a token can be sent either for the copy of the game, or it can be sent for each battle element (start of battle, chit pull #1, chit pull #1, etc). I think something between those two is more appropriate: A new token at the start of each battle, when the player first rolls a die.
Now, your next question should be "Hey, doesn't this mean even MORE emails?" Yes, it does. BUT, they can be one-way emails. Once the token has been sent, the battle can progress normally. The token does not need to be checked until AFTER the battle is all over (or, even, until the phasing players turn is completed). At that point, it is loaded as a separate PBM file into the main game. But, if the player cheated, his game's token will no longer match the one on the server.
There are still ways to cheat with this kind of setup, but it would be an order of magnitude harder. Plus, each piece of the picture adds a small amount to the security.
At LAST! The greatest campaign board game of all time is finally available for the PC. Can my old heart stand the strain?
prov79:fieldcombat:attacker:round3:outflankroll'). Take the MD5 hash of the combined string (or different hash if the PRNG requires more bits), seed the PRNG with it, roll. It's somewhat robust unless the PRNG is prone to patterns early in a sequence. Nice thing is, strings which are similar to each other aren't supposed to generate similar MD5 hashes, so you can do this with just the per-game secret and the built-in one. Bad thing is, it might be slightly computationally ugly, but it's not -that- bad.
