Published July 19, 2026
CosmicDrift.io has 1,000 levels. That number alone doesn't say much — the question that actually matters is how much mass (orbs collected, kills scored) it takes to reach each one, and that question turned out to be a lot harder to answer well than it looked at first. We rewrote the formula behind it twice. This is the story of why the first version was wrong, why it took shipping it to find out, and what the fix actually looked like once we stopped reaching for a single equation to solve the whole problem.
If you need "mass required to reach level N" for N from 1 to 1,000, the instinctive move is to write one formula and plug in N. That's exactly what the earlier version of the stage system did: mass_required(stage) = round(12 × stage²). A plain quadratic. It's clean, it's a one-liner, it's easy to reason about, and it satisfies the basic shape you want from a leveling curve — early levels are cheap, later levels cost more, and the curve accelerates smoothly the whole way up. On paper this looked completely reasonable. It's the kind of formula you'd sketch on a whiteboard in five minutes and feel good about.
And for a while, it was fine — because "fine" is easy to confirm when you're only looking at the front third of the range. Low levels felt fast. That's most of what anyone testing the game in short sessions actually sees, so it's easy to walk away thinking the formula works.
The problem shows up the moment you try to satisfy two goals that both matter and both apply to the same formula: level 100 needs to be reachable and exciting within one real play session, and level 1,000 needs to still mean something after weeks of dedicated play — a real, sustained grind, not a formality.
A single power curve can't do both, and the reason is structural, not a tuning mistake. If you tune the exponent and coefficient so level 100 feels achievable in a session, you've fixed two points on the curve near the origin — and a power function is defined by its shape near the origin just as much as anywhere else. Push the same formula out to level 1,000 and it either explodes into an absurd number nobody will ever reach, or — if you'd tuned it gently enough to avoid that — it stays so tame that level 1,000 becomes only marginally harder than level 500. There's no exponent that gives you "fast and exciting near level 100" and "still a real wall at level 1,000" at the same time, because both of those are just descriptions of the curve's steepness, and a single power curve only has one steepness-shape to give you across its entire domain. You can slide it, but you can't make it behave like two different curves stitched together — which, it turns out, is exactly what the design actually needed.
"No single power curve can satisfy both, since making level 100 cheap enough to feel exciting in a 15-30 min session also makes level 1000 trivially cheap if the same formula covers both."
The realization that unlocked the actual fix was simple to state and a little annoying to admit: we didn't need one formula. We needed the per-level cost to change decade by decade, on purpose, instead of being a fixed consequence of one equation's shape. So the quadratic got replaced with a 101-point anchor table — one entry every 10 levels, from stage 0 to stage 1,000 — with the mass required at every level in between filled in by linear interpolation from its two neighboring anchors.
That sounds like more moving parts than one formula, and it is. But it buys something a formula structurally can't: independent control over the growth rate in each section of the range. Levels 1 through 100 climb fast — roughly 28 mass per level up through level 10, ramping up to about 450 mass per level by the 100-110 range — so a new player reaches level 10 in about a minute and level 100 within their first real session. That's the "fast and exciting early" goal, fully satisfied, with nothing pulling against it from further out on the curve.
From level 100 to 510, the per-level rate keeps climbing every decade — roughly +50 mass-per-level for each additional decade, so the 100-110 band costs about 450 per level and the 500-510 band costs about 2,450 per level. This is the real, escalating grind for anyone who sticks with the game past a first sitting. And then, deliberately, it stops climbing: from level 510 to 1,000 the rate is frozen flat at that same 2,450-per-level figure. Level 1,000 isn't cheap, but it's not an ever-steepening wall either — it's a long, predictable, flat grind, which keeps the summit actually reachable for someone dedicated instead of turning into a number that only exists on paper.
The earlier version of this doc had that freeze point wrong for a while, too — an internal QA pass caught that the shipped table kept climbing for nine more decades past 510 before flattening at the wrong value. Worth saying plainly: a hand-built 101-point table is exactly the kind of thing that's easy to get subtly wrong in one spot without noticing, because eyeballing "does this feel right" doesn't catch a single wrong anchor the way it catches an obviously broken curve shape. That's a real cost of trading one clean equation for a table with a hundred manually-reasoned control points — you gain flexibility and lose the kind of correctness-by-construction a formula gives you for free.
The stage-progression curve wasn't the only place this exact problem showed up. Bot and player visual size — how big your comet actually looks on screen as you level up — is a completely separate formula from mass progression, and it went through the identical failure mode independently.
The first version was, again, a single power curve, this time capped at 22×. On paper, another reasonable-looking formula. In practice, it broke two ways at once, and they were the same tradeoff as the mass curve wearing a different costume. Cap the growth high enough to feel meaningful at end-game, and a player who reached a high stage became genuinely unplayable — a real, reported case had an entity alone at stage 250 measured at 9.69× scale, big enough that the player said outright it wasn't possible to see around their own head or actually fight anyone. Cap it low enough to avoid that, and the curve's shape front-loaded so much of the growth into roughly the first quarter of the stage range that the remaining three-quarters — the majority of the 1,000-level progression — looked almost visually flat. Same root problem as the mass formula: one curve, two goals, no exponent that serves both.
The fix followed the same logic as the mass table, just implemented as a three-tier piecewise curve instead of a full 101-point table, since visual scale only needed a few distinct behavioral zones rather than fine per-decade control:
The reasoning behind where those breakpoints land wasn't arbitrary — it came from thinking about the actual player population rather than the abstract range of possible stages. The large majority of players die or stop playing well within their first 50 to 100 levels, and those are exactly the players who most need visible, immediate progress to feel like the game is rewarding them. Well under 1% of players will ever reach stage 500 or beyond. So growth is front-loaded for the group that's actually there to see it, given a controlled climb through the stretch that only genuinely dedicated players reach, and then deliberately made flat past 500 — because past that point, raw size stopped being a good reward on its own terms. A 5×-scale entity is already close to the practical limit of what's fun and fair to fight; making it 10× or 20× wouldn't read as "more powerful," it would just read as "impossible to play against," which is the same unplayability failure the original 22×-capped curve produced, just discovered a second time in a different system.
Looking back at both of these next to each other, the actual lesson isn't "quadratics are bad" or "always use a table." It's narrower than that: when a single formula is being asked to satisfy two goals that live at genuinely different points on its domain — cheap-and-exciting near the start, meaningfully-hard near the end, for example — check first whether those two goals actually need different rates, not just different values. If they do, no amount of retuning coefficients and exponents on one formula will resolve it, because you're not fighting a tuning problem, you're fighting the formula's fixed shape. The fix in both cases here wasn't a smarter formula. It was giving up on having exactly one, and instead directly authoring how the rate itself changes across the range — a table with per-decade control for mass, a three-tier piecewise curve for visual scale.
None of the specific numbers above should be read as "the correct, final tuning." They're explicitly documented in our own internal notes as first-pass constants, the same way the original 22×-capped scale formula was too, before real play showed it was wrong. The mass-per-level figures in the anchor table, the exact stage breakpoints for the visual-scale tiers, the 5× cap itself — all of it is a starting point meant to be retuned once real playtesting shows the actual pace players experience, not a claim that we've found the perfect curve on the first or even second try. We got the shape of the solution right — split the goals apart instead of forcing one curve to serve both — but shape and tuning are different problems, and only one of them is done.
There's also a genuinely un-modeled factor sitting on top of all of this: killing another player scatters mass-conserving loot at their death location — up to 1,200 mass in a single drop for a well-timed player kill. That's worth over eleven minutes of ambient orb collection in one pickup. None of the pacing numbers above account for that, which means anyone actually fighting other players rather than just grinding orbs in isolation is going to move through this curve considerably faster than the table alone implies. That's a feature, not an oversight — but it's one more reason the table above is a first draft of the intended shape, not a promise about exactly how long level 1,000 will take any specific player to reach.