How we designed the cascade bonus

We wanted a combo reward, so we simulated the thing before building it. The obvious version turned out to pay sloppy play more than careful play, which is close to the opposite of what we were trying to do, and that result is why the bonus we eventually shipped is so small.

The idea, and the two ways to build it

Here is the setup. In Pebble Merge, one dropped stone sometimes sets off more than a single merge: two pebbles fuse, the result lands against a matching neighbour, that one fuses as well, and every so often the whole thing keeps going for another link or two. It feels fantastic. It is the best moment the game has, and naturally we wanted to pay for it.

There are two candidate definitions of “combo”, and they are not remotely equivalent:

• Time combo. Several merges inside a few seconds count as one combo.
• Cascade. One drop directly causes several chained merges.

Which is easier to implement is the question we wasted an afternoon on before realising we had picked the wrong question by accident. The one that matters is whether the mechanic rewards something the player actually controls, because a reward for luck is not a mechanic at all. It is a slot machine with extra steps, and players can smell that within a week.

The decisive test: skill versus luck

So we measured it. The simulation, that measured the progression layer rather than a stand-in for it, since any hand-written approximation would quietly smuggle in our own assumptions about what a board looks like after three drops, and those assumptions were exactly what needed testing. Then we ran it under two policies. The “random” policy drops stones anywhere. The “aimed” policy aims at the highest stone of the same kind, which is more or less what a moderately competent player does once they notice that height decides whether a chain keeps going. If a mechanic rewards skill, aimed play has to produce noticeably more of it.

Twelve simulated games per policy:

A ratio near 1.00 means the mechanic cannot be told apart from luck. On that basis the time combo fails completely, and reading the table again it was never going to do anything else: inside a three-second window roughly two thirds of merges already sit next to another merge whether you aim or not, so the bonus would fire almost automatically on any decent board. The gap distribution made it worse. Median gap between merges was 1.2 seconds, and a quarter of them came in under 0.15 seconds, which means most of what the timer was calling a combo is just the internal steps of one cascade being counted several times over. The timer had been measuring how fast players throw rather than how well they place.

Cascades of two carry a weak but genuine skill signal at 1.26×, which was enough to keep working on. Cascades of three or more drop straight back to luck at 1.02×. One caveat we owe you: our simulated “aimed” policy stands in for a competent player rather than an expert, so none of this rules out the possibility that a really good human learns to set up deep chains deliberately by reading two stones ahead. What the numbers do show is narrower than that. No simple aiming behaviour predicts them, and if players cannot aim for something, paying them for it is nonsense.

The part that killed the generous version

Skill questions aside, we also checked what a generous multiplier would do to the score economy, because adding a multiplier changes what every number in the game means rather than simply adding some points on top. Take a plausible ladder: no bonus, then ×1.5, then ×2, then ×3. Total score inflates by 63.5% under random play and by 48.3% under aimed play. That gap, pointing the wrong way, is the whole problem in one line of output.

Read the direction of those two numbers carefully, because I got it wrong on the first pass and had to be shown. The bonus is worth more to the sloppier player. The gap between a careful player and a careless one, which sat at about 45%, compresses to roughly 32%, so a mechanic we had added specifically to reward skill would quietly have cut the reward for skill, and we would have shipped it convinced we had done the opposite. In exchange for that, every existing best score and every leaderboard entry would also have stopped being comparable overnight, which players notice even when you warn them first.

What we shipped instead

The reward moved out of the score and into the feedback, almost entirely:

• A chain of two gets a floating label and no score change at all. It happens often enough that paying it out would put us right back where the ladder did.
• The third merge in a chain multiplies its own points by 1.15.
• The fourth and beyond multiply by 1.30.
• Every extra link lifts the sound a whole tone, so a long cascade plays as a rising arpeggio, with more debris particles and a stronger screen shake layered on top.

Measured inflation from all of that is about 2 to 3 percent, and the skill gap moves by a couple of points instead of thirteen. The excitement, which was always the point even though we did not say so out loud at the time, comes from the label, the rising sound and the shake rather than from digits getting larger, and people react to those far more reliably than to a number they have no intuition about anyway.

One implementation detail bit us, so it goes in the record. Attributing a merge to “the drop that caused it” does not work: the player is allowed to throw the next stone while the previous one is still settling, and counting by drop therefore cuts chains in half, which makes long cascades look like they almost never happen and would have flattened the feedback again. We attribute by a 900-millisecond time window instead, chosen from the measured distribution of gaps between merges, which is the sort of decision that deserves a comment in the source and has one now.

The general lesson

Any mechanic that makes numbers move a lot deserves suspicion. Twice on this project, a change that looked like a clean win while we played it by hand turned out, once we bothered to measure it, to be rewarding behaviour we did not want to reward or measuring something merely adjacent to what we believed we were measuring. In both cases the fix turned out to be much smaller than the original idea, which is a slightly humbling pattern to notice about yourself. The simulation took a few hours. Those hours are the reason we did not ship a slot machine wearing a skill system’s clothes.

← Back to the blog