Rubber Band Odds
"I am at all events convinced that He does not play dice."
— Albert Einstein
The curious name "rubber band odds" is taken from the game Brogue, where certain dice rolls are adjusted on the fly to increase or lower the odds of some item being generated. Food and strength potions, in particular, as without food the odds of completing the run can be low, and without sufficient strength potions the player runs higher odds of getting behind on the "power curve" and totally unable to deal with deeper threats, even with skilled play. To avoid these issues, the odds are stretched as if with a rubber band to even out both good and bad runs of the random number generator (RNG). Not all items in Brogue get such treatment; other items and monsters and attack rolls are generated with all the good and bad that comes with taking whatever the RNG gives.
The Problem
There is no problem if players are to be exposed to the cold hard reality of statistics, that is, the RNG will go on streaks where your 50% to-hit odds miss, say, five times in a row. Unlikely, but not impossible. This can be a concern if the Ogre is getting "better treatment" from the RNG and thus winning the fight. (Notice how humans may give agency to or personify the RNG.)
$ perl -e 'printf "$_\t%5.2f\n", 0.5 ** $_ * 100 for 1..13'
1 50.00
2 25.00
3 12.50
4 6.25
5 3.12
6 1.56
7 0.78
8 0.39
9 0.20
10 0.10
11 0.05
12 0.02
13 0.01That some players expect the rolls to eventually balance out goes by the name of the gambler's fallacy, a notable instance being when the ball fell in black 26 times in a row in a game of roulette at the Casino de Monte-Carlo in 1913. The ball "ought to" start landing more on red, right? A so-called monte carlo simulation can help illustrate the odds. The simulation simply runs the odds calculation many, many times and the resulting distribution is inspected for such attributes as the frequency of streaks or runs, how much variance there is, etc. A monte carlo simulation may be bad if the odds are expensive to calculate, or if the events are so rare as to require too many runs to extract any meaningful summary, or if doing the simulation takes one away from more important work. A simulation may be very useful if you are modifying the odds on the fly and want to enforce a particular attributes, usually to make the gambler's fallacy true in some way: if the ball has been falling on black "too much", then modify the odds so that red is more likely. In a game, if the RNG has generated "too little" food, then modify the odds to increase the odds of food being generated.
A Solution
One solution is to attach state to the odds of some event happening. The state is modified by such things as how the roll turns out, player attributes, items, effects, or other random factors. Increased complexity probably increases the need to run a simulation.
(block nil (setq *random-state* (make-random-state t)) (return))
(defconstant +base-odds+ -3)
(defparameter *state* +base-odds+)
(defun roll ()
(when (<= (random 10) *state*)
(setf *state* +base-odds+)
t))
(loop for n from 1 to 100 do
(format t "~a~c~a~c~a~&" n #\Tab (roll) #\Tab *state*)
(incf *state*)) $ sbcl --script rbodds.lisp | sed 16q
1 NIL -3
2 NIL -2
3 NIL -1
4 T -3
5 NIL -2
6 NIL -1
7 NIL 0
8 NIL 1
9 NIL 2
10 NIL 3
11 T -3
12 NIL -2
13 NIL -1
14 NIL 0
15 NIL 1
16 T -3This can be used to create a doubled note (in the music below, a semitone lower) shortly after some other note fires, but not too often because the odds go below zero percent for some number of iterations after such a note is generated.
It may be necessary to test such code with a monte carlo simulation to check that your assumptions are correct, especially if there are in-game items that the player can apply—a limited use luck charm, for example—that complicate the calculations. Being aware of the worse-case situation and the odds of it might be good to know; the above code could fail up to 11 times in a row some amount of the time. How bad would that be?
Another way Brogue avoids the RNG going on a run is to set a hard limit: if you search five times in a row the odds of secret doors being revealed goes up by some large amount. A non-linear odds progression could be of use:
search attempt | odds
---------------------
1 | 50%
2 | 10%
3 | 25%
4 | 50%
5 | 100%This applies some beginner's luck, and beyond that the player (if they know this chart) may need to decide whether to risk spending up to five turns searching versus doing other things with those presumably precious game turns. A risk here is when ideal play results in a lot of tedious button mashing: if game turns are not important, then doing a "five search" though all visible sections of the dungeon may be ideal play, but could be bad for the player's tendons. Playtesting may be advised, ideally with some inveterate min/maxers who like to find and exploit this sort of thing. On the other hand, in the original rogue the RNG could go on a run at the worse possible moment and the secret door necessary to continue the game would never be found. Problems in rogue were the bad RNG and more importantly that the search was only for the adjacent cells which could mean doing a lot of checks against a lot of long wall runs. It may be less bad to apply the secret door search to all visible wall tiles, which is what Brogue does, in addition to having the five-search boost.
Ultima took a different approach and the secret doors have a little dot in them you need to know to look for (the maps are also static, unlike the procgen one finds in a typical roguelike). This is a skill versus chance tradeoff; rubber band odds can help shift things towards skill or knowledge and away from blind luck, which may or may not be what you want.
Source