It sometimes surprises people that random number generation is a classically famous problem in computer science, because it seems like it should be so easy; just pick a number. And yet it's hard to get a computer to be random. Many Linux users have some awareness of the /dev/random and /dev/urandom devices, and most have some awareness that technically, the numbers generated there are not truly, scientifically random.
This is mirrored in the human world. You don't realize it until you're asked to come up with a random number, consistently. If you just need one random number, you can reach into your thoughts and pull out whatever number you find floating around (did you say 3, 7, 23, or 42?). As with non-crypto processes in computers, "mostly random" is good enough. But if you're asked to "generate" a new random number every minute, you start to falter; you develop a bias for a certain range or pattern of numbers, and even if you don't, your brain finds patterns in what you come up with so you doubt your randomness.
The question of random number generation is very pertinent to gaming, because no matter what kind of artificial intelligence (AI) you're up against, it just feels more realistic if there's a degree of randomness thrown in. Some games don't really have AI at all and depend entirely on the roll of the dice for conflict.
The problem with a die
Analogue gaming solved the problem of getting random numbers long ago, most notably with dice. Roll dice, get a random-enough number. Problem solved.
The trouble with dice, for me, is that you don't always necessarily have dice available, and you don't always have a place to throw the dice. Specifically, I run into this problem on airplanes. On the 14-hour plane ride from New Zealand to the US (and the following 6 hour flight to the East coast), I often keep myself occupied with solo RPG adventures; a sort of "choose your own adventure" book with the additional dimension of skill points, combat levels, and other statistical variables. In order to determine where in a solo RPG or dungeon crawler I go next, a series of die rolls determine the outcome of combat or dexterity (if attempting to avoid a sudden trap, for instance).
I could bring dice along on a plane ride, but I never think to. Even when I do, I'm self-conscious about dropping dice into my empty coffee cup and rattling them up every three minutes while I play a game. Even if you're not on a plane, you might not happen to have dice on your person every time you need it; maybe you're killing time at a cafe, or you're waiting for an appointment, or you have a few moments at the bus stop.Another scenario that became all-too real on 14 November of this year was evacuating my home after a 7.5 earthquake; whilst waiting for the tsunami warnings to fizzle out, I found myself with plenty of time to play a game, but no die.
As a result of the potential social awkwardness of dice and the fact that dice don't typically fit into your wallet, I decided that an alternative was required. I wanted something that could produce numbers with the illusion of randomness and could fit in my wallet or in the folds of a book.
If you look for it, the Internet does propose alternatives to dice. There are some interesting mathematical tricks, like a self-seeding modulo progression, or the idea of using a standard deck of Poker cards (draw a card, get a number), a wheel of fortune, and so on. Most of these methods are very good and very usable, but I wanted something as convenient, efficent, and as simple as dice.
ChapBooks and PocketMods
As chance would have it, I was at a Zine workshop at a local art gallery, where I learned a cool paper folding trick used to produce something called a ChapBook, which the Internet tells me is now better known as the PocketMod. Whatever the name, it's a very simple way to turn one US Letter or A4 sheet of paper into an 8-page booklet requiring no staples or binding. The result is a booklet small enough to fit into your wallet.
It occurred to me, after attending the workshop, that the PocketMod form factor was so convenient and so simple that it would be the perfect distribution method for a dice replacement. All I had to do was invent and design it.
Unexpected number generation
It doesn't work so well with encryption or anything subject to repetitious brute force or analysis, but for solo and cooperative gaming, what we usually want is unexpected numbers. We don't actually care how random it is, as long as when we see the number, we are genuinely surprised. Even in competitive gaming, an unexpected number is as effective as a random one, as long as it is equally unexpected to all players.
You can safely assume that your opponent (or yourself, if playing solo) would, if they had the option, choose the highest possible result every time they were asked to roll dice. Any system that renders a number that you cannot predict feels suitably random, because even though you rolled your eyes and said "they'll roll a 6, of course", they ended up just rolling 3. It's a genuine surprise, so it feels random, and it stays consistent to the innate uncertainty of game outcome.
I had the notion that a grid of numbers could serve as both its own offset, which would in turn trick the human brain into making random-enough choices to produce an unexpected number.
For instance, if I have a simple grid:
| 1 | 2 | 3 |
| 4 | 5 | 6 |
And I ask you to choose a number, then I could use whatever number you choose to select a new grid (from a hidden stash of six alternate grids) with a different layout, making your "die roll" whatever you find in the cell you chose. For instance, assume you choose five (5) from the table above. This sends you to table five, middle column of the bottom row. Assuming this is table five:
| 3 | 5 | 1 |
| 4 | 2 | 6 |
According to our system, you have "rolled" a two.
For your next turn, you'd use table two (because you rolled a two, last time), and as long as you select a cell before looking at table two, you'll again be surprised by the result, because there's no way to predict what number is in what cell.
This is true, at least, until you get used to which table is which, but that problem can be remedied by using unnumbered tables. Instead of assigning tables a label, I decided to designate them by position: specifically, by unnumbered pages in a PocketMod booklet. The player's job:
- Start at any page in the booklet
- Choose any cell in a table
- Using the number in the cell you chose, flip that many pages
It's effectively a random number generator; not scientifically, but mentally. Feedback from players so far has confirmed that the system confuses the human brain sufficiently that any kind of bias ("I'll choose a low number on this page because I'm pretty sure I remember that 5 pages to the right will render a high number in the same position") turns out to be unreliable enough to discourage the brain from devising a secret, compulsory hack.
There are more tricks I found I could do in terms of designing the physical implementation of this system, which I accomplished with the very good and completely open source Scribus desktop layout application.
Scribus
I don't generally use word processors or WYSIWYG applications, because they all tend to assume that you're designing for a single output. However, for this project I was designing for a specific output; I wanted to produce a file that would be printable on a single US Letter and A4 sheet of paper, which would then be folded into a PocketMod, and carried in one's wallet, or used as a bookmark in a gaming book. Having used it for professional print work at a former job and for some community conferences, I knew that Scribus was the tool for the job.
When starting with a page layout application, the first step usually is to set the target page size. To make sure everything folds correctly, a separate file for US Letter and A4 was required.
Page size and orientation.Next, I needed to define what a "page" was, within the booklet. I could have faked this, or spent hours dragging-and-dropping guides in Scribus, but I prefer to let the software do the calculation for me. From the Page menu, I selected Manage Guides, and used the Column/Row setting in the Guide Manager window that appeared:
Guides.
Next, I generated some simple grids. To avoid confusion between page-turns and roll results, I decided to use letters as references. A player chooses a letter, which has the number of page turns to their destination, making their "roll" result the number found next to that same letter in the grid they find when they turn the page.
Tables.
An advantage to the PocketMod design is that it can be an infinitely looping book if you let it, with no obvious beginning or ending. If a player feels like the unexpectedness of their die rolls are suffering, then the offset of the initial page turns can be changed just by making a new page the "first" page. Suddenly, all destination tables have changed! Unpredictably returns.
To add even more unexpectedness, I realized that the booklet is not only infinite, but also flippable and floppable. There's no need to define a beginning, an ending, a left-to-right or right-to-left, or top or bottom. So I added upside-down tables to each page, giving a player the option to decide which way the book should be oriented for each roll.
And finally, to make the system even more diverse, I decided that both a six-cell table and a 10-cell table would be provided.
A sample page.
The six-cell table simulates a six-sided die ("d6", in gaming terminology) and the 10-cell table a 10-sided ("d10") roll. Additionally, a d12 and d20 can be simulated by rolling twice and taking the sum of the rolls, or by taking the results of both right-side-up and upside-down tables on the destination page.
Statistically incorrect
The "problem" with my system is that it is, strictly, statistically incorrect. The action of a "roll" is simulated by differently arranged cells in a number of tables. On a d6, there are six sides of the die, so there should be six snapshots of the die's arrangement. PocketMod booklets, however, have eight pages. Doubling up on tables per page results in 16 snapshots, so no matter what, the system has space for more snapshots than possible roll configurations.
There's certainly a "right" way, mathematically, to solve this glitch, but ultimately I chose to follow the path to greater unexpectedness at the expense of statistically accurate (pseudo) randomness.
The project is Creative Commons licensed, however, so if a statistician is interested in formulating "correct" tables to balance out potential results, it's open for improvement!
Instructions
To make the system self-contained, I wanted to write instructions on how to use it and, possibly more importantly, how to fold it into a booklet, on the opposite side of the printed page. There are instructions on folding pages into a PocketMod online, but I wasn't able to find licensing information, so I decided to recreate the instructions myself.
My go-to tool for hand-illustration is the excellent open source Krita. Armed with a cheap Wacom tablet (all of which ship with Linux drivers) and Krita, your illustrations can look professional and even a little artistic.
Generally, I find that the trick is in the brush choice. The difference, for instance, between a really great Krita brush with tapered strokes and variable thickness and a pixel marker straight out of KolourPaint can make all the difference:
Krita made the pretty one.
Since I found most instructions online a little confusing, I based the instructions mostly from what I'd been taught at the Zine workshop. It took me no more than 15 minutes to complete. I saved the file and exported a version as a png, which I imported into Scribus and positioned on the second page of my design.
All design files for the project are open source, available from a git repository located at gitlab.com/notklaatu/pocketdiceroller.
Distribution
There are plenty of ways to distribute a one-sheet analogue dice rolling emulator; distribution paths are not a problem that open source software and free culture have. However, I didn't want to assume that a player would know what git was, or even how to print or build a PDF from Scribus. I wanted to be able to deliver the final product to players, ready to print from home. The Pocket Dice Roller works best if you have multiple copies of it lying around; one in your purse or wallet, one tucked away in your RPG rulebook, another in your backpack, and a backup in your notebook. Only then can you ensure you're never without an Unexpected Number Generator.
To my surprise, many online distributors expect you to want to sell your product. I didn't want to charge for my product, but ultimately I found the perfect site for it: rpgnow.com/product/195037/Pocket-Dice-Roller. It's a site already attracting a hardcore gamer audience, and while it does allow vendors to charge for their work, it has no built-in expectation of charging. This site allows gamers to discover the system by browsing a site they already go to, download the product for free, and then print it at home.
Play testing
Yes, but does the system work?
I recently had the pleasure of flying for over 24 hours straight (not counting the layovers between each flight). That gave me plenty of time to play some solitaire dice-based games. Using the Tunnels and Trolls and the Lone Wolf gaming systems, I played hours upon hours with all dice rolls being emulated by the Pocket Dice Roller. The latter game system uses a d10 (10-sided die) and the former a d6, so I was able to test both tables extensively.
Without actual dice, I was pleased to find the games as difficult, complex, nail-bitingly entertaining as ever. The numbers were completely unpredictable; even when I started to think it was becoming predictable, it surprised me by proving I had no way of knowing what number I'd land on upon turning to the seeded page.
My emulator is also more flexible than I'd realized whilst designing it.
First of all, you can either use rolling seeds (your previous roll value becomes your new seed), or you can re-seed each time, from any table. You can even use the wrong table for seeds; just because you're playing with a d6 doesn't preclude you from seeding from the d10. And if you feel sufficiently confused about the orientation of your Pocket Dice Roller booklet, you're free to skip the seed process entirely; just pick a letter and turn to a random page.
The Lone Wolf system uses a combat ratio to calculate damage for both you and your enemy, so one roll per attack is all that's required, but the Tunnels and Trolls system requires two rolls: one to calculate your damage, and another to calculate your enemy's damage. When a game required two rolls, I found myself picking a letter and turning to a page and using either the letter result on the facing tables, or on the two tables of the same page (the north- and south- facing tables). I established a rule about which result was the hero and which was the enemy, so it was essentially two rolls in one action, which sped things up a little in the physical game play and actually made the attack process more exciting, as if it was all happening at once.
After several hours of a card-based dungeon crawler and the two day flight (24 hours there, 24 hours back) RPG marathon, I'm confident that the Pocket Dice Roller is as satisfyingly unpredictable as the roll of a die. Download it and try it. Better yet, open up Scribus and make it your own!
Comments are closed.