Passa al contenuto principale

Proposal: Reward Economy — Quests, Cash & Seasons

Status — accepted direction for the pilot, not yet shipped · start here

Owner: Tom · decided 2026-06-19. This is the reward spine — the doc the rest of the proposals cluster hangs off. It replaces the hours→cash ladder, supersedes the cash-coupled parts of the EXP System (EXP no longer pays cash), and changes the pilot model recorded in playroll-ui/CLAUDE.md. Nothing here is shipped yet; this is the design-of-record the UI, schema and backend work hang off.

How the cluster fits together:

The pivot in one line

Cash comes from quests, not from time recorded. Passive recording earns progression (EXP toward a Season track), never money. The thing EC pays for is bespoke, directed capture — specific people doing specific scenarios — because that is the data with value. Undifferentiated "record any eligible game for N hours → €X" is retired.

Why move cash onto quests

Three wins land at once, which is why this is worth the churn of replacing the shipped model:

The data improves. A quest specifies what to capture — a scenario, a role, a group composition, an objective. That is directed/interventional capture, which is far more valuable per hour than ambient volume. Paying for quests means paying for exactly the data we want.

Cost becomes controllable. Under the hours ladder, spend was an open-ended function of how long people recorded, bounded only by a per-user envelope. Under quests, each quest carries a set reward we price to its worth to us. Total spend is the sum of quest rewards we choose to publish — a dial, not a tide.

The abuse surface shrinks. "Record for time → money" rewards idle, AFK, menu and fake gameplay; the in-session low-fps / dead-capture checks are observe-only and upload low-quality sessions anyway. A quest pays for a defined deliverable validated against its objective, so there is no payout for simply leaving a game running.

The two axes

The economy now has two independent axes that must not be conflated.

Cash axis — quests. Every paid action is a quest with a set cash reward. Rewards are tuned per quest by data value and adjusted over time. This is the business/payout layer.

Progression axis — the Season (battle pass). EXP is the progression currency and it buys status and cosmetics, never cash. A Season is a time-boxed window in which EXP advances a tier track with unlocks (avatar frames, username trim, in-game/game rewards, seasonal cosmetics). The Season is tunable between runs and can be active or dormant — built enabled, with an off switch, because there will be gaps between Seasons. The 4-week pilot is effectively Season 0.

Keeping these axes separate is what makes the model safe: social/virality mechanics (party multipliers, referrals-as-EXP) can be generous on the progression axis without ever inflating cash outlay, and cash stays strictly tied to validated quest deliverables.

Mockup

A cohesive visual of the model — the quest-forward Home (C2) with the reworked top bar and the EXP ring on the avatar, plus the Rewards / Season page showing the two tracks side by side. Also linked under Proposals → Interactive mockups in the sidebar; opens full-width as a standalone page.

What earns what

ActionCashEXP (Season progression)
Passive recording of an eligible gameYes — validated minutes (the EXP floor)
Completing a questYes — the quest's set rewardYes — quest bonus EXP on top
Larger party on a questYes — party-size EXP multiplier (shared)
Referral qualifiesYes — bounty on referee's first quest completionoptional

Notes that follow from the decisions:

  • Passive recording = EXP only. It keeps the app sticky and still captures ambient data, but it is not a payout vector — which is precisely what removes the farm incentive. EXP accrues from validated minutes (idle/menu time does not pay), so EXP lands shortly after a session, not live.
  • Party-size multiplier rides EXP, not cash. More players in a quest party → more EXP for everyone in it. This pulls friends in and rewards group play without turning party size into a cash-fraud lever.
  • Referral = cash bounty on first quest. When a referred player completes their first quest, the referrer earns a set cash bounty (replacing today's hours-based +2h). It is engagement-gated (the referee did real, validated work) and capped, reusing the existing referral anti-fraud gates (self-refer block, one-time per pair, referrer-must-be-real, cap).

What this retires or changes

  • The hours→cash ladder is gone (the €10/€20/€40/€80/€350 at 1/6h…25h thresholds). Cash earned = Σ completed quest rewards.
  • EXP no longer maps to cash. The EXP System levels become Season tiers with cosmetic/status unlocks. EXP math (1 validated min = 1 EXP, + quest bonus, + party multiplier) survives — only its payout meaning changes.
  • Referrals rebase from +2h to a first-quest cash bounty.
  • The pilot success metric changes from "5000 hours in 4 weeks" to something quest-shaped — quests completed / target scenarios captured. Hours stay a health/coverage metric, not the goal.
  • playroll-ui/CLAUDE.md (pilot section, levels.config.ts cash mapping, the cash-ladder Rewards view, hours-based referral copy) needs updating when this lands. Tracked here so the flip is deliberate.

Things this model makes us responsible for

These are the real costs of the pivot — worth naming so they are designed, not discovered.

Quest supply is the funnel. With time-based cash, every player always had a way to earn. Now, if there are too few live quests worth doing — or we are between Seasons — a money-motivated student can open the app and find nothing to earn. Mitigations: an evergreen baseline of always-available quests so the earn path is never empty, plus a clear empty-state when it is. The CRM-authoring throughput (who writes quests, how many, refresh cadence) becomes the operational constraint on earnings.

Quest-objective validation is harder than hour validation. "Did they record the specific scenario, with the specific people, doing the specific thing?" is a bigger ask than "did they hit N validated minutes." This is a dependency on the data-filtering / validation pipeline and on how quest_participations records objective satisfaction. Until objective-level validation exists, early quests may validate on a coarser proxy (validated minutes in the marked game(s) + party membership) and tighten later.

Budget is now a publishing decision. Spend = the rewards we attach to the quests we publish. That is more controllable than the old envelope, but it means pricing quests deliberately and watching aggregate exposure as quests go live.

Season mechanics (sketch — to expand)

  • A Season has a start/end and an active/inactive flag. Quests (and their cash) can run continuously; the Season layer (EXP→tier cosmetics) is what toggles. Between Seasons: quests still pay cash, EXP still accrues, but tier cosmetics do not advance until the next Season opens (or EXP banks toward it — open call below).
  • Tier rewards are cosmetic/status only and fully re-tunable each Season, which is the "adjust reward structures over time" lever.
  • The pilot ships as Season 0; the season scaffolding is built now and the flip to enabled is config, not a rebuild.

Open calls

  • Evergreen baseline size: how many always-on quests guarantee a non-empty earn path, and at what reward floor?
  • Between-Season EXP: does EXP bank toward the next Season, or pause? (Lean: bank, so passive players are not punished for the gap.)
  • First-quest referral bounty amount + cap, and whether the referee also gets a small kicker.
  • Objective validation rollout: coarse proxy first vs. wait for true objective validation before any quest pays.
  • Pilot metric definition: the exact quest-shaped target that replaces "5000 hours."