# Unexpected Number Generator
by Seth Kenlon
It sometimes surprises people that random number generation is a
classically famous problem in computer science. 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. Then again, for most
everyday uses, "mostly random" is good enough.
This is mirrored in the human world. You don't realise it until you're
asked to come up with a random number, consistently. For instance, 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?). It's good enough. But if you're asked to "generate" a new
random number every minute, you start to falter; your brain finds
patterns in what you come up with, or else you develop a bias.
The question of random number generation is very pertinent to gaming,
because no matter what kind of artificial intelligence 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 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 an airplane. On the 14
hour plane ride from New Zealand to the US, 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 the solo RPG 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, and
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. Plane rides are unpleasant enough without a weirdo sitting next
to you compulsively rolling a cup of dice.
If you're not on a plane, you still might not have dice on your person
every time you need it. Maybe you're killing time at a café, or you're
waiting for an appointment, or you have a few moments at the bus stop.
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](
https://gitlab.com/notklaatu/prettydicey/raw/master/mindice.py),
or the idea of using a standard deck of Poker cards (draw a card, get
a number), and most of these methods are very good and very
usable. However, I felt that none of the options were as convenient or
as simple as dice.
## ChapBooks and PocketMods
As chance would have it, I was at a
[Zine](
https://en.wikipedia.org/wiki/Zine) workshop at a local art
gallery, where I learned a cool paper folding trick used to produce
something called a [ChapBook](
https://en.wikipedia.org/wiki/Chapbook),
which the Internet tells me is now better known as the
[PocketMod](
http://www.pocketmod.com). 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 occured 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.
After all, 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 could not 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 consitent 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:
<table>
<tr>
<td>1</td>
<td>2</td>
<td>3</td>
</tr>
<tr>
<td>4</td>
<td>5</td>
<td>6</td>
</tr>
</table>
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 6 alternate grids)
with a different layout, making your "die roll" whatever you find in
the cell you chose. For instance, assume you choose 5 from the table
above. This sends you to Table 5, second cell to the right, bottom
row. Asssuming this is Table 5:
<table>
<tr>
<td>3</td>
<td>5</td>
<td>1</td>
</tr>
<tr>
<td>4</td>
<td>2</td>
<td>6</td>
</tr>
</table>
You have "rolled" a 2.
For your next turn, you'd use Table 2 (because you rolled a 2 last
time), and as long as you select a cell before looking at Table 2,
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 unnumeberd pages in a PocketMod booklet. The player'
job:
1. Start at any page in the booklet
2. Choose any cell in a table
3. 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](
http://scribus.net)
desktop layout application.
## Scribus
I don't generally use word processors or WYSIWYG applications, since
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.
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:
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, making
their "roll" result the number found next to that same letter in the
grid they find when they turn the page.
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". Suddenly, all destination
tables have changed! Unpredictably returns.
To add even *more* unexpectedness, I realised 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 6-cell table and a 10-cell table would be provided.
The 6-cell table simulates a 6-sided die ("d6", in gaming terminology)
and the 10-cell table a 10-sided ("d10") roll. Obviously, a d12 and
d20 can be simulated by rolling twice and taking the sum of the rolls.
### 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 6 sides of the die, so
there should be 6 snapshots of the die's arrangement. PocketMod
booklets, however, have 8 pages. Doubling up on tables per page
results in 16 snapshots, so no matter what, the system has space for
more snapshots than possible rolls.
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](
http://creativecommons.org)
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](
http://krita.org). 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:
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](
https://opensource.com/resources/what-is-git) repository located
at [gitlab.com/notklaatu/pocketdiceroller](
https://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](
http://www.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 lay-overs between each flight). That gave me plenty of
time to play some solitaire dice-based games. Using the [Tunnels and
Trolls](
http://www.flyingbuffalo.com/solo.htm) and the [Lone
Wolf](
https://www.projectaon.org/en/Main/Home) 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 (ten 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 realised 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. For a d12 or d20 roll, I'd probably use the same
system so that I didn't have to "roll" twice.
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!
