Expected value: the calculation that stops your event killing the revenue after it
An event that hands out too much currency leaves players rich and with no reason to buy. The documentation shows the expected value calculation that predicts this before it happens — and the sink that solves it.
Produced with AI from the sources cited below, and checked by automated verification against those same sources. No person read this text before publication. Editorial Policy
There is a pattern almost every game with an economy lives through at least once: the event is a success, players love it, participation explodes — and in the following weeks the revenue falls.
It is not a coincidence, and it is not the audience getting tired. It is arithmetic, and the official documentation shows the calculation that predicts it before it happens.
The problem
The framing: virtual economies on Roblox mimic real economies, with players trading, earning and spending currency and resources. Balancing them is vital for a fair experience that keeps the player motivated, without over- or undervaluing the virtual goods.
The best practices are four: data-driven content, resource planning, impact estimation and resource sinks.
The first is about knowing what is happening. The documentation lists six things to track, and the list is worth reading slowly because each item answers a different question:
- Who buys which item.
- Which actions earn currency.
- How much currency is earned versus how much is purchased.
- Whether the currency used in purchases was earned or bought.
- When and which items are used.
- How often the player interacts with each resource, and at what moment.
The third and fourth items are the ones nobody measures and the ones that matter most for this text. The proportion between earned and purchased currency is your economy's health — and if purchases are being paid for with earned currency, the Robux shop is decorative.
Step by step
The example the documentation uses is a fictional fishing game, and it is good because it is small enough to follow in your head.
Three fish, with a chance and a value: the catfish has a 70 per cent chance and is worth 10 gold; the trout, 20 per cent and 20 gold; the salmon, 10 per cent and 30 gold.
1. Calculate the expected value of one attempt. The common method for measuring potential impact is the expected value — the sum of all possible values, each multiplied by its probability of occurring.
In practice: given a group of valuable items with a chance of appearing, you multiply each one's value by the chance of getting it. In the example, the catfish contributes 7 gold, the trout 4, the salmon 3. Adding up, the expected value of one fishing attempt is 14 gold.
2. Multiply by the volume. That is the step that turns an abstract number into a prediction. Fourteen gold per attempt, times the number of attempts per day, gives how much gold your game creates on a normal day. The documentation uses a thousand attempts a day in the example, which gives 14 thousand gold created.
3. Redo the calculation with the event. The planned event adds a golden salmon available for 24 hours, with a 0.1 per cent chance, worth 1000 gold. Add that line to the same spreadsheet and compare with the normal day.
4. Plan the sink before launching. That is the fourth practice, and the next section.
5. Measure afterwards. The event ends and the analysis begins: comparing the period's currency creation with a normal day's is what turns this event into a better estimate for the next.
It is worth saying why expected value is the right tool here, rather than an average of observations. An average only exists afterwards; expected value exists beforehand, from numbers you set yourself — each outcome's chance and value. It is the only way to assess an event that has not happened yet, and that is why it belongs in the planning phase rather than the diagnostic one.
And it has a property that helps: it is additive. Adding a currency source to the game is adding a line to the spreadsheet, and the effect on the total appears immediately. That lets you test an event idea in thirty seconds, before any implementation.
The artifact
The table below is the complete calculation from the official example, with the normal day and the event day side by side.
A necessary observation about the source: the salmon line appears in the official calculation written as 30 gold times 30 per cent, but the stated result is 3 gold — which corresponds to the 10 per cent given in the fish's description, not 30. The total of 14 matches 10 per cent. When copying the spreadsheet, use the chance from the description.
And at the end of the table is the point the whole example exists to teach, which the next section develops.
Before the mistakes, a note on what the first practice — data-driven content — requires in practice. The six points on the list do not measure themselves: they have to be instrumented in the game, event by event. Anyone who never recorded "which action earned how much currency" cannot build the next step's spreadsheet, because the expected value needs the real chances and values, not the ones that were in the design document.
Common mistakes
The mistake is described in the official example itself, and it is subtle enough to deserve attention.
The developers launch the event without estimating the economic impact of the increase in fishing. What happens afterwards: the data visualisation shows gold purchases in the shop flat, while spending soars.
Read that sentence again, because it is the diagnosis. The players are spending a lot — which looks great — and buying nothing. They are spending the gold they fished, not the gold they bought.
The cause: underestimating the increase in fishing leads to a significant surplus of gold in the economy. And the consequence is the one that gives this article its title: with gold abundant, the player spends freely, loses the incentive to buy more, and the revenue falls after the event ends.
The crucial detail is which variable was underestimated. It was not the golden fish's value: at a 0.1 per cent chance, its contribution to one attempt's expected value is small, however much the 1000 gold impresses in the event's description.
What blew up was the number of attempts. The event, being attractive, made people fish far more. And since the gold created is the expected value times the volume, doubling the volume doubles the currency creation — even with nothing changed in the fish table.
That is the lesson to carry into any event: a successful event is, by definition, an event that increases activity. And if activity creates currency, success and inflation are the same thing.
The documentation is honest about the limit of the prediction: it is impossible to know exactly how many people will take part on an event day. But it adds what makes that tractable — each successive event helps future estimates. The first is an informed guess; the third is already a forecast.
And it gives the criterion for knowing when it is too much: by understanding the normal purchase rhythm and how long the player takes to buy useful items, you can determine how much currency is too much currency.
Looking only at spending. It is the reading mistake that sustains all the others: high spending looks like health. The documentation shows the case where it is a symptom — spending soaring with purchasing flat means the player is spending what they earned, not what they paid for. The two curves have to be read together, always.
Next step
The fourth practice is what closes the loop: a resource sink — an economic system built to take resources out of circulation.
The documentation lists three forms, in increasing order of effectiveness:
- An event cosmetic, such as a golden accessory for a limited time.
- A sequential event requiring the currency earned in the previous event to be spent.
- An event shop giving a small benefit to whoever spends while the event runs.
And it points at the safest of all: making the event generate a currency of its own, used only to buy items from a specific shop.
That last one solves the problem at the root rather than treating the symptom. Event currency that does not convert into the main currency cannot inflate the game's economy, by construction — it is born with the event and dies with it. The surplus exists, players celebrate it, and it does not leak.
The exercise for today, before any event: build your game's expected value spreadsheet. List every currency source, with its value and probability, calculate the expected value per attempt, and multiply by the volume you already measure.
That number — currency created per day, on a normal day — is the baseline without which no event estimate means anything at all. And it is a number most games with an economy do not have.
Sources
Ready-to-use artifact
EXPECTED VALUE (EV) OF ONE ATTEMPT. Checked on 23/09/2026.
The rule: multiply the VALUE of each possible outcome by its CHANCE,
and add it all up.
== THE OFFICIAL EXAMPLE: a normal day ==
| Fish | Chance | Value | Contribution |
|---------|--------|-------|--------------|
| Catfish | 70% | 10 G | 7 G |
| Trout | 20% | 20 G | 4 G |
| Salmon | 10% | 30 G | 3 G |
| | | EV = | 14 G |
EV of ONE attempt ............. 14 G
x attempts per day ............ (YOUR number, measured)
= gold created per day ........ what you need to know BEFORE the event
The documentation uses a thousand attempts a day in the example, which
gives 14 thousand gold created on a normal day.
NOTE AN INCONSISTENCY IN THE SOURCE: the salmon line appears in the
official calculation as "30 Gold x 30%", but the stated result is 3 G --
which corresponds to the 10% given in the fish's description, not to
30%. The total of 14 G matches 10%. When copying the spreadsheet, use
the chance from the description.
== THE EVENT, in the same calculation ==
Golden Salmon: 0.1% chance, 1000 G, for 24 hours
Put that line in the SAME spreadsheet: value x chance, like the others.
Its contribution to the EV per attempt is SMALL -- 0.1% is little,
however much 1000 G impresses in the event's description.
And that is why the mistake is not there: the event also changes how
many ATTEMPTS happen
per day, and it is that second variable that blows up the economy. The
mistake in the official example was not getting the fish's value wrong
-- it was underestimating the increase in FISHING.
| What to measure | Normal day | Event day |
|------------------------|------------|----------------------|
| EV per attempt | 14 G | slightly higher |
| attempts per day | measured | ??? <- the variable |
| gold created | EV x att. | can be a MULTIPLE |
== THE FOUR SINKS ==
A sink = a system built to TAKE resources out of circulation.
1. an event cosmetic (a golden accessory for a limited time)
2. a SEQUENTIAL event requiring the previous event's currency to be spent
3. an event shop giving a small benefit to whoever spends during it
4. THE EVENT'S OWN CURRENCY <- the documentation calls this the safest
The fourth is the only one that stops the surplus LEAKING into the main
economy: a currency that only works inside the event dies with it.
