A 1% drop rate does not mean players get the item in 100 pulls. Roughly a third of them will not. Here is the math your players will eventually do for you, and how to design pity so the unlucky tail never becomes a one-star review.
What a 1% drop rate actually means
Start with the mistake almost every player makes, and a surprising number of designers make with them: reading "1% drop rate" as "1 in every 100 pulls." Probability does not work like a punch card. Each pull is independent, so the chance of walking away with nothing after n pulls is:
P(nothing after n pulls) = (1 − p)^n
Plug in p = 1% and the numbers stop matching intuition fast:
Pulls | Chance of at least one drop | Chance of still nothing |
|---|---|---|
50 | 39.5% | 60.5% |
69 | 50.0% | 50.0% |
100 | 63.4% | 36.6% |
200 | 86.6% | 13.4% |
300 | 95.1% | 4.9% |
Read that middle row again. After 100 pulls at a published 1% rate, more than a third of your players still have nothing. If 100,000 players chase that item, about 36,600 of them go home empty after spending what the rate implied should be "enough." That group is real, it is large, and it is the group writing your reviews.
You even need 69 pulls just to reach a coin flip. This is why "the drop rates are published and accurate" and "the drop rates feel like a scam" are both true at the same time. Honest math can still produce a miserable distribution.
Expected value vs. what players actually experience
The expected number of pulls to get a drop with probability p is simple:
E = 1 / p → at 1%, E = 100 pulls
If a pull costs 160 gems and gems cost roughly $0.01 each in your mid-tier bundle, the expected cost of that item is 100 × 160 × $0.01 = $160. That single calculation should sit next to every loot table you ship. Not because players will do it, but because content creators will do it for them, on camera, within a week of launch.
The trap is that expected value describes the average, and nobody experiences the average. The geometric distribution has a long right tail: plenty of players get the drop in 20 pulls, and a painful minority need 250 or more. Two things follow:
The median is kinder than the mean. At 1%, half of players succeed within 69 pulls, comfortably under the 100-pull average. Most of your players feel fine. That is exactly what makes the tail dangerous — the majority's experience hides the minority's.
Uncapped randomness has an unbounded worst case. Without pity, there is no number of pulls that guarantees the item. Someone in a large enough player base will hit a 1-in-10,000 dry streak, and they will not experience it as variance. They will experience it as your game being rigged.
The design rule hiding in this math: Never evaluate a loot table by its average. Evaluate it by the 90th and 95th percentile of pull cost — the price your unluckiest 10% and 5% actually pay. If that number would embarrass you in a Reddit thread, the table is not done.
Hard pity, with real numbers
Hard pity is a guarantee: if the item has not dropped by pull N, pull N grants it. It caps the worst case, and it also quietly changes the average. With a 1% base rate and hard pity at pull 80:
E = (1 − 0.99^80) / 0.01 ≈ 55.3 pulls
Three things just happened, and only one of them is obvious:
The worst case became finite. No player ever pays more than 80 pulls. Your support inbox and your app-store rating both feel this.
The average cost dropped from 100 pulls to about 55. Pity is not free. Adding a guarantee at 80 made the item roughly 45% cheaper on average, because every dry streak that would have run past 80 now ends there. If your revenue model was priced against E = 100, you just gave away nearly half the expected spend without touching the published rate.
The published rate stopped describing the system. The true "effective rate" — total drops divided by total pulls across the population — is now about 1.8%, not 1%. This is why serious gacha games publish a consolidated rate alongside the base rate. If you only publish the base rate, the honest number, players will eventually compute the real one and wonder what else you rounded.
Pricing rule of thumb: Set your pity threshold first, from the worst-case experience you are willing to sell. Then compute the expected pulls with that pity in place, and price the pull currency against that number — not against 1/p.
Soft pity and why effective rates diverge from published rates
Hard pity fixes the tail but creates a cliff: a player at pull 79 has no reason to feel lucky, they are just waiting. Soft pity smooths this by ramping the drop rate as the counter climbs. A common shape: base rate holds flat for most of the counter, then increases steeply per pull over the last stretch before hard pity.
The best-documented public example is Genshin Impact's 5-star banner: a published 0.6% base rate, hard pity at 90, and a soft-pity ramp that community data places around pull 74. The consolidated rate the game itself publishes is about 1.6% — nearly three times the base rate — because soft pity resolves most streaks in the 74–80 window. The distribution of "which pull did I win on" ends up with two bumps: a wide low hill across the early pulls and a sharp spike inside the soft-pity zone.
That spike is a feature, not an accident. It concentrates the win into a zone where the player has visibly invested, which reads as "the game rewarded my persistence" instead of "I got randomly lucky." Soft pity is as much an emotional design tool as a statistical one.
When you design your own ramp, you are choosing three numbers: where the ramp starts (how long the flat, tense phase lasts), how steep it climbs (how tightly wins cluster near the end), and where hard pity lands (the promise). Every combination produces a different expected cost and a different consolidated rate, and none of them can be read off the base rate anymore. At this point the system has too many moving parts to price by formula alone — which is where simulation comes in.
Duplicate protection changes the whole collection economy
Everything above covers a single chase item. Real gacha pools contain dozens, and the moment a player owns half the pool, half of their "wins" become duplicates. Without protection, the expected cost of completing a collection explodes — this is the classic coupon collector problem, where finishing a 50-item pool takes on average about 50 × (1 + 1/2 + ... + 1/50) ≈ 225 successful drops, and the last few items cost more than the first forty combined.
Duplicate protection (removing owned items from the pool, or converting dupes into a currency with a guaranteed-selection shop) does not just soften bad luck. It changes what late-game pulls are worth, which changes what your whales are actually buying, which changes how you should price everything past the mid game. A dupe-to-currency exchange rate is one of the highest-leverage numbers in a collection economy, and it is usually set by feel.
Simulate before you publish rates
By now the pattern is clear: every mechanism you add to make RNG feel fair — hard pity, soft pity, rate-up banners, dupe protection, guaranteed first drops — pushes the real cost of the system further away from anything you can compute on the back of an envelope. The base rate becomes the least informative number in the design.
The honest way to know what your loot table costs is to run players through it. Ten thousand simulated players, each pulling until they hit the target, with your exact pity counters and ramp values, gives you the full distribution: median cost, mean cost, 95th percentile cost, consolidated effective rate, and how all of those shift when you move soft pity from 65 to 70. Those are the numbers that should decide whether a table ships — measured before launch, not discovered by your unluckiest paying players after it.
What to read off the simulation: Median pulls to target (what most players feel), 95th percentile pulls (what your angriest players feel), consolidated rate (what you should publish), and expected revenue per completed chase (what finance asked for). If any of the four surprises you, the table is not ready.
A working checklist for shipping a drop table
Before a loot table goes live, you should be able to answer all of these with numbers, not adjectives:
1. What is the chance a player has nothing after the "expected" number of pulls? If it is over a third, your published rate will read as a lie even when it is not.
2. What does the 95th-percentile player pay? In pulls and in real currency. Decide whether you are comfortable with that person recording their spending on video.
3. Is the worst case bounded? If there is no hard pity, the answer is no, and you have chosen that.
4. Did you re-price after adding pity? Pity at 80 on a 1% rate cuts expected cost by ~45%. If the pull price did not change, your revenue model did.
5. Which rate are you publishing? Base, consolidated, or both. Players will compute the consolidated one either way.
6. What happens to pull value at 50%, 80%, 95% collection completion? If late-game pulls are mostly dupes with weak compensation, your best customers are the ones being punished.
Where Itembase fits
Itembase is a node-based tool for designing and simulating game economies. Loot tables, pity counters, currencies and player segments are all nodes on a canvas — so instead of estimating what your gacha costs, you run thousands of simulated players through the exact system and read the distribution directly: median cost, unlucky-tail cost, effective rate, and how each one moves when you drag a single value. Test the table before your players do.