Make risk and reward readable
Snapshot
~80 sec
Risk/reward readability means the player can estimate what they might gain and lose before they commit. If stakes are hidden until after the click, the fork is not a choice; it is a surprise. Readable risk makes regret informative instead of arbitrary.
You will learn
- Name gain, cost, and downside for each branch before the player commits.
- Spot when a bold option only looks bold because information arrives too late.
- Rewrite one fork so a careful player and a bold player can both explain their pick.
Target outcome
You can design a risk/reward fork where both options stay interesting because stakes are visible in time.
Visual walkthrough
Visual walkthrough
~6 min
What must be readable before commit
Gain
What the player hopes to get if the branch pays off.
Cost
What they spend to take the branch (resource, position, time, option).
Downside
What can go wrong, stated as a concrete loss or closed door.
Reveal timing
When each of those three becomes knowable relative to the commit click.
Hidden stakes versus readable stakes
Approach Agency Regret quality Fairness feel Surprise after commitLabels look similar; real downside appears only in the result screen. The player cannot aim; they can only hope the UI was friendly. Regret targets the designer, not a tradeoff the player chose. Even balanced numbers feel unfair when cause arrives late. Stakes before commitGain, cost, and downside are previewable; result confirms what was already priced. Players pick a risk profile, not a random button. Regret is informative: they knew the downside and still valued the gain. Attribution stays intact even when the bold branch fails. Fork with priced stakes
Both branches must change the aftermath. Readability fails if only one path has a real downside.
Fork moment
Two options appear with previewable gain, cost, and downside.
priced low
Safer branch
Lower gain, lower downside, keeps more later options open.
leads to
priced high
Bolder branch
Higher gain, sharper downside, closes or risks a later door.
leads to
Different aftermath
The next situation shows which risk profile was taken.
Both branches must change the aftermath. Readability fails if only one path has a real downside. Reading order
- Fork moment
Two options appear with previewable gain, cost, and downside.
- Safer branch
Lower gain, lower downside, keeps more later options open.
- Bolder branch
Higher gain, sharper downside, closes or risks a later door.
- Different aftermath
The next situation shows which risk profile was taken.
Connection explanations
- Fork moment → Safer branch (priced low)
Safer must still be a real option with its own gain, not a cosmetic skip.
- Fork moment → Bolder branch (priced high)
Bolder must show the sharper downside before commit, not only after failure.
- Safer branch → Different aftermath (leads to)
Safer aftermath should leave different doors open than the bold path.
- Bolder branch → Different aftermath (leads to)
Bold aftermath should prove the risk was real, success or fail.
Judge a fork
Option A says Safe route and shows +10 scrap. Option B says Risky route and shows +40 scrap. Failure on B deletes the run, but that text appears only on the result screen after confirm. Is risk/reward readable? What would you change?
Expected reasoning
Not readable. Gain is previewed; downside is not. Move the run-delete warning next to the +40 scrap before confirm, or block confirm until the player acknowledges the downside. Then check that the safe route still changes a later door so both branches remain real.