Help with external die roller

General Discussion
1

Hello,

I used PBE games roller since many years, but it closed on August 15.

Then, I’m looking for another external die roller, but, till now, I found nothing.

Someone , please,can help?

Thanks a lot!

Panther_2010

2

I’ll go ahead and ask the obvious. What’s the advantage of an external die roller?

3

hamete virtual dice server

4
5

No such thing as a stupid question - only stupid answers :smiley:

The short answer: None (but see below for more)

When PBEM’ing, users should record their session using the log facility in Vassal. This will faithfully record the die-rolls, and others may check that no mistake (whether maliciously or through incompetence - remember Hanlon’s razor) were made.

Of course, a user may tamper with a module to ensure better die rolls (quite easy in fact), and thus cheat. Clearly, that’s not a good thing.

Another way to make it harder to cheat by changing a module, would be to write a check-sum of the module to the log file. Then, the recipient could check that checksum against the checksum of the recipients module, thus checking that (whew a lot of checks) the modules are likely the same. Incidentally, this would also solve another problem where two or more players are using different versions of the same module.

Of course, one can tamper with the log file (again, not too hard to do) to change the checksum or even change die rolls.

One way to address that - though not tamper-proof - is to encode more rules into the modules - such as automatic odds calculations and combat resolutions. A creative player may still tamper with the log, but it will become somewhat harder to do.

These considerations are likely why tournaments sometimes requires the use of third-party die-rollers.

With a third-party die-roller, and one that somehow records the die rolls in a secure way (e.g., by posting read-only logs, or mailing them to multiple addresses), it will be harder to cheat on the die-rolls. Quite often, though, these third-party die-rollers need authentication to use (which actually makes sense).

With a third-party die-roller, the ideal situation would be if there’s a public API that could be used from within Vassal. Such an integration would to a GET request on a server, which would then reply with a die-roll. At the same time, the server would record the die-roll with some unique ID (timestamp, module, player, side, etc.) in a read-only log, so that other players may verify it when replaying the log (each roll being annotated by that unique ID). In fact, when replaying the log, the Vassal interface could ask the server to verify all die-rolls against the server’s log. The connection to the server would still need to be authorised.

In fact, Vassal does have an interface like this - it is VASSAL.build.module.InternetDiceButton, which uses the class VASSAL.build.module.dice.DieManager, which in turn relies on implementation of the interface VASSAL.build.module.dice.DieServer, of which there are two: VASSAL.build.module.dice.BonesDiceServer (using http://dice.nomic.net/ - by @uckelman ) and VASSAL.build.module.dice.ShadowDiceDieServer (using http://www.gamerz.net/shadowdice). However, that interface is no longer documented, and the servers seem not to be entire in operation.

I think the main problem with the above implementation is that it isn’t a dynamic drop-in replacement for normal die rollers. That is, a user should be able to say - via some preference - “I want to use a third-party die roller, and here are my credentials to do so”. Instead, the module has to use a specific component.

One way to do that, would be if Vassal hosted such a server on https://vassalengine.org, or provided a way to run such a server. Then, users would authorise against the forum credentials, and the server would hold a log of die-rolls for some limited time. The code could simply reuse some of the code already in Vassal - to make things easier :smiley:

BTW, note that a third-party server doesn’t really need to know anything about die rolls. It just needs a way or producing a whole random number between 0 and some known maximum. The module and the Vassal code should then take care to make that into a die roll of the appropriate kind. Thus, a server could have a very simple API:

GET /api/randomnumber → {‘number’: 1234567, ‘maximum’: 9999999, ‘hash’: `0123456789abcdef’ }
PUT /api/verify with {‘number’: 123456789, ‘hash’: ‘0123456789abcdef’ } → OK, BAD, NOT FOUND

Yours,
Christian

6

Many thanks to all for the reply to my inquiry.

I use external die rollers only in rated games, and this was a request of my opponents.

Yes, a Vassal server for die rolls would be great!

Panther_2010
Emoji

Someone replied to your post.

| cholmcc
August 17 |

  • | - |

clanmacrae:

I’ll go ahead and ask the obvious.

No such thing as a stupid question - only stupid answers :smiley:

clanmacrae:

What’s the advantage of an external die roller?

The short answer: None (but see below for more)

When PBEM’ing, users should record their session using the log facility in Vassal. This will faithfully record the die-rolls, and others may check that no mistake (whether maliciously or through incompetence - remember Hanlon’s razor) were made.

Of course, a user may tamper with a module to ensure better die rolls (quite easy in fact), and thus cheat. Clearly, that’s not a good thing.

Another way to make it harder to cheat by changing a module, would be to write a check-sum of the module to the log file. Then, the recipient could check that checksum against the checksum of the recipients module, thus checking that (whew a lot of checks) the modules are likely the same. Incidentally, this would also solve another problem where two or more players are using different versions of the same module.

Of course, one can tamper with the log file (again, not too hard to do) to change the checksum or even change die rolls.

One way to address that - though not tamper-proof - is to encode more rules into the modules - such as automatic odds calculations and combat resolutions. A creative player may still tamper with the log, but it will become somewhat harder to do.

These considerations are likely why tournaments sometimes requires the use of third-party die-rollers.

With a third-party die-roller, and one that somehow records the die rolls in a secure way (e.g., by posting read-only logs, or mailing them to multiple addresses), it will be harder to cheat on the die-rolls. Quite often, though, these third-party die-rollers need authentication to use (which actually makes sense).

With a third-party die-roller, the ideal situation would be if there’s a public API that could be used from within Vassal. Such an integration would to a GET request on a server, which would then reply with a die-roll. At the same time, the server would record the die-roll with some unique ID (timestamp, module, player, side, etc.) in a read-only log, so that other players may verify it when replaying the log (each roll being annotated by that unique ID). In fact, when replaying the log, the Vassal interface could ask the server to verify all die-rolls against the server’s log. The connection to the server would still need to be authorised.

In fact, Vassal does have an interface like this - it is VASSAL.build.module.InternetDiceButton, which uses the class VASSAL.build.module.dice.DieManager, which in turn relies on implementation of the interface VASSAL.build.module.dice.DieServer, of which there are two: VASSAL.build.module.dice.BonesDiceServer (using http://dice.nomic.net/ - by @uckelman ) and VASSAL.build.module.dice.ShadowDiceDieServer (using http://www.gamerz.net/shadowdice). However, that interface is no longer documented, and the servers seem not to be entire in operation.

I think the main problem with the above implementation is that it isn’t a dynamic drop-in replacement for normal die rollers. That is, a user should be able to say - via some preference - “I want to use a third-party die roller, and here are my credentials to do so”. Instead, the module has to use a specific component.

One way to do that, would be if Vassal hosted such a server on https://vassalengine.org, or provided a way to run such a server. Then, users would authorise against the forum credentials, and the server would hold a log of die-rolls for some limited time. The code could simply reuse some of the code already in Vassal - to make things easier :smiley:

BTW, note that a third-party server doesn’t really need to know anything about die rolls. It just needs a way or producing a whole random number between 0 and some known maximum. The module and the Vassal code should then take care to make that into a die roll of the appropriate kind. Thus, a server could have a very simple API:

GET /api/randomnumber → {‘number’: 1234567, ‘maximum’: 9999999, ‘hash’: `0123456789abcdef’ }
PUT /api/verify with {‘number’: 123456789, ‘hash’: ‘0123456789abcdef’ } → OK, BAD, NOT FOUND

Yours,
Christian

7

By far the most common objection I know of in communities where 3rd party die rolling is commonplace have nothing to do with potential for tampering with logfiles or modules, but rather just not producing a logfile until a player is satisfied with dice outcomes.

That is, a player just abandons recording of a logfile if one or more crucial rolls don’t go their way, and just rinse and repeat until they get what they want. There’s no way for an opponent on the other end to know.

8

Actually, thinking about the problem a little bit more, here’s a potential solution that doesn’t require a third-party server.

  • When a user starts a new log file, generate a new state (seed) of the random number generator (java.security.SecureRandom) by calling generateSeed
  • Write those bytes to the log file (.vlog)
  • Set the random number generator state to that see (setSeed).

When a user play back an log file

  • When it sees the line that contains the seed, it sets the random number generator seed to that seed (setSeed).
  • Every time a random number is seen in the log file, the play-back requests a number random number from the random number generator, and checks if the read and the generated random numbers match. If they don’t then something is a-foot.

The point is, that given a seed, a Pseudorandom number generator will produce a specific sequence of numbers. Thus, if two random number generators (one when writing the log file, one when playing-back the log file) are initialised with the same seed, then they will produce the same sequence of pseudo-random numbers.

Of course one can tamper with the seed written in the log file, but it is very hard to reverse-engineer a seed from a desired sequence of random numbers - especially with a strong, cryptographic random number generator as the one used in Vassal.

Note that the above approach could be used at all times, since it does not depend on third-party services, or any other knowledge than the initial seed.

Incidentally, it would actually be nice if one could initialise the seed of the Vassal random number generator. That would allow one to start - say - a tutorial from the same seed every time, and thus hopefully have a known sequence of die-rolls.

There’s one technical caveat to the above: Random numbers are used not only for die rolls in Vassal. For example, one can rotate a piece by a random angle, which may or may not be registered as a newly drawn random number. Also, VASSAL.build.GameModule#getRNG allows unfeathered access to the random number generator. This object should probably be encapsulated in some other object that records all generated random numbers in the current log.

Yours,
Christian

9

@panther_2010 - it seems like you are replying to forum posts via email. If that’s the case, then please edit your reply email so that it doesn’t contain the full message you are replying to.

Also consider that Top-posting is generally consider bad form - at least by any one older than 30 :smile: For example

Because it messes up the order in which people normally read text.
Why is top-posting such a bad thing?
Top-posting.
What is the most annoying thing in e-mail?

Below is the message (in part) this is a reply to:

Yours,
Christian

10

Personally I would not have patience to do all that work.

One way to get around that, would be to insist that the opponent or third party records the log.

  • Player in turn, say A, connects to server.
  • Player B, or some third party arbitrator connects to server
  • Player B or arbitrator starts log recording
  • Player A does its moves.

The one recording doesn’t need to monitor the moves. That’s done by the recording.

Of course, if the players are playing live, possibly via the net, then there’s no problem.

In all cases, it requires an active internet connection, which is less of a problem these days.

Yours,

Christian

11

Neither would I, but in the game communities I have in mind this possibility has historically paralyzed people to the degree that they erected entire 3rd party websites like ACTS to handle random game elements. It’s frequently the case that individual plays in a long-running multiplayer game are very short and might involve only one or two crucial die rolls at a time–so it would be the work of mere moments to re-record a logfile a couple or several times to get the outcome you want (favorable roll, avoid losing your best card to a random giveaway, etc).

The suggested 3rd party arbiter for recording of logs is technically a solution, but in practice a complete non-starter in multiplayer async games usually involving people spanning the globe and taking many months to complete even in the most optimal circumstances.

12

This will cease to be an issue with with V4 so long as one has internet connection, as the public server will record rolls. If you want verifiable rolls, you’ll be able to get them without using anything third-party.

2 Likes
13

Hopte to see version 4 soon. I remember that someone was speaking about this new version back in 2010 when I discovered Vassal…

Emoji

Someone replied to your post.

| uckelman
August 18 |

  • | - |

This will cease to be an issue with with V4 so long as one has internet connection, as the public server will record rolls. If you want verifiable rolls, you’ll be able to get them without using anything third-party.

14

First off, if I suspected an opponent was employing such tactics to cheat, I would resign from such a game. It is simply no fun playing against a cheater.

It seems to me, that what one would like to accomplish is, that after an player as played back a log file (or loaded a save file), that the new player must continue immediately and without interruption, so that the die rolls (and other random numbers) cannot be tampered with.

What that means, is in some sense that the second player (and later) must continue to use the same random number sequence (i.e., the same random number generator seed), or some sequence which comes from a predictable seed. Then, the first player can check, given the seed that was used originally, that the sequence of random numbers used by the second player, is the same or predictable as the one used by the first player.

In practise, this could look like

  1. Player A starts a game
  2. A starts a log file - say A1.vlog
    • This will put the currently used seed - say sA1 - into the log file
  3. A generates random numbers
    • Each random number is written to the log file, irrespective of whether it corresponds to a die roll or some other random thing. In this way, the sequence of random numbers is documented in the log file.
  4. A ends the log file
  5. A sends the log file to player B

Now it is player Bs turn

  1. Player B opens the log file A1.vlog
    • Vassal will, as part of reading the log file, see the seed - sA1 - written down in step 2 above.
    • The Random number generator is seeded with that seed sA1.
  2. B starts to step through the log file A1.vlog
    • When ever A made a random number, it is read in from the log file. Vassal can now check, that given the above seed - sA1, that the random number read in is indeed the next random number in the sequence of random numbers - simply by drawing an equivalent random number from the random.
      • If the random number read from the log file matches the generated random number, then all is good.
      • If the random number read from the log file does not match the generated random number, then something is a miss and the problem is reported (an exception is thrown).
  3. Once B has stepped through the log file, B then immediately opens up a new log file - say B1.vlog.
    • As above, that means that the current seed should be written to the log.
      • However, there’s a bit of a caveat here, as we cannot reuse the old seed - sA1 (otherwise we’d need to know the full sequence of random numbers, which will no be in the newly started log file).
      • So instead, we draw one random number - say iB1 (a long) using the current seed (the one read from the log file) and write that to the log file.
      • Furthermore, we use that random number as the new seed - sB1 - from the random number generator, and we then write that seed to the log.
        • While we made a new seed - sB1, the seed we created is derived from the previous seed - sA1, and therefore we can check, later on, that that seed is as expected.
        • Had we simply generated a new seed, then we’d be back to the situation where a player may restart logs until favourable outcomes are achieved).
  4. B now generates random numbers and these are written to the log file, just like above.
  5. B ends the log file - B1.vlog and sends it to A.

