Rollout safety for changes to a live game's economy

Most live changes are reversible. Ship it, watch it, revert if it looks wrong. That habit is correct for nearly everything and it is wrong for the economy in a way that catches teams out.

The difference is that an economy change produces state. Reverting the config stops the change from continuing; it does not remove what it already did.

Why reverting does not undo it

If a reward rate is set too high and runs for six hours, players earned at the higher rate for six hours. Reverting the rate restores the intended rate going forward. The currency issued in those six hours is in wallets, and it stays there.

You now have three options and all of them are bad. Leave it, and a subset of players got a windfall others did not, which is unfair in a comparative game and inflationary in any game. Remove it, and you are taking currency from players who did nothing wrong, which is the single most reliable way to generate a trust incident. Compensate everyone else, which multiplies the original mistake across the whole player base.

The same applies to prices. An item accidentally priced too low and bought by a thousand players cannot be unbought. Those players have the item. Raising the price back does nothing about them.

This is what makes economy changes different from almost everything else you ship. The blast radius is not the duration of the mistake — it is the duration multiplied by your active population, and it persists after the fix.

The controls that actually help

Because you cannot undo, the useful controls are the ones that limit exposure before the change is fully live.

Rolling out to a small share of players first is the most valuable single control. A rate that is ten times too high, applied to two percent of players for an hour, is a manageable amount of currency in wallets and a completely obvious signal in the data. The same mistake applied to everyone for a day is an incident.

Bounds on what a config value may be are the second. Most catastrophic economy mistakes are typos — a decimal place, an extra zero, a value in the wrong unit. A rule that refuses to apply a reward rate more than some multiple of the current one catches nearly all of them, and it costs one check. This is worth having even when the change is being made by someone experienced, because the failure mode is a slip rather than a misjudgement.

A hard limit on total issuance is the third and the most underused. If the system knows how much currency it expects to issue in an hour, it can stop when the actual figure exceeds that by a wide margin. This catches the whole class of mistakes where the rate looks reasonable but the trigger fires far more often than expected — which is a bug type that bounds on the value cannot catch.

Watching the right number during a rollout

Teams watching an economy change usually watch revenue, which is the slowest signal available.

The fast signal is issuance rate: how much currency is entering the game per unit time compared to normal. This moves within minutes of a bad change and is unambiguous. Revenue moves hours or days later and is confounded by everything else.

The second fast signal is the distribution of what players are earning, not the average. A change that gives a small group a very large amount barely moves the average and is clearly visible in the distribution. Averages are exactly the wrong summary for catching this class of problem, because the mistakes that matter most are usually concentrated.

The third is spend behaviour immediately after. A sudden increase in purchases of a specific item usually means that item is mispriced, and it shows up well before anyone reads a revenue report.

None of these need to be elaborate dashboards. They need to be visible during the window when someone is watching the rollout, which is the only window where cheap intervention is possible.

See how we bound and stage economy changes →

The pre-flight question

Before a change to anything that issues or prices currency, the question worth answering in writing is what happens if this value is wrong by a factor of ten.

For most changes the answer is "not much" — the value is bounded by something else, or the change affects a small number of players, or it is a one-time grant with a known size. Those can ship normally.

For some changes the answer is that a factor-of-ten error would be a serious incident that cannot be undone. Those need staging, bounds, and someone watching. The point of asking is that the two categories are not distinguishable by how big the change looks. A one-line rate adjustment can sit firmly in the second category, and it will not feel like it does while you are making it.

Teams that adopt this find that most changes stay easy and a small number get treated with care, which is a much better allocation than treating everything the same in either direction.

Talk to us about safe economy operations →