VASL’s use of random.org is problematic. It’s using the old HTTP API, which has been marked as obsolete for quite a few years, and there’s no free way for VASL to use the new API in accord with the license terms for it.
What’s more, it seems that random.org’s older API does not provide a means to check that the die rolls where actually made. That means, that a malignant user may still “cook” the die-rolls by restarting a log until the user achieves the desired result.
What you need, to prevent against that kind of cheating, is a way for opponents to check that the current player only does one attempt at that users turn, or at least has committed to fulfilling that users turn, and will not restart a session to better results.
That is, an external random number generator - remember: it is not only die rolls, but also anytime Random is called, etc. - must provide
- a way to identify why the caller, possibly including the context - such as module, opponents, etc.
- when the calls where made
- and a way for opponents to get the list of random numbers to verify against the log file.
This is not a simple random number generator like the old API of random.org (the newer API does seem to allow for these points).
Perhaps a simpler approach would be the following:
- A new File menu item - say Begin audited log file …
- When the user presses that button, several things happen:
- A unique ID is put in the log file - this can generated automatically, possibly with a time-stamp.
- A “message” of some kind is sent to third-party that records the unique ID (and possibly timestamp), together with metadata (user selected, module, module version, user name, …)
- When the user presses that button, several things happen:
- Another new File menu item - say Load audited log file …
- When a user uses that entry, then Vassal will look for the recorded unique ID and possible timestamp.
- The client may then “ask” to verify that the unique ID is correct, and that there are not previous attempts with the same metadata after a certain timestamp.
The “message” sent could be an API call to third-party server that records the unique ID and metadata in a database. The “ask” is then a look-up in that database to see if the entry exists, and that the metadata matches, followed by another query to check that there a no other previous entries with the same metadata older than some given date (the time when the next to last log was created).
The metadata could be entered by the user and be some agreed upon identifier - e.g., “Jane and Joe playing The Greatest Game of All”. When verifying the log, the user would also be asked to enter the metadata. E.g., Jane and Joe agree to “sign” their log entries with “Jane and Joe playing The Greatest Game of All”. When Jane is checking Joe’s log, the system may prompt for the earliest possible time when Joe could have submitted a log.
Vassal already prompts for a comment on log files, so that comment could be used as the metadata. Loading of an audited log file will take a bit more.
To make the “message” entry on the server, one would probably need to authenticate and be authorised.
The idea is fairly simple: When a user is ready, that user commits to creating a log, and that commitment is recorded. Opponents can then check that the log they received was indeed the only log committed to. If there are more than one possible committed log, then all such logs are refused.
If fraud is detected - because there’s more than one log - I would find it prudent to terminate the game there and then and declare the non-malignant party the winner. However, sometimes mistakes are made, and Jane may say, well, here’s the timestamp I will use for the log. Make a new log and commit to that - then I’ll take that.
This would mean that opponents do not check the random numbers directly, but rather that the other opponents committed to their log. Thus, the random number generator in Vassal - which is pretty good BTW, probably as good as random.org - need not be changed at all. Once you commit to log, you commit to a sequence of random numbers. Rather, we are recording the commitment to a log, and then insisting on a single commitment.
Off-hand, there’s a way that a user could still cheat. A user would start an audited log, making the server entry. The user would then immediately close the log. The user would then use the Fast forward and append tool to create the final log, restarting that process if the random numbers didn’t produce the desired outcome. Of course, Vassal could detect that situation because the initial log file had a unique Audit ID in it, and then refuse to append.
A third way would be a File button: Begin online logfile … which, when pressed will prompt the user for some identifier - say Jane and Joe playing The Greatest Game of All, and then the log file will be written to some external server and not to disk. Then Jane will pick up Joe’s last log from there, checking that Joe did not commit more than one log since Jane’s last log. In this scenario, one probably doesn’t even need a third party specialised service, but could use cloud storage such as Google Drive, OneDrive, … - as long as one can make sure that those third party services records if files are changed or disallows overwriting files.
Again, the point is, you commit to making a log before any random numbers are generated.
Anyway, my 2 ¢
Yours,
Christian
Committing to a log file, is the one I share with my opponent, probably not my first attempt.
If I’m playing a complex game, I might try 5 or 6 log files of possible moves before I get to the combat phase where the dice have to be rolled. Then I realize that the first half of my 2nd log (that was early morning yesterday) was great, but it needs something like the second half of my 4th log to be ideal tactics. I can go back to my 2nd log, start recording my 7th log, step through the good part of the 2nd log, and end the 7th log. Reopen the 7th log, start recording my 8th log, step through the 7th, and then manually enter and record the good parts of the the 4th log. When I end that 8th log, I’ve got a set of moves that I’m prepared to share with my opponent. Using a 3rd party roller (I use dicelog.com) I share my rolls with explanations to my opponent. If the dice gods don’t smile upon me, my opponent knows.
I like that the system doesn’t let my opponent cheat, but more importantly, I want a system that does not tempt me to cheat myself.
The current log file system, associated with an external dice roller, allows me to experiment with alternative strategies and craft good moves to share with my opponent
If I understand what it is you do, but please correct me if I’m wrong, is
- You may create several log file, starting from the previous log file, to try out different strategies, tactics and operations. However, in none of these log files do you do anything that involves random numbers.
- You may then decide, that one or more particular log files is the strategies, tactics, or operations that you want to employ, so you replay those logs (in full or in part), and possibly amend with additional operations. Again, at this point, no random numbers have been involved.
- Then, you will start to do actions, and record them in a log, that involves random numbers, such as combat die rolls and so on.
Essentially, you have two stages - or phases - in your log file creation:
- One where randomness is not a factor - say the movement phase
- One where randomness is a factor - say the combat phase.
It is only the second phase - or combat phase - where there needs to be some kind of accountability or ability to audit.
What I hear you advocate, is that in the first phase, one should be free to try and retry to ones hearts content, while in the second, you have to commit to what ever comes out.
I think that is perfectly compatible with my suggestion of an audited log: In the first phase, you do not start an audited log, while in the second you do. Practically, it could be that one would make two logs - one for each phase, and only the second, the audited on where random numbers are generated, need to have a known timestamp and unique ID.
Of course, a player may decide to make one audited log if that player is confident - or the game is simple enough - that the player can do the movement phase part reliably.
Of course, when creating an audited log, one may not (and Vassal should enforce that) replay other logs. Otherwise, one may make logs until desired outcomes, and then pass that off as the audited log.
The point is really that your opponent does not need to be able to check your random numbers - only that that you used the random numbers that you got on the first try. This is far simpler - and allows for equal flexibility in the movement phase - than using a third-party die-roller.
When you start an audited log, a unique ID - e.g., Jane and John are playing The Greatest Game of All - John's 2nd turn, combat phase and a timestamp is registered somewhere. Your opponent can then check that there’s no previous attempt at making a log. And, if your opponent sees that you made random numbers in an non-audited log, then your opponent can see that you are cheating.
For this system, one could set it up with two relatively small components:
- A simple server that responds to a request, with a Unique ID as payload, and gives back a timestamp. The Unique ID and time stamp is registered and can be viewed by others.
- Some code change in Vassal to make the request to the server, and put the UniqueID and received timestamp into the log file. When loading a log with such a UniqueID and time stamp, then Vassal should prompt the replayer to check the server if the UniqueID and timestamp is OK. It could do some of it itself.
This would also make the data stored on the server fairly simple and small, as well as infrequent.
Yours,
Christian