I didn't set out to do data collection on a kids' hospital roleplay game. I set out to figure out why my XP bar in Maple Hospital felt like it was lying to me. The answer turned into a small lesson about progression design that's relevant to anyone who's ever shipped a leveling system.
The setup
Maple Hospital is a Roblox roleplay game where you pick a hospital role — Nurse, Doctor, Surgeon, and about ten others — and earn XP by treating patients. The roles unlock at level gates (Doctor at 10, Surgeon at 25, and so on). What bugged me: experienced players insist Nurse has "the best XP," but my level bar crawled no matter what I did.
So I logged it. Across roughly 40 hours I recorded XP-per-minute by role and by room. Nothing fancy — a spreadsheet and a stopwatch and some discipline about tagging each session.
What the numbers showed
Two findings, one boring and one interesting.
The boring one: most roles earn within a tight band, roughly 8–12 XP/min. The "Nurse is best" advice is technically true but the margin is small. The real outlier was a specialization path (Anesthesiologist) where the per-action payout is higher and the room is less contested, pushing it to ~9–13/min. Contention matters as much as the base rate — a "high XP" room you share with five other players yields less than a "medium XP" room you have to yourself. That's a design lever a lot of multiplayer progression systems underuse.
The interesting one: the rate was roughly flat, but the bar still felt slower over time. That's because the XP required per level scales up. Flat income against a rising cost curve produces the exact sensation of "I'm playing well but stalling." Players read that as their own failure when it's actually the cost curve doing its job.
The progression-design takeaway
This is the part worth keeping if you build games: a constant earning rate plus a superlinear cost curve feels like deceleration even when nothing about the player's performance changed. It's a great retention tool — each unlock feels earned — but it's also a great way to make players quit if you never give them a sense of the remaining distance. The fix isn't to flatten the curve. It's to make the distance legible.
So I did two things, mostly to scratch my own itch:
I built a small XP-to-level estimator — current level and target in, approximate minutes-of-play out. It just inverts the cost curve against the observed earning rate. The point isn't precision; it's converting an opaque bar into "about 35 minutes," which is a number a human can plan around.
Then, because the specialization tree has branching prerequisites that are genuinely hard to hold in your head, I made an interactive spec-tree explorer that lets you click a target node and see exactly what it depends on. This is the same problem as a tech tree or a skill DAG in any RPG: the data is a graph, but the in-game UI usually presents it as a flat list, which hides the dependencies that actually drive decisions.
Why this generalizes
None of this is specific to one Roblox game. If you've ever shipped a progression system and watched a retention cliff at a particular level, the questions are the same: Is the earning rate actually flat, or does contention erode it at scale? Does the cost curve outrun the player's sense of progress? Is your dependency graph legible, or are you making players reverse-engineer it the way I just did?
Sometimes the most useful tool you can ship alongside a progression system is the one that tells the player how far they have left to go. The bar isn't enough. People want a number they can plan their evening around.
Top comments (0)