A 1% Drop Rate Is Not “One Item Every 100 Pulls”

When players see a 1% drop rate, most interpret it as:

“If I make 100 pulls, I should get the item.”

But that is not what the probability means.

Each pull is an independent attempt. The game does not remember the previous failures unless the system has a pity counter.

This small misunderstanding creates one of the biggest problems in loot-system design: a drop table can be mathematically correct and still feel dishonest.

What does a 1% drop rate actually mean?

If the probability of receiving an item is p, the probability of not receiving it from one pull is:

1 - p

The probability of receiving nothing after n independent pulls is:

P(nothing after n pulls) = (1 - p)^n

For a 1% drop rate:

P(nothing after 100 pulls) = 0.99^100
                            ≈ 36.6%

This means that after 100 pulls:

• 63.4% of players will receive at least one copy
• 36.6% will still receive nothing

If 100,000 players chase the same item, approximately 36,600 of them can complete 100 pulls without getting it.

The published rate is correct. The negative player experience is also real.

Here is how the probability changes as players make more pulls:

Pulls	Chance of getting the item	Chance of getting 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%

It takes 69 pulls just to reach a 50% chance of receiving the item.

Even after 300 pulls, around one player in twenty can still have nothing.

Expected value does not describe a real player

The expected number of pulls required for an item with probability p is:

Expected pulls = 1 / p

At a 1% drop rate:

Expected pulls = 1 / 0.01 = 100

This is where “one item every 100 pulls” comes from. But 100 is the population average, not a guarantee.

Some players will receive the item on their first pull. Others might need 50, 200, or 400 pulls. With uncapped randomness, there is no maximum number of attempts.

Suppose one pull costs 160 gems and the player effectively pays $0.01 per gem.

Expected cost = 100 × 160 × $0.01
              = $160

The expected cost of the item is $160, but individual players will not all pay $160.

Some will pay $1.60. Some will pay $320. A small group may spend much more and still fail.

This is why averages are not enough when evaluating a loot system.

Measure the unlucky tail

Imagine two loot systems with the same average cost.

In the first system, most players receive the item between 70 and 130 pulls.

In the second system, many receive it early, but a small group needs 300 or more pulls.

The average may be similar, but the player experience is completely different.

Designers should therefore measure more than the mean:

• Median pulls: what a typical player experiences
• 90th percentile: what the unluckiest 10% experience
• 95th percentile: what the unluckiest 5% experience
• Maximum cost: whether the system guarantees an outcome
• Effective drop rate: the real number of rewards divided by total pulls

The 95th percentile is especially useful.

Ask a simple question:

Would we be comfortable if a player recorded this amount of spending and posted it publicly?

If the answer is no, the loot table probably is not ready.

Hard pity changes more than the worst case

A hard pity system guarantees the item after a fixed number of unsuccessful pulls.

For example:

• Base drop rate: 1%
• Hard pity: pull 80

Now no player can go beyond 80 pulls without receiving the item.

That sounds like a small fairness feature, but it changes the entire economy.

The expected number of pulls with hard pity at N is:

E = (1 - (1 - p)^N) / p

For a 1% base rate and pity at 80:

E = (1 - 0.99^80) / 0.01
  ≈ 55.3 pulls

Without pity, the expected result was 100 pulls.

With hard pity at 80, it falls to approximately 55 pulls.

The system now has three important differences:

1. The worst case is limited to 80 pulls.
2. The average cost falls by approximately 45%.
3. The effective drop rate becomes higher than the published base rate.

If the economy was originally balanced around an average of 100 pulls, adding pity at 80 without changing anything else can significantly change expected revenue.

This does not mean pity is bad. It means pity must be treated as part of the economy rather than as a UI feature added later.

A better workflow is:

1. Decide the maximum acceptable player cost.
2. Set the pity threshold.
3. Calculate the new expected number of pulls.
4. Rebalance pull prices and rewards around that result.

Why soft pity often feels better

Hard pity prevents extreme bad luck, but it can create a predictable cliff.