Now comes the part where we check that things are consistent

  1. A Opens up its own log file A1.vlog first
    • This reinitialises the Random number generator with the seed in that log file - sA1.
  2. A then fast-forwards through the log file.
    • As above in 7, this will read in the random numbers and check if they are indeed in the sequence (and in order) of the Random number generator given the seed sA1
  3. Once A has stepped through the log file A1.vlog, the game is back to the state in step 4 above.
    • But crucially the current random number seed is set to the read seed - sA1, and we have replayed the sequence of random numbers to the same point as in step 4 above.
  4. A now opens the log sent by B - B1.vlog
    • This means that the random number generated in step 8 above - iB1 - using the seed sA1 is read in. We can therefore check that that random number is the expected random number - as in step 7 above.
    • Opening the log also means we read in the seed - sB1 - set in step 8 above, and we seed the Random number generator with that seed.
  5. A nows steps through the log file B1.vlog
    • As in step 7 above, every time we see a random number in the log file - generated from the seed sB1, which we are currently also using, we check if that read random number matches the next random number in the current Random number generator sequence.
  6. Once A has stepped through all of the log file B1.vlog, then A immediately starts a new log file - say A2.vlog
    • Again a new random number, given the seed sB1 is generated and written to the log
    • That random number is set as the new seed - sA2, and written to the log
  7. A does its moves, including generating random numbers from seed sA2, which are recorded in the log file.
  8. A ends the log file A2.vlog and sends it to B

