Abstract
Problem: Game developers frequently request "randomness" in their systems, but true randomness consistently produces results that feel broken or unfair to players and colleagues alike.
Approach: Tim Cain shares three war stories from Fallout and WildStar where he implemented mathematically correct randomness, only to be told it was wrong — then walks through the iterative solutions he developed.
Findings: What people call "randomness" is almost never what they actually want. They want shuffled permutations, escalating probability, or guaranteed bounds — systems that feel random while constraining the uncomfortable extremes that true randomness produces.
Key insight: As a programmer, learn to listen to what people want, not what they're asking for. "Random" is a word smart people use to mean something it doesn't mean, and your job is to extract the actual requirement.
The Fallout Miss Streak
Fallout used a linear congruential generator from Numerical Recipes in C — a simple, long-period pseudo-random generator with excellent chi-squared values. Mathematically bulletproof.
One day, the head of QA came to Tim's office: "The random number generator is terrible. I had a 95% chance to hit and missed three times in a row."
Tim did the math:
- 5% chance to miss = 1 in 20
- Miss twice in a row = 1 in 400
- Miss three times in a row = 1 in 8,000
Sounds rare — but if you fire ~200 shots per hour (20 shots per encounter × 10 encounters), and work 40 hours a week, that's 8,000 shots per week. You should expect to see a triple miss roughly once a week. The QA tester had been playing for months.
The random number generator was working perfectly. That was the problem.
The WildStar Music Shuffle
WildStar's audio director gave Tim five songs and said "play them randomly." Tim picked a number 1–5 each time a song ended.
Day 1 complaint: "I heard song one twice in a row." There's a 20% chance of that happening on any transition. Tim added a re-roll: if the next pick matches the current song, pick again.
Day 2 complaint: "I heard song one, then song two, then song one again. I never heard songs three, four, or five." True random selection doesn't guarantee coverage. Tim switched to shuffling the sequence 1–5 and playing through the entire shuffle before re-shuffling.
Day 3 complaint: "I heard two songs in a row — song three ended the first shuffle and started the second." Tim added one final rule: when generating a new shuffle, if the first song matches the last song of the previous shuffle, swap position one with a random position from two through five.
The final system is explicitly not random. It's a shuffle without replacement, with a cross-boundary constraint. But the audio director was happy because it matched what he meant by "random": hear all songs before any repeats, never hear the same song back-to-back.
The WildStar Loot System
A designer asked for monsters that drop loot 20% of the time. Tim implemented a straight 20% roll.
Complaint 1: "I killed 10 monsters and never saw loot." Possible — roughly a 10.7% chance. The designer wanted the drop chance to increase with each kill that doesn't drop loot.
Complaint 2: Still seeing long dry streaks. The designer added a third requirement: a maximum kill count after which loot drops automatically, regardless of the roll.
The final system had three layers: a base drop chance, an escalating modifier per failed kill, and a hard ceiling. Tim had to maintain per-player, per-creature-type kill tracking — a significant data overhead compared to a single random roll. The same pattern repeated two weeks later when the designer noticed critical hits (set to 20%) weren't landing reliably.
What "Random" Actually Means
Tim identifies a fundamental vocabulary gap:
- To a programmer: randomness means rolling dice and accepting whatever they show.
- To everyone else: randomness means a shuffled permutation — the full list of possibilities enumerated, shuffled, and dealt out without replacement. Like a deck of cards: you can't draw the Queen of Spades twice until you reshuffle.
This is why casinos reshuffle before the end of the deck or use multiple decks — to defeat card counting, which exploits the non-random nature of permutations.
The Deeper Lesson
The recurring theme across all three stories: people ask for things that aren't what they actually want. They may lack the vocabulary, the self-reflection, or the ability to articulate the true requirement. This applies beyond randomness — it's true when reading game reviews, forum feedback, and feature requests.
Tim's advice to programmers and designers:
- Learn what terminology actually means in a technical context
- Ask for exactly what you want, not a vague approximation
- Listen to what people want, not what they say they want
- Expect this pattern to continue — it's been happening for decades
References
- Tim Cain. YouTube video. https://www.youtube.com/watch?v=DqL9R5PqE20