An economy change review that catches real mistakes

An economy change goes through normal review. Someone reads the diff, the values are formatted correctly, the change matches the ticket, and it ships.

Nothing in that process examines whether the numbers are right, because a wrong number looks exactly like a right one. Economy changes need a different review, and it is short.

Why standard review does not apply

Code review is good at finding logic errors, missing cases, and things that will break. An economy change usually has none of those — it is a value moving from one number to another, and the code is unchanged.

The failure modes are different in kind. A decimal in the wrong place. A value entered in the wrong unit. A rate that is correct per event and wrong because the event fires more often than the author assumed. A price that is right in isolation and inconsistent with its neighbours.

None of these are visible in a diff. All of them are catchable by asking a small number of questions that a reviewer would not otherwise think to ask.

The five questions

What does this multiply out to across the player base? Almost every serious economy mistake is a per-player number that looks reasonable and a population-level number that does not. The author computed the first. Asking for the second catches the whole class.

How often does this actually fire? A reward that is correct per trigger is wrong if the trigger happens ten times more than expected. This is the most common source of runaway payouts and it is invisible unless someone asks.

What is this relative to? A price or rate should be checked against the thing it is meant to relate to — a session's earnings, a comparable item, the tier above and below. A number that is right in isolation and wrong relative to its neighbours creates an inconsistency players will find.

What happens if it is wrong by ten times? For most changes, nothing much. For some, an unrecoverable state change across the whole population. Knowing which category you are in determines whether this needs staging.

Can it be undone? If the answer is no — if it issues currency or grants items — the change needs more care than one that only affects what is displayed.

Five questions, a few minutes, and they cover most of what actually goes wrong.

Who should ask them

The reviewer does not need to be an economy expert. The questions are answerable by the author and the value of the review is in the asking.

This matters because the alternative — routing every economy change through one specialist — creates a bottleneck that gets bypassed under time pressure, which is exactly when mistakes happen. A checklist any reviewer can run is more robust than an expert who is sometimes unavailable.

What the reviewer does need is standing to say "compute that before this ships". The questions only work if the answers are actually produced rather than estimated in the review conversation.

See how we bound and stage economy changes →

The record that pays off later

The second output of the review, beyond catching mistakes, is the reasoning.

If the review produces a one-line note about why the value is what it is, that note is worth more than the review itself over a long enough period. It is what stops the value being tidied away in two years by someone who cannot see why it is odd.

The cheapest place for that note is next to the change, in whatever the team already uses. It does not need a system. It needs to exist somewhere findable by someone who is looking at that value and wondering.

The reason this compounds is that economy values accumulate. A game running for years has hundreds of them, each set for a reason, and the reasons are the part that decays. A review process that captures one sentence per change produces, almost as a side effect, the document that makes the economy maintainable — and it produces it at the only moment when writing it is free.

It also helps to keep the review proportional. A change to display text does not need five questions asked of it, and running the full checklist on everything is how a lightweight process becomes one people route around. The trigger worth using is whether the change touches anything that issues currency, sets a price, or alters a rate. That is a small, mechanically identifiable set of files or config keys, and gating on it means the review fires exactly where it earns its cost and nowhere else. Teams that scope it this way keep using it; teams that apply it universally abandon it within a quarter.

Talk to us about safe economy operations →