|
Grognot -> RE: Intriguing idea: Hiding the rolls (8/15/2009 5:32:33 AM)
|
Technically, you shouldn't need to "bundle" any rolls at all -- at least, if
(1) we have some compute power (which probably isn't an issue for rolling battles, because we're talking small numbers of rolls and strictly turn-based -- the human beings are by far the gating factor)
(2) we have reasonable faith in cryptographers and their ability to vette hashing functions for statistical weakness
For instance, while MD5 is an imperfect function against determined attack, it still serves as a deterministic, but difficult-to-predict function where even minor alterations in the input can result in substantially different bit sequences. In addition, the correlations between the different bits should be low.
Consider a system in which a single random sequence were created and stored in the initial game file (and only machines rolling dice would need it -- ideally, this would be the host, but this makes naval movement phase very painful due to the interception rolls). To generate any given roll, this could be concatenated with some description of the roll type e.g.
"<seed>-<year>-<month>-<phase>-<location>-<more roll data>"
with qualifiers as need be; for instance, if one wanted to ensure that a guard commitment roll would be the same regardless of what round, one could avoid mentioning the round number, whereas 'combat-attacker-<day>-<round>' might be used for rolling dice to determine casualties. The details would not need to be disclosed, but they would need to be consistent, and sufficient so that different events would actually get different inputs (like a siege battle would need an way to distinguish it from the field battle, since both might happen in the same turn and location).
Then take this monstrous string, feed it into a reasonable digest function (just need one with good entropy characteristics). We only need six different outcomes, so three bits can be chosen (and again, the choice does not need to be disclosed). Three bits results in eight outcomes, not six, so approximately 25% of the time this will require a 'reroll'. Some number of rerolls can be determined by choosing different (non-overlapping) triples; this is reasonable since the correlation between bits should be low. If *all* specified triples land in 'reroll' results, then add a fixed suffix (e.g. "-reroll") to input string and repeat; the probability of getting a die roll instead of a reroll request should rapidly converge to 1.
This sort of thing could
(1) ensure platform independence and reproducibility, provided one is careful about bit ordering -- which might be useful for fixing bugs
(2) tie rolls down to location or other criteria (e.g. ensuring that the order in which one does forage rolls does not matter, by tying it down to something like <nation>-<corp id>-<time specs>),
(3) still ensure a high degree of unpredictability despite being completely deterministic, provided that the secret seed is not trivial to extract and/or that the exact algorithm to compose the strings (which could be arbitrarily ornate; even shifting the last byte to the first position might make a large difference in the rolls) and/or the method of selecting bit triples is hidden (and there are a gazillion ways to choose 42 non-overlapping triplets of bits from a 128-bit sequence, because there's no requirement that the bits in any triple be consecutive). All rolls would be 'predetermined' but the determinations would be basically impossible to without some serious code disassembling... .and why somebody would put that level of effort into determining the roll algorithm for an obscure, rather niche game is beyond me.
It would *not* have any effect on problems such as restarting the naval phase to avoid interception, or anything else that would only be solvable through adding additional file exchanges or the like. It would provide some very interesting properties that would be useful for reproducing bugs, preventing any benefit from reordering a set of die rolls, and the like. And since most of the magic would be in the code and the very first game setup file, the incremental turn files shouldn't need to grow.
Ain't perfect, ain't complete, but it might be worth thinking about.
|
|
|
|