Now B follows the same logic:

  1. B plays back its own log B1.vlog, so that the seed is set to sB1, and the sequence up to step 10 above is replayed.
  2. B then opens the log file A2.vlog, which first checks the random number - iA2 - based on seed sB1 - written in the log, and then reads in the new seed sA2.
  3. B then replayes the log and on each random number checks that it is the next random number in the sequence seeded in sA2.
  4. B starts a new log - B2.vlog, generates a random number based on sA2, and sets that as the seed - sB2.
  5. B makes random numbers, based on seed sB2
  6. B Closes the log and sends it back to A

In this way, there’s a consistency check on every step, that the sequence of random numbers is ultimate derived from the initial seed - sA1 - possibly via intermittent seeds - sB1, sA2, sB2, sA3, …, which them selves are derived - in a predictable fashion from the first seed sA1. The “trick” is to use the fact that pseudo random number generators are just that - pseudo - and they will always produce the same sequence of random numbers given the same starting point (seed).

The benefit of this approach, in so far as it works and can be implemented in Vassal, is that it is entire self-contained and does not require external services or the like. That also means that reading and writing log files does not require an internet connection.

Note, if no seed is seen in a log file, then no checks are performed. This would be to support older log files. Also note, that the logic carries over to on-line games, as an online game is really just a live replay of a log file. In an online game, all players will use the same seed and they will all see the same sequence of random numbers so they can check for consistency.

