For years I thought RobTop was being stubborn. Every time someone in the Geometry Dash subreddit suggested he should port the game to Unity to ship 2.3 faster, I rolled my eyes a little — but somewhere in the back of my head I half-agreed. Unity has a level editor. Godot is open source. Either choice would have given RobTop a shipping pipeline that didn’t depend on him personally writing every system from scratch. The 2.2 wait was demoralizing. The 2.3 wait is approaching legendary status. Why not just take the shortcut?
Then I sat down and tried to imagine what a Unity port of Geometry Dash would actually feel like to play. Not in theory. Specifically. Click for click, level for level, what would change. After about three hours of thinking it through, I stopped questioning RobTop’s choice and started questioning my own assumption that engine choice is just an implementation detail. It isn’t. For this game, it’s the entire foundation, and I think after years of playing I finally understand why he made the call he made.
The Build vs Buy Decision Most Solo Devs Get Wrong
The default advice for any solo game developer in 2026 is “use an existing engine.” That advice is correct for almost every project. Unity exists because re-implementing rendering pipelines, physics solvers, audio systems, and input abstraction is a multi-year project before you’ve even shipped a single mechanic. Godot has caught up to the point that I’d push most indie devs there for a 2D platformer today. The math on building your own engine in 2026 is brutal — you’re spending two years on infrastructure your competitors got for free, and your game has to be measurably better in some specific dimension to make that investment worth it.
Most games that try to justify a custom engine fail this test. They end up with a worse renderer than Unity has, a worse physics system than Box2D ships out of the box, and the same gameplay they would have shipped two years sooner on someone else’s stack. Geometry Dash is one of the rare cases where the math actually works out the other way. RobTop started building this game in 2013 on top of Cocos2d-x, modified it heavily over the next several versions, and the modifications themselves became the thing that makes Geometry Dash feel like Geometry Dash. The engine isn’t an afterthought. It’s the product.
Why a Unity Port Would Feel Wrong
I want to walk through this concretely, because I think the abstract argument doesn’t land until you imagine the specifics. Picture loading up Bloodbath in a Unity-rebuilt Geometry Dash. The level looks identical. The music starts. You click. Here’s where it falls apart.
Unity’s input system has a default polling rate tied to the frame rate, with an asynchronous path that can be enabled but introduces its own complexity. On a 60Hz monitor, a click that arrives between frames waits for the next frame boundary before being processed. That’s roughly 16 milliseconds of variance in input timing depending on when within the frame your click landed. For most games, 16 milliseconds is invisible. For Geometry Dash, where players routinely hit windows of 30 to 50 milliseconds on demon-tier challenges, 16 milliseconds of variance is the difference between consistent and uncrackable. You’d feel it on your first run through Theory of Everything 2. The level wouldn’t have changed. The cube wouldn’t have changed. But the timing would feel slippery in a way it currently doesn’t.
Unity’s physics solver is also nondeterministic across machines by default. PhysX, which Unity ships with, is fast and good at general-purpose 3D and 2D physics, but it doesn’t promise that two players running the same level with the same inputs will get the same outcome. Replays in a Unity-port Geometry Dash would have to be saved as recorded video, not as input logs, because re-simulating an input log on a different machine could produce a death where the original run produced a clear. That single change — replays that aren’t bit-perfect — guts the entire verification ecosystem the game has built up. Top-tier extreme demon completions are validated partly because the engine can re-simulate the inputs deterministically. Take that away and you’re back to the YouTube-video-as-proof era.
The Level Data Format Problem Nobody Talks About
Here’s a thing I didn’t fully appreciate until I started poking at it. Geometry Dash levels are stored as a custom serialized format that’s been evolving since 2013. Every level the community has built — every Robtop main level, every featured user creation, every legacy demon — exists in this format. The community has built tools (GDShare, the various editor plugins) that can parse and manipulate these files because the format, while undocumented, is stable.
If RobTop ports the game to Unity, he has two choices. Option one: rebuild Unity’s level loader to ingest the existing format and emit Unity-native scene representations at runtime. That’s a translation layer, and translation layers leak. Some object behaviors won’t map cleanly to Unity primitives, and those will have to be patched individually. Option two: migrate every level in the game’s history to a new format. The user-created level catalog alone is in the millions of levels. A migration on that scale either takes years of community-maintained tooling or breaks compatibility for anything that doesn’t get migrated by hand. Either path costs more than the engine port itself.
This is the thing that I think tilts the decision irreversibly toward “stay on the custom engine.” A new engine doesn’t just have to deliver the gameplay feel. It has to inherit twelve years of accumulated content with bit-perfect fidelity. Unity is not built to do that. Godot isn’t either. Cocos2d-x with RobTop’s modifications is, because the modifications were designed alongside the format from day one.
The Cost RobTop Pays — And We Pay With Him
I’d be writing dishonestly if I made this all sound like a pure win. Sticking with the custom engine has cost RobTop years and cost the community patience that is genuinely running out. Version 2.2 took roughly seven years from 2.1 to ship. Platformer mode, the headline feature of 2.2, is a great addition and clearly took massive engine-level work to integrate properly — you can feel the determinism still holds in platformer mode, which would have been hard to maintain on a sloppier engine. But seven years is seven years, and we lost a lot of the original 2014 community to that wait. Some of them are not coming back.
2.3 is on a similar pace and there’s no evidence that’s going to change. RobTop has confirmed in 2026 that “real progress” is happening, but he’s still the bottleneck on every system because he wrote every system. A larger studio could parallelize across an engine team and a content team. RobTop is one person who is also still the engine team. The cost of that approach is exactly the multi-year update gaps the community keeps complaining about. The cost is real. I just think the alternative — shipping faster on a generic engine that broke the game’s identity — would have been a worse trade.
What I Think He Actually Got Right
The deeper insight, the one I didn’t have a few years ago, is that RobTop wasn’t choosing between “Unity in 2014” and “custom engine in 2014.” He was choosing between two future paths. Path one: ship faster, build a game that feels like every other Unity platformer, lose the specific identity that made Geometry Dash a phenomenon, gain a few years of development velocity. Path two: ship slower, own the engine, keep the identity, build something that’s still feeling distinct twelve years later when the Unity competitors have all started to feel interchangeable.
I think he was right. I’m fairly confident he didn’t articulate the choice in those terms in 2013 — most of us don’t think that strategically about engine choice when we’re a solo dev with a half-finished prototype. But he made the choice anyway, probably because he was the kind of developer who likes writing engines, and the path-dependent consequence of that personal preference turned out to be the right call for this specific game in a way that almost no other indie platformer could have replicated.
Geometry Dash in 2026 is one of the few games where you can point at the engine and say: that, specifically, is the reason this works. Most games don’t have that. The cost of getting it is approximately seven years between major releases, and the community is not always quiet about that cost. Fair enough. But I’m not going to pretend I’d take a faster Unity port over what we have. After thinking it through carefully, I don’t think most of you would either, once you actually played it.
Leave a Reply