Pakwan Rhapsody
A high-pressure co-op cooking game themed on regional Indian cuisines. Cross-platform multiplayer, a tunable level-based difficulty curve, and a hybrid F2P economy built for the Tier-2 Indian market.
View detailsGame · Systems · Co-op F2P Design
I tune the systems behind co-op games: loops, economies, and difficulty that hold up under real players. Co-founder and lead designer on Pakwan Rhapsody.
About
For the last two years I co-founded Cracked Keyboards, an indie studio, where I owned core gameplay systems end to end: the co-op loop, the multiplayer architecture, the difficulty progression, and the free-to-play economy for our cross-platform title Pakwan Rhapsody.
What I care about is the part of design that never shows up in a screenshot: why a system holds together, where it breaks under real players, and what to actually change versus what to leave alone. Most of my work lives in spreadsheets and playtests before it reaches a build.
A high-pressure co-op cooking game themed on regional Indian cuisines. Cross-platform multiplayer, a tunable level-based difficulty curve, and a hybrid F2P economy built for the Tier-2 Indian market.
View detailsA scoped, data-driven balance read of 24 weapons across 8 slots: what the numbers can defend, and where the model itself breaks.
View detailsA hyper-casual runner built around session and difficulty design: keeping a 5–15 minute loop fresh through variation and pacing, not depth.
View detailsOwned core gameplay systems on Pakwan Rhapsody: co-op loop, multiplayer architecture (Unity Netcode / Lobby / Relay), the level-based difficulty progression, and a hybrid F2P economy. Led a four-person remote team from GDD to a functional vertical slice.
Ran product launches on Product Hunt, built community documentation databases, and shaped outreach aimed at aspiring game developers.
Early design work: visual layouts, illustration, and promotional content across the Adobe Creative Suite for two startups.
My Deep Rock Galactic weapon study is the clearest proof of how I think: scope the question to what the data can defend, group by role, name the model's own limits, and end on a decision, not a chart. It's a short read that shows the reasoning, not just the numbers.
Read the PDF →If you're building co-op or free-to-play games and want someone who reasons about the loops underneath, I'd like to hear from you.
◉ Delhi, India
A high-pressure co-op cooking loop that had to stay fair across mobile and PC, and scale in difficulty without sessions falling apart.
Built cross-platform multiplayer on Unity Netcode, Lobby and Relay; ran playtests; designed a hybrid F2P economy (IAP + rewarded ads) tuned for Tier-2 Indian players; authored 20+ levels themed on regional Indian cuisines.
In playtests, 8-player lobbies kept hitting desync and sessions collapsed before the difficulty curve ever mattered. Player count was masquerading as a difficulty knob.
Pivoted to a 4-player model so the connection held, then replaced player-count scaling with a level-based difficulty progression I could tune per level, independent of party size.
A static stat table can't tell you whether a game is "balanced": that needs play data. So I scoped the question to what the numbers can defend: within each slot, do the options look comparable on paper, or does one lead?
Parameterized every weapon (damage, magazine, ammo, reload, fire rate, range), derived comparative metrics with formulas stated explicitly, and grouped by role so comparisons stay fair.
Every slot resolved into one of three rulings: a clear skew with a lever to pull (the Scout marksman rifle), a set of balanced sidegrades to leave alone, or a paper-vs-feel gap where the model itself is the thing that's wrong.
I named where the model breaks: base damage-per-second can't see spin-up, charge mechanics, accuracy, or weak points. Stating the limit is the point, not hiding it.
Keep a hyper-casual loop feeling fresh across short 5–15 minute sessions without adding mechanical weight.
Designed the core run mechanic, power-up-driven gameplay variation, and a progressive difficulty ramp tuned around session length.
Rendered tilemaps in a lossless pixel format that holds up even in fast-paced play, and stabilised real-time performance by capping animated-sprite frame rates and driving them from prefabs. Added responsive music feedback on item pickups and power-ups, and built three varied levels with a variable headlight design that raises the challenge without straying from the core loop.
The retro pixel aesthetic is the hook: its nostalgia pulls players in and keeps them re-running the loop, which stress-tests the core gameplay hard. For the final level I used colour theory, flipping to a palette opposite the base greens so progression feels refreshing rather than repetitive.