Yours,
Christian

15

Storing a sequence of numbers yet to be used (or a seed, which amounts to the same thing) isn’t secure. An unscrupulous player could look ahead into the sequence to see what upcoming rolls will be.

16

The sequence isn’t written until it is actually generated (steps 3, 9, 17, and 23 above). The only time the sequence is apparent is when the random numbers are played back and checked (steps 7, 12, and 21 above).

Also, because the seed is changed on each new log (steps 8, 16, and 22 above), albeit based on the current random sequence, it makes it practically impossible to guess the next random number.

Sure, if a user can decode the seed stored in the log file (which can be done although the log file is “encrypted”), then that user may write a small program that regenerates the sequence of random numbers. However, the user will have to know exactly which kinds of random numbers will be used (integer, bound integer, long, float, double, boolean) and in what order. That makes it unlikely that a user will have any success doing so.

One can argue, that if a user has the skill to do that work, then that user does deserve a leg up :smiley:

Also, consider what the effect of knowning the next die-roll would be (if at practically possible): A user could decide to resolve one combat over another. For example, if the next die roll is a 1, then the user may decide to resolve a soak-off attack rather than the main thrust attack, or vice versa if a 6 is coming up. However, the user will not be able to know before the opponents log is sent, what the die rolls would be, and can therefor not plan accordingly before hand. The user will not be able to change the die rolls, nor change the order of them - only where those die-rolls would be used.

No system will ever be fully tamper proof, but some systems will be more cumbersome than others.

I think the above outlined scheme is relatively tamper resistent, and has the added benefit that no external tool is needed. My largest concern with such a scheme, is that one has to make darn sure that all random numbers are recorded properly in the log file.

Yours,
Christian

17

I’ve made a Pull Request so that one can see in practise how the procedure outlined above would work in practise.

The PR is of course a proposal. Please refer to the PR for more details.

Yours,
Christian

18
  • The first player can set the initial seed to any desired value, undetected.
  • Any subsequent player can use the most recent saved seed to preview the next batch of rolls and the seed for the next player, which can then be used to preview the next player’s rolls.

If I know the sequence of dice types I will be rolling, I can use the current seed to look ahead into that sequence. For any game where there is only one type of die, it would be possible to know the rolls for a turn of any proposed length, and also the rolls for the next turn, though not necessarily how many rolls there will be in the next turn. A tool to do this would be trivial to write, and with that in hand, no significant expertise or effort would be needed to defeat this scheme.

19

Me neither. But unfortunately having been around a while and have seen that there are some out there who live in narrow worlds and have egos.

I was involved in a computer game once where someone was suspected of some very in-depth hacking of encrypted save game files. Return on the effort would be?? Go figure… :hushed_face:

You won’t stop the serious but I think the aim of a third party roller (or equivalent) is simply trust. That your opponent won’t take the easy option of a simple exploit (like re-running the turn) when things get difficult.

Reg.

20

VASL (Virtual Advanced Squad Leader) appears to call die rolls from random.org, at least when playing live via server.

Best,
Ken