Case study · Live
Dream Cricket
The meta and economy layer for a live cricket game: Battle Pass, Store, Gacha, Quests and Live Events, all tunable from the backend.
Store listing capture.
The problem
A live cricket game with a solid core and a thin reason to come back tomorrow. The meta needed to be built, and it needed to be built so that the people running it after launch could change it without a client release.
What I owned
The whole meta and economy layer: Battle Pass, Store, Gacha and Bundle, Quest and Mission, and Live Events. Alongside that, the onboarding and first-time user experience, which went through repeated iteration as we watched new players in closed beta, and the LiveOps cadence during that beta.
The system or decision
The structural decision was to make every system backend data-driven from the start. Pass tiers, store slots, drop tables, quest chains and event schedules were all tunable without touching code. It cost time up front and slowed the first milestone. It paid for itself the first time an event needed to change on a weekday afternoon and did, without an engineer in the loop. The second decision was to treat onboarding as a system with its own tuning sheet rather than a one-off tutorial, so each FTUE change was a hypothesis with a date attached.
Status
Live. I led a team of four or more designers through the build and the closed-beta LiveOps period. I am not quoting retention or revenue numbers here; the ones I have are the studio’s to share.