If the guaranteed reward arrives at pull 80, a player at pull 79 may no longer feel excited. They are simply waiting for the guarantee.

Soft pity increases the drop rate as the player approaches the hard-pity threshold.

For example:

Pulls 1–60:   1% probability
Pulls 61–70:  probability gradually increases
Pulls 71–79:  probability increases more aggressively
Pull 80:      guaranteed reward

This changes the emotional experience.

Instead of most unlucky players reaching exactly pull 80, many win during the final stretch. Their persistence appears to be rewarded before the guarantee becomes visible.

But soft pity also makes the system harder to calculate.

Once the probability changes between pulls, 1 / p no longer describes the system. Designers need to account for:

• The pull where soft pity begins
• The probability increase per pull
• The hard-pity threshold
• Whether pity resets after success
• Whether pity transfers between banners
• Whether featured and non-featured rewards use separate counters

At this point, simulation becomes more reliable than a simple formula.

Duplicate protection changes collection value

The previous examples assume the player wants one specific item.

Real loot pools may contain dozens of characters, weapons, cards, or cosmetic items. As the collection grows, duplicate rewards become increasingly common.

Consider a pool containing 50 items with equal probability.

Receiving the first new item is easy because every result is new. But when a player owns 49 of the 50 items, only one possible result completes the collection.

Without duplicate protection, completing the collection follows the coupon collector problem.

The expected number of successful drops required to collect all 50 items is approximately:

50 × (1 + 1/2 + 1/3 + ... + 1/50)
≈ 225 successful drops

The final few items can cost more than much of the earlier collection.

This means the value of a pull decreases as the player progresses. Ironically, the most committed players may receive the worst value.

Common solutions include:

• Removing owned items from the pool
• Converting duplicates into useful currency
• Allowing players to exchange duplicate currency for a selected item
• Guaranteeing a new item after several duplicate results
• Creating separate pools based on collection progress

Each solution changes the economy.

A duplicate-conversion rate is not a small balancing detail. It determines what late-game pulls are worth and how expensive completing the collection becomes.

Simulate the exact system before launch

Loot systems quickly become too complicated for intuition.

A real system may include:

• Base drop rates
• Hard pity
• Soft pity
• Featured-item guarantees
• Pity resets
• Duplicate conversion
• Player-selected rewards
• Multiple currencies
• Discounted pull bundles
• Free pulls
• Different player segments

The safest approach is to simulate thousands of players using the exact rules.

For every simulated player:

1. Start with an empty pity counter.
2. Perform pulls using the configured probability.
3. Increase the pity counter after failures.
4. Apply soft pity when the threshold is reached.
5. Apply hard pity if necessary.
6. Reset or transfer the counter according to the real rules.
7. Continue until the target reward is received.

From the results, measure:

• Mean pulls
• Median pulls
• 90th and 95th-percentile pulls
• Maximum pulls
• Effective drop rate
• Real-currency cost by percentile
• Duplicate frequency
• Collection-completion cost

You can then compare different configurations.

What happens if soft pity begins at pull 60 instead of 70? What happens if hard pity moves from 90 to 80? What happens if duplicate currency becomes 20% more valuable?

These questions should be answered before players spend money, not after the first complaints appear.

A practical checklist

Before publishing a loot table, make sure you can answer these questions with numbers:

1. What percentage of players will still have nothing after the “expected” number of pulls?
2. What will the median player pay?
3. What will the unluckiest 5% pay?
4. Is there a guaranteed maximum cost?
5. How does pity change the expected cost?
6. What is the effective drop rate after pity?
7. What happens when most rewards become duplicates?
8. How much does it cost to complete the collection?
9. Are the published probabilities enough to explain the real system?
10. Have you simulated the exact rules used in the game?

A fair loot system is not necessarily one where everyone wins quickly. It is one where the possible outcomes are understood, the worst case is intentional, and players are not exposed to costs the design team never measured.

The base drop rate is only the beginning of that calculation.

You can read the original article and explore how Itembase can simulate game-economy systems here: